In order to import an existing installation of Redmine you’ll need both local (your development machine) and remote steps (on your production server). First of all you need to checkout my Redmine fork on your local machine using this command:

git checkout git://github.com/fabn/redmine.git

After that you need to define at least your production configuration, this goes into config/deploy/production.rb file. This could be its content

# roles definition
role :web, "your.redmine.org"
role :app, "your.redmine.org"
role :db, "your.redmine.org", :primary => true

# used on redmine install to load default data when installing
#set :load_default_data, false # default: true

# Customize here your start, stop and restart tasks if you need
# To use them you MUST deploy using explicit environment i.e. cap production redmine:upgrade
#namespace :deploy do
#  task :stop do
#    logger.important "Overridden"
#  end
#end

After that, from the local machine run

cap deploy:setup

this will prepare the folder structure on the server (under /var/rails/redmine folder, if you want to edit that override the :deploy_to variable for capistrano in the same file)

After the setup ssh into the remote machine and run the following commands, adjust paths to fit your needs

export OLD_REDMINE=/where/you/have/it
export NEW_REDMINE=/what/you/ve/set/in/production.rb
# The file configuration.yml exists only in RM >= 1.2
cp -a ${OLD_REDMINE}/config/{database,email,configuration}.yml ${NEW_REDMINE}/shared/config
rmdir ${NEW_REDMINE}/shared/files && cp -a ${OLD_REDMINE}/files ${NEW_REDMINE}/shared/

Then you should copy your themes and plugins in your new structure, you can use the following commands, but then need to remove all the stuff provided in Redmine itself. This is true especially for plugins since your installed plugins are in the same folder of the distribution plugins. If you won’t Capistrano will fail on deploy with a "ln: file exist" error.

cp -a ${OLD_REDMINE}/public/themes/* ${NEW_REDMINE}/shared/themes
cp -a ${OLD_REDMINE}/vendor/plugins/* ${NEW_REDMINE}/shared/plugins

Alternatively you can pick only folders you’ve manually installed into themes and plugins folders and put it in the destination folders (under shared/plugins and shared/themes).

Then, from the local machine, deploy the current version with

GIT_TAG=<your-current-version> cap production redmine:upgrade

This will deploy the code for the given tag, symlink all the imported data and then it migrate the db. Since you’re not doing a real upgrade no migration should be ran.

Final Notes

To ensure you can run all the above command you can try them with a staging configuration before doing the actual import to ensure that you meet the requirements. To do that follow these steps

Create a config/deploy/staging.rb file locally, with the following content:

# deploy to a different path
set :deploy_to, "/another/redmine/path"
# roles definition
role :web, "your.redmine.org"
role :app, "your.redmine.org"
role :db, "your.redmine.org", :primary => true

# used on redmine install to load default data when installing
set :load_default_data, true

Edit local configuration example files (especially config/database.yml.example and put it a sqlite database to avoid mess with production database)

cap staging deploy:setup
GIT_TAG=<your-current-version> cap staging redmine:install

If everything runs fine login on the remote machine and start the staging installation with

cd <your staging path> && rails server

point your browser to http://your-server:3000 to see if everything works.

Fix any issue in this staging environment before doing the above procedure, if staging configuration works then the above should work either.

Prerequisites

In order to install Redmine from a local machine you should have ssh access to the host where to install, rvm installed on both machines, git installed on both machines and the following gems on your local machine:

• capistrano
• capistrano-ext
• capistrano-tags

Then you can clone my repository (which is a fork of the official redmine git mirror) on your local machine with

git clone git://github.com/fabn/redmine.git

Installation

Once you’ve cloned the repository you should define your deploy configuration by using one or more stage files in config/deploy/ folder inside redmine root. This is a minimal example of such file (named production.rb, the name will be useful later).

# roles definition, on single machine deployment all the roles are played by the same host
role :web, "redmine.example.org"
role :app, "redmine.example.org"
role :db, "redmine.example.org", :primary => true

# used on redmine install to load default data when installing
#set :load_default_data, false # default: true

# Customize here your start, stop and restart tasks if you need
# To use them you MUST deploy using explicit environment i.e. cap production redmine:upgrade
#namespace :deploy do
#  task :stop do
#    logger.important "Overridden"
#  end
#end

After you’ve created this file (it’s not included in the repository) your should edit redmine settings provided in .example files in the config folder, especially the database.yml.example file, all those files will be copied during the setup phase. Don’t change their names, simply edit them.

I don’t think that someone uses sqlite in production, anyway if you want to deploy with that db engine you MUST put your db files in the db/sqlite folder, otherwise they will NOT kept across different releases.

Then the first step on the remote machine is to prepare the environment for the installation, this could be achieved with the command

cap production deploy:setup

This command will prepare the typical capistrano structure under /var/rails/redmine (ensure your ssh user has write permission on /var/rails, otherwise capistrano will fail) on your remote machine adding some directories inside the shared folder and it will copy the yml files you’ve edited in the shared/config folder.

Now you should login on the remote machine and ensure that you’ve all the redmine dependencies installed, I choose to use rvm gemset to avoid mess in gem environment and to keep multiple projects with different dependencies installed on the same machine I used gemsets. So on the remote machine you must create a dedicated gemset called “redmine” and install redmine gems inside that gemset. This can be done with

rvm use 1.8.7@redmine --create
gem install rails -v=2.3.11
gem install i18n -v=0.4.2
gem install mysql # (or gem install sqlite3)

This should meet all redmine requirements, just check that your rvm installation has gem <= 1.5.0, if not you must downgrade it or you'll have problems.

Last manual task (optional), on the remote machine install your RM themes under shared/themes and your RM plugins under shared/plugins and you're ready to go with the installation.

To perform the installation just type the following command

cap production redmine:install

You'll be prompted to choose the tag to deploy (tested with 1.1.2 and 1.2.0) or leave it blank to deploy from master branch, you'll see a lot a screens and at the end RM is installed. I overridden the default capistrano start, stop and restart task because they are pretty obsolete, you have two choices here to handle redmine start and stop: starting it manually in your server, or redefine those tasks in your production.rb file (sample provided). A last note, if you want to deploy any < 1.2.0 RM version you should change the installed gems in the gemset or replacing the gemset with a different one because with 1.2 RM has moved to rails 2.3.11.

Upgrade

Now the funny part, suppose you've just deployed the 1.2 release and the 1.2.1 come out (or you want to switch to the devel version). Instead of doing all the manual steps listed here on your machine type the following command an it will do all that work for you

cap production redmine:upgrade

This task will upgrade the codebase in a new release folder, will symlink all the shared folders (files, logs, themes and plugins), will run the migrations (both for RM and plugins) and it will update the symlink. In a couple of minutes you're done.

Final Notes

I tried this procedures a dozen of times in my environment before publishing it and eventually I ran the update task against my production installation to upgrade it from 1.1.2 to 1.2 and everything has worked as expected, but this is experimental code, so try it at your own risk and most important backup, backup, backup.

If someone is interested I can write on how to import an existing RM installation into this structure, let me know in the comments and I'll update the post.

I just published the steps needed to import your existing installation.

Recently I started to exploring Ruby on Rails and one of the aspects I like of it is the ability to deploy projects using Capistrano an automated deployment tool. With Capistrano your deployment process (once configured the app) is simple as typing cap deploy, and if you make a mistake you can revert the things as before by just typing cap deploy:rollback, no more ssh, no more (s)ftp, nothing, just a command.

I tried to replicate this behavior also for Zend Framework projects and what I obtained is a brand new gem, named zend-framework-deploy. With this gem you can deploy ZF projects in the same manner of Rails ones. I developed a gem, because Ruby (and rails) are more extensible than php and I want to reuse existing capistrano code.

Installing the gem

So to use this technique you’ll need to install ruby and RubyGems. If you never did that, don’t worry it’s pretty simple with the right tools, just use Ruby Version Manager on any Unix platform. If you’re on Windows platform (aargh…) you can use Ruby Installer.

Once you have the gem command available in your shell type this command to install my gem

gem install zend-framework-deploy

and it will take care of anything, path setup, dependencies, etc.

Prepare the project

Now you can enable your project to be used with capistrano, to do that just use the bundled zf-capify executable provided

zf-capify /your/project/root
[add] writing '/your/project/root/application/configs/deploy.rb'
[add] writing '/your/project/root/Capfile'
[done] zf-capified!

The executable writes two files with the minimal settings to deploy your project, you can safely ignore the Capfile and just edit the deploy.rb file. It contains the capistrano variables to configure parameters for your deploy. This is the content of the generated file

set :application, "set your application name here"
set :repository,  "set your repository location here"
set :deploy_to, "set path where to deploy application"
set :zf_path, "set Zend Framework (remote) installation path here"

set :scm, :subversion
# Or: `accurev`, `bzr`, `cvs`, `darcs`, `git`, `mercurial`, `perforce`, `subversion` or `none`

role :web, "your web-server here"                          # Your HTTP server, Apache/etc

Just fill the strings with your parameters and you’re almost ready to make your first deploy, these are the meaning of various settings:

• application: the name of your app, try to avoid spaces in that
• repository: url of your repository
• deploy_to: base path on the remote server which will contain the application
• zf_path: remote path of Zend Framework release
• scm: source code management type (git, subversion, etc)
• role web: fill this with the dns name of your server

To test your configuration you should type this command in the root of your project

cap deploy:setup

It will try so ssh into your server and it will make the required directories for project deployment. If everything goes fine, next step is to make a deploy, you can do that by typing

cap deploy

This command will create a new folder under the releases directory in the deploy_to folder and it will checkout the content of your SCM head into. Then it will symlink the data folder in the project root and lastly it will symlink Zend Framework directories in the library folder. At this point you should have a working version of your zend framework application (if the exit code of the command is 0), to make it run point your webserver root to the deploy_to/current/public folder and you’re ok. (Please note that you still need to setup your database manually). Refer to the capistrano documentation for the full setup workflow and the structure of the deployment paths.

Following deployments

Once the setup is done, releasing a new version of your app is trivial, just cd (locally) in the root of the project and type cap deploy. The released project is automatically updated at the latest version present in your SCM. And if something goes wrong you can safely revert it to the previous state with cap deploy:rollback

I will explain the multistage configuration in a future article. Please post any problem in the comments and I’ll try to help you on solving that.

autoloadernamespaces[] = "Zle_"
pluginPaths.Zle_Application_Resource = "Zle/Application/Resource"

Then you’ll have to setup the application resource using the following directives

; notifier settings
resources.notifier.project = Project Name
resources.notifier.addresses[] = foo@example.com
resources.notifier.addresses[] = bar@example.com

This snippet of code attachs an email log writer to the log resource, so don’t forget to configure the log resource in application.ini file. The generated email will be sent using the default transport, so you’ll have to configure it otherwise the default transport (sendmail) would be used.

The default error controller will log any error with the CRIT priority, this will trigger the writer and send a message like this one to the given recipients:

You would like to avoid to receive notifications for a page not found (otherwise all the request generated by script kiddies would flood your inbox), in order to do this you can edit the default error controller to keep track of that in this way:

    public function errorAction()
    {
        $errors = $this->_getParam('error_handler');
        $logError = true;
        // skipped code
        switch ($errors->type) {
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ROUTE:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
            case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
                $logError = false;
        // other case for the switch
        // Log exception, if logger available
        if ($logError && $log = $this->getLog()) {
            $log->crit($this->view->message, $errors->exception);
        }

Last but not least, when you are in development or in testing mode you can avoid notifications by using this line in the right section of your application.ini

; disable notifier for development
resources.notifier.disabled = true

Per ovviare a questo inconveniente è possibile utilizzare i servizi messi a disposizione gratuitamente da Google per far si che le modifiche apportate ai propri dati siano riflesse in tempo reale su uno o sull’altro dispositivo in maniera semplice e trasparente senza dover collegare il telefono al computer via USB.

Per fare tutto ciò e necessario utilizzare il protocollo Exchange, disponibile su iOS a partire dalla versione 3.0, e il servizio Google Sync. Come primo passo è necessario disattivare la sincronizzazione dei calendari tramite iTunes dopo aver effettuato un’ultima sincronizzazione per garantire che siano presenti gli stessi dati si entrambi i dispositivi, per cui colleghiamo l’iPhone al Mac e dopo che la sincronizzazione è completata spuntiamo la casella “Sincronizza calendari iCal” e clicchiamo su “Applica” in tal modo verranno rimossi tutti i calendari dall’iPhone (tranquilli, verranno riaggiunti negli step successivi).

Ora colleghiamoci al nostro account di Google Calendar e creiamo gli stessi calendari che abbiamo in iCal tramite l’interfaccia di Google, inizialmente saranno vuoti (a meno che non usiate già Calendar).

Una volta fatto ciò è necessario accedere ai calendari creati tramite iCal, per fare questo andiamo sulle preferenze del programma ed aggiungiamo l’account di Google ai calendari attuali come nella schermata successiva, in tal modo verrà visualizzato in iCal il calendario principale.

Per visualizzare anche gli altri calendari aggiunti è sufficiente cliccare sulla scheda Delega nella pagina dell’account e spuntare i calendari a cui siamo interessati. Piccola nota, utilizzando questo approccio i calendari aggiuntivi appariranno nella categoria DELEGATI con una grafica non proprio accattivante, non ho trovato un modo per cambiare questa visualizzazione, se qualcuno conosce il modo mi farebbe piacere se lo scrivesse nei commenti.

A questo punto mancano due passi ancora per terminare, il trasferimento dei vecchi calendari da iCal a Google e l’impostazione dell’iPhone/iPod Touch/iPad. Per quanto riguarda il primo passo è disponibile una guida direttamente nell’help di Google Calendar. I passaggi indicati vanno ripetuti per ognuno dei calendari a cui siamo interessati, dopodiché i calendari originali, indicati nell’interfaccia di iCal nella categoria “SUL MIO MAC” andrebbero eliminati da iCal in modo da non visualizzare eventi doppi.

Passando alla parte finale della configurazione, la configurazione del dispositivo mobile, anche qui è presente un’ottima guida passo passo da parte di Google, in ogni caso la configurazione da fare è composta da pochi passi. È sufficiente andare sulle preferenze del telefono e nella voce “Mail, Contatti e Calendari” selezionare “Aggiungi account”; selezionare Exchange come tipo di account e inserire i dati del proprio account Gmail, lasciando la voce “Dominio” vuota. Nella schermata successiva inserire m.google.com alla voce “Server” e poi selezionare “Successivo” in alto a sinistra.

Infine selezionare i servizi da sincronizzare tramite l’account, il mio suggerimento è per il momento di attivare solamente la sincronizzazione dei calendari, in futuro esplorerò anche la modalità ottimale di sincronizzare i contatti, mentre per la posta preferisco decisamente IMAP a meno che uno non preferisca la modalità push, ma usando questo approccio ci sono alcune limitazioni che in IMAP non sono presenti, per cui preferisco non usarla.

A questo punto il più è fatto, ma al momento abbiamo solamente il calendario principale sincronizzato sul telefono, per farlo è necessario accedere alla pagina http://m.google.com/sync con il broswer dell’iPhone (in alternativa si può usare Safari sul Mac avendo l’accortezza di cambiare lo User Agent in “Safari Mobile 4.0.2″ attraverso il menù Sviluppo), comparirà una schermata che dice che il browser in uso non è supportato, ma in realtà basta cliccare su “Modifica lingua” e selezionare English (US) nella pagina successiva per arrivare al punto desiderato, ovvero quello mostrato nella schermata successiva.

Facendo il login si avrà a disposizione la lista dei propri dispositivi su cui si è impostata la sincronizzazione di tipo Exchange, cliccando sul dispositivo al quale si è interessati è possibile selezionare i calendari da sincronizzare ed il gioco è fatto.

Una nota sulle modalità di recupero dei dati, di default l’iPhone la imposta su Push, ovvero le modifiche fatte attraverso interfaccia web o tramite iCal diventano immediatamente visibili (a discapito però della batteria) mentre su iCal di default l’aggiornamento avviene ogni 15 minuti, quindi le modifiche (fatte dal telefono) non saranno immediatamente visibili. Entrambe queste impostazioni possono essere cambiate a piacimento dagli appositi menù.

Infine una nota dolente, i colori dei calendari su iPhone/iPad sono casuali, non ho trovato nessun modo di cambiarli. L’unica indicazione che ho trovato in giro suggerisce di disattivare e riattivare la sincronizzazione in quanto i colori vengono riassegnati (sempre in modalità random) e di ripetere la procedura fintanto ché non si trova una combinazione di colori che aggrada. Non mi sembra il massimo come soluzione, per cui se qualcuno trova un modo differente per risolvere questo piccolo problema è pregato di segnalarlo nei commenti.

Buona sincronizzazione.

Per l’installazione del plugin è sufficiente scaricare l’archivio contenente il generator e copiare il file BetterZipQL.qlgenerator contenuto al suo interno in /Library/QuickLook se lo si vuole installare per tutti gli utenti del sistema oppure in ~/Library/QuickLook se lo si vuole solamente per l’utente corrente.

Una volta installato per far si che sia attivo bisogna aspettare qualche minuto che QuickLook si accorga del nuovo generator oppure forzarne il caricamento con il comando qlmanage -r.

Il risultato che si avrà quando si preme la barra su di un archivio è questo

Infine un sito che raccoglie una vasta lista di plugin aggiuntivi per QuickLook: http://www.quicklookplugins.com/

Purtroppo tale comando non è presente di default in Mac OS X, per averlo a disposizione si può installare il gestore di pacchetti MacPorts, ma chi non volesse installarlo può sempre avere a disposizione questo comando installando il binario tramite sorgenti. Per fare ciò sono sufficienti pochi comandi per scaricare i sorgenti

curl -O ftp://mama.indstate.edu/linux/tree/tree-1.5.3.tgz
tar xzvf tree-1.5.3.tgz
cd tree-1.5.3/

Fatto ciò è necessario cambiare il Makefile per compilare il programma per Mac commentando queste righe relative a Linux

# Linux defaults:
#CFLAGS=-ggdb -Wall -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
#CFLAGS=-O2 -Wall -fomit-frame-pointer -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
#LDFLAGS=-s

ed decommentando queste relative a Mac

# Uncomment for OS X:
CC=cc
CFLAGS=-O2 -Wall -fomit-frame-pointer -no-cpp-precomp
LDFLAGS=
XOBJS=strverscmp.o

Alla fine è sufficiente compilare ed installarlo nel path di sistema con i comandi

make
sudo make install

ed il comando sarà a disposizione anche su Mac.

Ho appena perso un disco da 500 GB con al suo interno una partizione piena circa al 50%, il disco ha cominciato improvvisamente a manifestare chiari problemi sia in lettura sia in scrittura, per cui prima che si rompesse del tutto ho voluto eseguire una copia dei dati al suo interno. Chiaramente la copia dal filesystem risultava impossibile per via degli errori restituiti dal dispositivo, per cui ho preso un nuovo disco della stessa capacità ed ho avviato il fido ddrescue.

Dopo circa 1 giorno il contenuto del disco era stato copiato quasi del tutto poco meno dei 500GB totali (ddrescue copia tutti i settori del dispositivo, indipendentemente dal filesystem, per cui sono stati copiati anche i blocchi vuoti) , ma mancavano circa 70MB che restituivano errori in lettura. Ho avviato la seconda passata di ddrescue con le opzioni -d e -r 2 per tentare il recupero di questi ulteriori 70 MB ed ho lasciato andare per circa 3 giorni. Quando mancavano solamente 11MB (ma purtroppo sparsi in 12000 settori differenti) anche ddrescue si è arreso e rimanevano questi dati non copiati. Una volta montato il filesystem recuperato il problema a questo punto era capire quali file erano integri e quali no, infatti leggendo il log prodotto da ddrescue si poteva leggere quanto segue

# Rescue Logfile. Created by GNU ddrescue version 1.11
# current_pos  current_status
0x14E248400     -
#      pos        size  status
0x00000000  0x0FD49800  +
0x0FD49800  0x00000400  -
0x0FD49C00  0x0000FA00  +
0x0FD59600  0x00000600  -
0x0FD59C00  0x000B4E00  +
0x0FE0EA00  0x00000200  -
0x0FE0EC00  0x0000F200  +
0x0FE1DE00  0x00000200  -
0x0FE1E000  0x00000200  +
0x0FE1E200  0x00000400  -
0x0FE1E600  0x000B4E00  +
0x0FED3400  0x00000400  -
0x0FED3800  0x0000F000  +
0x0FEE2800  0x00000600  -
0x0FEE2E00  0x000C4000  +

In questo log ad ogni – sulla terza colonna corrisponde una parte di disco non recuperata che inizia all’indirizzo nella prima colonna e la cui lunghezza in bytes è espressa nella seconda colonna. Praticamente nel disco mancavano blocchetti di pochi bytes (in media 400) in 11000 indirizzi diversi il che indica che è, da un punto di vista probabilistico, impossibile che tutti i file siano stati recuperati correttamente.

Per stabilire con certezza quali file siano corrotti ho utilizzato la modalità fill di ddrescue. La prima cosa da fare è quella di montare il filesystem recuperato (se si ha la possibilità meglio eseguire tutte le operazioni su un’ulteriore copia) in modalità readonly e calcolare i checksum dei file presenti nel dispositivo. Nel mio caso il disco recuperato era sdc per cui ho eseguito questi comandi allo scopo

# mount-o ro /dev/sdc1 /mnt/rescued
# find /mnt/rescued/ -type f -print0 | xargs -0 -n 1 md5sum >> rescued.md5.txt

In questo modo ho salvato tutti i checksum dei file presenti nella partizione /dev/sdc1 nel file rescued.md5.txt. Questo comando a seconda della dimensione totale dei files può richiedere parecchio, nel mio caso circa 2 ore e mezza. A questo punto ho invocato nuovamente ddrescue in modalità fill in modo da riempire tutti i buchi presenti nell’hard disk con una stringa fissa, in modo da cambiare l’md5 dei file coinvolti. La funzione md5 ci garantisce che anche cambiando un solo bit in un file l’hash generato cambia radicalmente per cui il rischio che un file mantenesse lo stesso hash era praticamente zero (è molto più probabile vincere al superenalotto…). Per riempire i blocchi danneggiati ho eseguito i seguenti comandi

# umount /dev/sdc1
# echo -n "BAD SECTOR " > tmpfile
# ddrescue --fill=- tmpfile /dev/sdc rescued.log

Questa operazione è molto veloce in quanto avviene su un disco funzionante, per cui in meno di un minuto ddrescue ha completato il suo lavoro. A questo punto non resta che rimontare il filesystem e verificare quali file sono cambiati su disco, per fare ciò sono sufficiente questi comandi.

# mount -o ro /dev/sdc1 /mnt/rescued
# md5sum -c rescued.md5.txt > checklist.txt

Passate altre 2 ore e mezza circa la lista è pronta, basta leggere il file checklist.txt per capire quali file sono integri e quali no, infatti il contenuto del file è all’incirca questo

/mnt/rescued/IMG_0096.JPG: OK
/mnt/rescued/IMG_0247.jpg: OK
/mnt/rescued/IMG_0249.jpg: FAILED
/mnt/rescued/IMG_0253.jpg: OK
/mnt/rescued/IMG_0256.jpg: OK
/mnt/rescued/IMG_0482.JPG: OK
/mnt/rescued/IMG_0485.JPG: OK
/mnt/rescued/IMG_0486.JPG: OK
/mnt/rescued/IMG_0487.JPG: OK
/mnt/rescued/IMG_0489.JPG: OK
/mnt/rescued/IMG_0490.JPG: FAILED
/mnt/rescued/IMG_0491.JPG: FAILED
/mnt/rescued/IMG_0492.JPG: FAILED
/mnt/rescued/IMG_0493.JPG: FAILED

In alternativa si possono costruire le liste dei file integri e di quelli rovinati utilizzando grep in questo modo

# grep OK$ checklist.txt > files.ok.txt
# grep FAILED$ checklist.txt > files.bad.txt

• RAID hardware: disponibile sui server di fascia alta, è quello che offre forse le migliori performance in quanto le operazioni vengono eseguite tutte dal controller in maniera completamente trasparente, ma ha sicuramente i costi più elevati. Inoltre utilizzando questa tipologia di raid i dati sono legati al controller utilizzato e non possono essere utilizzati ad esempio in un’altra macchina senza che si utilizzi lo stesso controlloer
• FAKERAID: ovvero RAID hardware a basso costo. Questa è la tecnologia che viene usata sui controller di fascia bassa oppure implementata nelle motherboard dei computer desktop. Questa tecnologia viene chiamata fakeraid in quanto non è un RAID vero e proprio ma una parte dell’implementazione e della computazione viene lasciata alla CPU e l’interfacciamento con i dati avviene tramite un driver. Qui le performance sono decisamente più basse e rimane il problema del trasporto dei dati da un sistema all’altro. Inoltre non è detto che il driver di questi controller sia disponibile per tutti i sistemi operativi.
• RAID software: quello di cui discuteremo qui. Il maggiore vantaggio di questa tecnologia è il controllo assoluto sui propri dati, si possono aggiungere e rimuovere dispositivi a piacere e soprattutto si possono trasferire da una macchina all’altra. Inoltre è possibile eseguire le operazioni di manutenzione a sistema attivo, cosa che non è possibile negli altri due casi in cui è richiesto un reboot.

Per questo tutorial utilizzerò una macchina virtuale in modo da poter aggiungere dischi a piacimento e simulare la rottura di un disco rimuovendolo dalla macchina virtuale. Il sistema operativo di questa macchina virtuale è Ubuntu 9.10, ma i comandi ed i pacchetti utilizzati sono gli stessi che si utilizzerebbero su Debian. L’unico pacchetto che va installato per poter creare e manipolare array di dischi è il pacchetto mdadm che mette a disposizione l’omonimo comando.

Per creare un array di dischi a utilizzando il RAID5 sono necessari almeno 3 dischi/partizioni della stessa dimensione. Degli N dischi utilizzati uno di essi è utilizzato come codice di controllo in maniera circolare, per cui lo spazio effettivo a disposizione nell’array risultante sarà pari ad (n-1) * disksize. Il livello di fault tolerance offerto da questa soluzione è di un disco, ovvero il sistema rimane in funzione ed i dati rimangono integri se si danneggia fino ad un disco, in caso di rottura di più di un disco contemporaneamente i dati sono irrimediabilmente persi. Se si hanno più dischi a disposizione si può configurare uno di essi come spare disk, ovvero come disco di emergenza. Nel caso di rottura di un disco esso verrà rimpiazzato automaticamente dal disco di riserva ottenendo quindi una fault tolerance pari a 2 dischi.

Nella macchina virtuale di esempio verranno utilizzati 3 dischi da 3GB per la configurazione iniziale che porteranno quindi ad un array di dimensione 6GB.

Creazione delle partizioni

Una volta aggiunti i dischi alla macchina virtuale essi appaiono come dispositivi vuoti, quindi come prima cosa vanno partizionati per poter essere utilizzati come membri di array. Il tipo di partizione per il RAID è fd, per cui utilizzando fdisk la sequenza di comandi da utilizzare per ognuno dei 3 dischi è la seguente:

root@fabio-laptop-ubuntu:/# fdisk /dev/sdb
Il dispositivo non contiene né una tabella delle partizioni DOS valida, né una disklabel Sun, SGI od OSF
Building a new DOS disklabel with disk identifier 0xd90f450c.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Attenzione: il flag 0x0000 non valido della tabella delle partizioni 4 verrà corretto con w(rite)

Comando (m per richiamare la guida): n
Azione comando
   e   estesa
   p   partizione primaria (1-4)
p
Numero della partizione (1-4): 1
Primo cilindro (1-391, predefinito 1):
Utilizzo del valore predefinito 1
Last cilindro, +cilindri or +size{K,M,G} (1-391, predefinito 391):
Utilizzo del valore predefinito 391

Comando (m per richiamare la guida): t
Partizione selezionata 1
Codice esadecimale (digitare L per elencare i codici): fd
Modificato il tipo di sistema della partizione 1 in fd (Autorilevamento raid di Linux)

Comando (m per richiamare la guida): w
La tabella delle partizioni è stata alterata!

Chiamata di ioctl() per rileggere la tabella delle partizioni.
Sincronizzazione dei dischi in corso.

Il procedimento va ripetuto per tutti e tre i dischi in modo da prepararli per la costruzione dell’array. Una volta create le partizioni dopo aver creato le partizioni per tutti i dischi interessati si dovrebbe avere questo output digitando il comando fdisk -l

Disco /dev/sdb: 3221 MB, 3221225472 byte
255 testine, 63 settori/tracce, 391 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Identificativo disco: 0x00000000

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         391     3140676   fd  Autorilevamento raid di Linux

Disco /dev/sdc: 3221 MB, 3221225472 byte
255 testine, 63 settori/tracce, 391 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Identificativo disco: 0xd90f450c

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         391     3140676   fd  Autorilevamento raid di Linux

Disco /dev/sdd: 3221 MB, 3221225472 byte
255 testine, 63 settori/tracce, 391 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Identificativo disco: 0x171338f5

Dispositivo Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         391     3140676   fd  Autorilevamento raid di Linux

Creazione dell’array

Come accennato in precedenza tutte le operazioni vengono eseguite con il comando mdadm. Per vedere le opzioni a disposizione vedere la relativa pagina di manuale, in ogni caso per creare il volume è sufficiente eseguire il comando

root@fabio-laptop-ubuntu:/# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 64K
mdadm: size set to 3140608K
mdadm: array /dev/md0 started.

In questo modo si è creato ed avviato il device /dev/md0 che può essere utilizzato come una normale partizione in modo del tutto trasparente. Per controllare che il device sia stato utilizzato correttamente basta eseguire

root@fabio-laptop-ubuntu:/# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      6281216 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Se l’array è stato creato correttamente siamo a posto, ma dobbiamo fare in modo che esso venga avviato all’avvio del sistema operativo. Per fare ciò dobbiamo editare (o creare) il file mdadm.conf che normalmente dovrebbe trovarsi in /etc, ma in Ubuntu si trova in /etc/mdadm/mdadm.conf. Per i dettagli relativi a tale file consultare la pagina di manuale relativa (ovvero mdadm.conf). In ogni caso l’opzione che va inserita per caricare all’avvio l’array appena creato è ARRAY. Per ottenere automaticamente il contenuto di tale opzione è sufficiente eseguire il comando

root@fabio-laptop-ubuntu:/# mdadm --examine --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=c5a20602:9985ece9:11a1047a:ce03a3ef

L’output generato da tale comando è la linea che dobbiamo inserire nel file di configurazione. Un’altra opzione utile da considerare in tale file è MAILADDR ovvero l’indirizzo di posta a cui il demone mdadm invierà le email per segnalare eventuali anomalie nel sistema. Su Ubuntu/Debian il programma mdadm viene avviato automaticamente all’avvio del sistema, su altre distribuzioni potrebbe essere necessario aggiungere uno script in init.d a tale scopo. Infine un’ultima opzione che consiglio di lasciare al valore di default è DEVICE. Questa opzione indica a mdadm in quali device deve ricercare partizioni di tipo fd. Il valore di default è partitions, ovvero tutte le partizioni elencate in /proc/partitions. Utilizzando questo valore invece che la lista esplicita delle partizioni di tipo RAID non si rischia di dimenticare nessuna partizione che potrebbe contenere una parte di array.

Finito di editare il file mdadm.conf riavviamo il sistema e controlliamo al riavvio attraverso il file /proc/mdstat che l’array sia stato inizializzato correttamente (ovvero che si abbia lo stesso output avuto in precedenza).

Se tutto è andato a buon fine si può cominciare ad utilizzare il device creando un filesystem su di esso. Ad esempio per creare un filesystem di tipo ext3 con il seguente comando

root@fabio-laptop-ubuntu:/home/fabio# mkfs.ext3 /dev/md0
mke2fs 1.41.9 (22-Aug-2009)
Etichetta del filesystem=
Tipo SO: Linux
Dimensione blocco=4096 (log=2)
Dimensione frammento=4096 (log=2)
393216 inode, 1570304 blocchi
78515 blocchi (5.00%) riservati per l'utente root
Primo blocco dati=0
Maximum filesystem blocks=1610612736
48 gruppi di blocchi
32768 blocchi per gruppo, 32768 frammenti per gruppo
8192 inode per gruppo
Backup del superblocco salvati nei blocchi:
	32768, 98304, 163840, 229376, 294912, 819200, 884736

Scrittura delle tavole degli inode: fatto
Creating journal (32768 blocks): fatto
Scrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fatto

Questo filesystem verrà automaticamente controllato ogni 25 mount, o
180 giorni, a seconda di quale venga prima. Usare tune2fs -c o -i per cambiare.

Fault tolerance in RAID5

Vediamo ora cosa succede disconnettendo un disco dalla macchina virtuale, simulando così la rottura di un disco. Per verificare l’integrità dei dati nella partizione costruita sul RAID ho creato alcuni files dal contenuto casuale (con il comando dd if=/dev/urandom of=testfile bs=1MB count=100) e ne ho salvato l’md5 in un file di testo.

Spegnendo la macchina virtuale ed eliminando un disco al successivo riavvio l’array non verra’ montato e, se configurata la variabile MAILADDR in mdadm.conf ci arriverà un messaggio di posta che ci avvisa che l’array è degradato. Sarà comunque possibile avviare l’array utilizzando il seguente comando ed i verificare che i dati sono integri e disponibili

root@fabio-laptop-ubuntu:/mnt/raid# mdadm -As
mdadm: /dev/md0 has been started with 2 drives (out of 3).
root@fabio-laptop-ubuntu:/mnt/raid# mount /mnt/raid
root@fabio-laptop-ubuntu:/mnt/raid# md5sum -c md5
testfile: OK
testfile1: OK
testfile2: OK
testfile3: OK

Chiaramente questo è molto pericoloso in quanto se si dovesse rovinare un altro disco sarebbe tutto irrimediabilmente perso (ed inoltre le performance sono ridotte all’osso in quanto i dati del disco mancante sono calcolati a partire dagli altri 2). Per cui il passo successivo è quello di rimpiazzare al più presto il disco mancante e ricostruire l’array. Inserendo un nuovo disco per sostituire il precedente e partizionandolo come in precedenza (quindi sempre come /dev/sdd1), sarà sufficiente eseguire il seguente comando per ricostruire l’array e tornare operativi e coperti da eventuali ulteriori guasti:

root@fabio-laptop-ubuntu:/mnt/raid# mdadm /dev/md0 --add /dev/sdd1
mdadm: added /dev/sdd1

A questo punto l’array verrà ricostruito automaticamente come si può verificare con il comando

root@fabio-laptop-ubuntu:/mnt/raid# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdb1[0] sdc1[1]
      6281216 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
      [>....................]  recovery =  4.9% (154624/3140608) finish=2.2min speed=22089K/sec

unused devices: <none>

Aggiunta di un nuovo disco all’array

Nello stesso modo in cui si sostituisce un disco/partizione che ha fallito è possibile aggiungere un nuovo device all’array nel caso in cui fossimo a corto di spazio. Per cui una volta inserito il nuovo disco nella macchina si può aggiungere all’array con il comando

root@fabio-laptop-ubuntu:/mnt/raid# mdadm /dev/md0 --add /dev/sde1
mdadm: added /dev/sde1

In questo modo si è aggiunto il disco all’array ma allo stato attuale delle cose il nuovo disco viene considerato come disco di spare, ovvero come disco di emergenza da usare in caso di fallimento di un altro disco. Per aggiungere questo dispositivo allo spazio effettivamente disponibile bisogna utilizzare un altro comando con il quale si ingrandisce l’array.

root@fabio-laptop-ubuntu:/mnt/raid# mdadm --grow /dev/md0 --raid-devices=4
mdadm: Need to backup 384K of critical section..
mdadm: ... critical section passed.

Anche qui si può controllare lo stato della ricostruzione dell’array con il comando

root@fabio-laptop-ubuntu:/mnt/raid# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sde1[3] sdb1[0] sdd1[2] sdc1[1]
      6281216 blocks super 0.91 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      [>....................]  reshape =  2.5% (79680/3140608) finish=3.8min speed=13280K/sec

unused devices: <none>

Dopo che si è aggiunto il disco però è necessario un altro passo, ovvero l’estensione del filesystem, altrimenti non otterremmo nessun beneficio nell’aver aggiunto ulteriore spazio. Nel caso di ext3 questa operazione può essere eseguita al volo con il comando

root@fabio-laptop-ubuntu:/mnt/raid# resize2fs /dev/md0
resize2fs 1.41.9 (22-Aug-2009)
Filesystem at /dev/md0 is mounted on /mnt/raid; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/md0 to 2355456 (4k) blocks.
The filesystem on /dev/md0 is now 2355456 blocks long.

Per far si che le foto vengano mostrate sulla mappa è necessario però che le immagini contengano i dati GPS negli appositi campi EXIF. Questo può essere ottenuto in vari modi, ad esempio iPhone, essendo dotato di un modulo GPS interno, inserisce automaticamente tali dati nelle proprie foto. Altre macchine fotografiche di fascia medio alta hanno integrato un sensore GPS oppure dispongono di un interfaccia hardware per collegare un ricevitore esterno, normalmente questo comporta una spesa aggiuntiva che con un iPhone ed un po di sforzo possiamo evitare.

Il metodo che descriverò ora funziona con qualsiasi macchina fotografica, anzi in realtà con qualsiasi immagine. È richiesto solamente un po di lavoro da eseguire tramite riga di comando per taggare correttamente le proprie foto. Basta utilizzare uno dei tanti software disponibili per iPhone per registrare i propri percorsi in formato GPX. Io mi sono trovato bene con il software EveryTrail che è un software gratuito, ma esistono moltissime alternative su AppStore.

Una volta scaricato il software e necessario creare un account (gratuito anch’esso) sul sito di EveryTrail per poter caricare i propri percorsi tramite iPhone. Una volta che si è creato l’account è possibile visualizzare i propri percorsi registrati con l’applicazione.

Per cui nel momento in cui si inizia a scattare ricordatevi di avviare l’applicazione e tenetela attiva sul telefono. In caso di arrivo di una chiamata l’applicazione va in pausa ed è sempre possibile riprendere in seguito il percorso iniziato in precedenza. Quando avete terminato di scattare eseguite l’upload del percorso, cliccate sul link che vi arriva per email e scaricate il file gpx con i dati GPS registrati.

Sincronizzazione e geotag con exiftool

Le operazioni da eseguire per effettuare il geotag possono essere eseguite utilizzando exiftool. Il programma, una volta installato, mette a disposizione da riga di comando l’eseguibile exiftool, la cui pagina di manuale si trova qui. Il programma è uno strumento molto potente da utilizzare a riga di comando. Negli esempi seguenti utilizzerò le opzioni che vanno a sovrascrivere i file originali che sono

  -P          (-preserve)          Preserve date/time of original file
  -overwrite_original_in_place     Overwrite original by copying tmp file

Nel caso in cui si esegua qualche esperimento è il caso di non utilizzare tali opzioni,  in quanto con esse i file originali vengono sostituiti e non c’è modo di recuperarli.

Indipendentemente da come si è ottenuto il file con i dati gps la cosa più importante da verificare è la sincronizzazione tra gli orari delle immagini e quelli indicati nel file con le coordinate gps. La cosa migliore da fare è di sincronizzare il proprio iPhone e la propria camera prima di cominciare, possibilmente con una precisione al secondo. Se questo non è possibile o ce ne siamo semplicemente dimenticati (come è successo a me) è possibile cambiare la data di scatto nei dati EXIF.

La prima cosa da fare è quella di calcolare l’offset tra il tempo di scatto ed il tempo esatto, nel mio caso l’orario della macchinetta era completamente sballato (di circa una settimana) per cui ho dovuto cambiare completamente data ed ora. Per eseguire questa procedura ho eseguito una fotografia al display del telefono in modo da avere sul file la data di scatto memorizzata dalla macchinetta e nell’immagine il tempo registrato dall’iPhone. Confrontando i dati ho ottenuto una differenza di tempo pari ad 8 giorni, 13 ore 44 minuti e 24 secondi, per cui facendo riferimento a questa pagina di manuale riguardante lo shift di tempi e date la sintassi da utilizzare con exiftool è

exiftool -P -overwrite_original_in_place -DateTimeOriginal+='8 13:44:24' -createdate+='8 13:44:24' *.JPG
   22 image files updated

Ora che la data del file è corretta è possibile utilizzare il file gpx per assegnare la localizzazione ad ogni foto, il comando per fare ciò è il seguente

exiftool -geotag geodata.gpx -P -overwrite_original_in_place *.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1263.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1264.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1265.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1266.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1267.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1268.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1269.JPG
Warning: Time is too far before track in File:Geotime (ValueConvInv) - DSCF1270.JPG
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - DSCF1281.JPG
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - DSCF1282.JPG
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - DSCF1283.JPG
Warning: Time is too far beyond track in File:Geotime (ValueConvInv) - DSCF1284.JPG
   10 image files updated
   12 image files unchanged

Come si vede nel caso in cui  alcune immagini non rientrino nell’intervallo temporale dei dati gps, exiftool ce lo segnala con un warning e lascia i file in questione invariati. Alla fine di questo processo potete importare le foto in iPhoto ed esse compariranno sulla mappa in “Luoghi”.