• 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”.

Per ottenere le icone in questo formato ho trovato un paio di trucchetti che non sono niente male. Il primo metodo per creare icone in questo formato a partire da un file grafico esistente è quello di utilizzare il sito IConvert. Il sito è di utilizzo immediato, si carica un file grafico ed una volta terminato l’upload si ha la possibilità di scaricare il file convertito in numerosi formati tra cui icns.

Il secondo metodo consiste nell’utilizzare il programma img2icns scaricabile da questo sito. Anche questo metodo risulta di immediato utilizzo, si apre il programma, si trascina all’interno della finestra principale l’immagine da convertire e si salva il file tramite il pulsante apposito. Il programma offre anche la possibilità di esportare l’immagine come cartella, come icona per iPhone o come favicon per i propri siti, ma questi due ultimi formati richiedono la versione pro a pagamento.

Infine un ultimo metodo che ho trovato molto utile per creare icone a partire da icone esistenti. Supponiamo che vogliate creare un file icns a partire da una cartella o da un’applicazione in vostro possesso. In tal caso ho trovato un metodo molto efficace per Snow Leopard in questo post. Il metodo descritto nel post dovrebbe funzionare per chi ha ancora Leopard, ma in SL sembra che l’utility icnsBrowser non ci sia più. In ogni caso trovo molto più efficace il metodo descritto nell’ultimo commento, in pratica partendo dalla cartella (o applicazione) della quale si vuole l’icona si apre il pannello delle informazioni del finder (clic destro e Ottieni Informazioni oppure Comando (⌘)-I dopo aver selezionato l’elemento). Nel pannello fare clic sull’icona di interesse in alto a sinistra affinché questa venga evidenziata, dopo di che premere Comando (⌘)-C per copiare l’icona. A questo punto apriamo Anteprima (Preview) e premiamo Comando (⌘)-N per creare l’icona a partire dal contenuto degli appunti.

Abbiamo la nostra icona in formato icns visualizzata in Anteprima, ma se proviamo a salvare non risulta possibile. Per avere il file però è sufficiente “chiudere” i vari elementi nella barra laterale di Anteprima utilizzando la freccia nera a destra e trascinare in una cartella qualsiasi del finder l’oggetto risultante ed esso verrà salvato come icona nel punto di rilascio, provare per credere.

A differenza del programma Istantanea, utilizzando le combinazioni di tasti non è possibile decidere dove saranno salvate le immagini prodotte, queste saranno registrate tutte sul Desktop. In alcuni casi può essere desiderabile cambiare la posizione di default per mantenere un pò di ordine sulla propria scrivania.

In questo caso ci viene incontro il terminale, infatti è sufficiente un semplice comando per cambiare la directory dove salvare le screenshot. In particolare è sufficiente aprire il terminale (sempre dalla cartella Utility in Applicazioni) e digitare il seguente comando

defaults write com.apple.screencapture location /Users/fabio/Pictures

In questo caso ho impostato come directory di salvataggio la cartella Immagini nella mia home, chiaramente l’ultimo argomento del comando è quello che determina la posizione dove saranno salvate le immagini d’ora in poi.

Per rendere effettiva la modifica riavviamo il server grafico (per evitare un logout o un riavvio) con il comando

killall SystemUIServer

A questo punto se eseguiamo una screenshot con una delle shortcut disponibili l’immagine sarà salvata nella directory scelta e non più nel Desktop.

Per completezza riporto quali sono le scorciatoie da tastiera disponibili per i vari tipi di screenshot che si possono eseguire:

Per utilizzare questa comoda funzionalità messa a disposizione da Zend Framework, è sufficiente inserire queste righe nel file di configurazione dell’applicazione

resources.db.params.profiler.enabled = true
resources.db.params.profiler.class = Zend_Db_Profiler_Firebug

Per ovvi motivi queste direttive vanno abilitate solamente nella sezione development del file di configurazione, a meno che non vogliate far sapere a tutto il mondo quali sono le query che eseguite sul database.

Il risultato che si ottiene su Firefox è il seguente:

Dati restituiti dal profiler per Firebug

Come molti sapranno PHP è un linguaggio interpretato, questo fa si che ad ogni singola richiesta di una pagina web, l’interprete PHP debba leggere il codice nei files memorizzati su disco, valutarne la correttezza, trasformarlo in istruzioni eseguibili, trasformare i nomi di variabili e funzioni in indirizzi di memoria, ed eseguire le istruzioni specificate.

Inoltre per chi fa uso di framework o librerie particolarmente corpose, c’è l’overhead dovuto alle dozzine di files contenuti in queste librerie. Per esempio Zend Framework è composto da più di 2500 files, e spesso e volentieri per istanziare un singolo oggetto di una data classe è necessario che l’interprete legga decine di files.

Files caricati da Zend Framework

L’applicazione di prova dell’articolo su ZFDebug necessita di 110 files (circa 1MB) solamente per caricare l’home page.

Proprio in casi come questi ci viene incontro APC, infatti questa estensione crea un file mappato in memoria (praticamente una porzione di RAM salvata su filesystem) che viene condivisa tra tutte le richieste al webserver, dove mantiene una copia cache di tutti i files caricati durante l’esecuzione degli script.

In questo modo, fatta eccezione per la prima richiesta, i tempi di risposta avranno uno speedup notevole in quanto l’interprete non dovrà più leggere i files da disco ma se li ritroverà automaticamente caricati in memoria.

Installazione e configurazione

Per installare questa estensione su una macchina Debian/Ubuntu è sufficiente eseguire il comando

aptitude install php-apc

In alternativa è possibile installarla utilizzando PECL oppure compilando a mano l’estensione e caricandola con il file php.ini con la riga

extension=apc.so

Per quanto riguarda la configurazione, in linea di massima va bene quella di default che prevede 1 segmento di memoria condivisa di dimensione pari a 30MB, ed abilita la cache di tutti i files php ed inc di dimensione inferiore al Megabyte.

Su una macchina in produzione può essere molto producente l’opzione apc.stat con la quale si indica all’estensione di non controllare per i files in cache se sono cambiati su disco. Questa infatti è un’operazione abbastanza onerosa, in quanto richiede per ogni file un controllo sul filesystem. Chiaramente questo settaggio va usato con molta cautela, in quanto la cache non viene svuotata sino ad un riavvio del webserver, per cui eventuali modifiche effettuate ad uno script non saranno visibili se questo si trova in cache.

Un’altra opzione che può tornare utile cambiare è apc.enable_cli, che rende disponibile la cache dei files anche negli script a riga di comando. Per default questa opzione è disattivata, quindi non si ha la cache attiva negli script a riga di comando.

Per una trattazione completa delle opzioni, del loro significato e dei valori di default si può vedere la pagina relativa.

Benchmark

Per misurare l’aumento di prestazioni che si ha installando sul proprio webserver l’estensione APC, ho utilizzato il tool Apache Benchmark. Questo strumento misura i tempi di risposta di un sito web e determina il numero massimo di richieste al secondo che la vostra installazione di Apache può gestire. Per ottenere un risultato indipendente da eventuali congestioni di rete le prove sono state eseguite in locale come spesso viene consigliato, per cui la singola sessione di benchmark è stata lanciata eseguendo il comando

ab -c 30 -n 1000 http://localhost/zfqs/

Ovvero ho detto ad ab di eseguire 1000 richieste lanciandone al più 30 in parallelo sulla home page del progetto dell’articolo di ZFDebug, che come detto in precedenza carica 110 files per mostrare la home page.

Il benchmark è stato eseguito in tre situazioni distinte:

1. Estensione apc non caricata
2. Estensione apc caricata con opzione stat=1 (default)
3. Estensione apc caricata con opzione stat=0

E questi sono i risultati ottenuti:

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)

Server Software:        Apache/2.2.9
Server Hostname:        localhost
Server Port:            80

Document Path:          /zfqs/
Document Length:        24269 bytes

Concurrency Level:      30
Time taken for tests:   67.103 seconds
Complete requests:      1000
Failed requests:        182
   (Connect: 0, Receive: 0, Length: 182, Exceptions: 0)
Write errors:           0
Total transferred:      24717294 bytes
HTML transferred:       24268294 bytes
Requests per second:    14.90 [#/sec] (mean)
Time per request:       2013.098 [ms] (mean)
Time per request:       67.103 [ms] (mean, across all concurrent requests)
Transfer rate:          359.71 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       2
Processing:   984 2004 228.3   2001    3384
Waiting:      957 1874 221.8   1865    3209
Total:        984 2004 228.3   2001    3386

Percentage of the requests served within a certain time (ms)
  50%   2001
  66%   2078
  75%   2125
  80%   2159
  90%   2239
  95%   2321
  98%   2412
  99%   2740
 100%   3386 (longest request)

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)

Server Software:        Apache/2.2.9
Server Hostname:        localhost
Server Port:            80

Document Path:          /zfqs/
Document Length:        24263 bytes

Concurrency Level:      30
Time taken for tests:   22.696 seconds
Complete requests:      1000
Failed requests:        753
   (Connect: 0, Receive: 0, Length: 753, Exceptions: 0)
Write errors:           0
Total transferred:      24714238 bytes
HTML transferred:       24265238 bytes
Requests per second:    44.06 [#/sec] (mean)
Time per request:       680.882 [ms] (mean)
Time per request:       22.696 [ms] (mean, across all concurrent requests)
Transfer rate:          1063.40 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       2
Processing:   198  678 144.2    673    1449
Waiting:      184  639 142.5    640    1444
Total:        198  678 144.1    673    1449

Percentage of the requests served within a certain time (ms)
  50%    673
  66%    722
  75%    752
  80%    778
  90%    846
  95%    916
  98%   1001
  99%   1101
 100%   1449 (longest request)

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)

Server Software:        Apache/2.2.9
Server Hostname:        localhost
Server Port:            80

Document Path:          /zfqs/
Document Length:        24267 bytes

Concurrency Level:      30
Time taken for tests:   18.690 seconds
Complete requests:      1000
Failed requests:        866
   (Connect: 0, Receive: 0, Length: 866, Exceptions: 0)
Write errors:           0
Total transferred:      24713251 bytes
HTML transferred:       24264251 bytes
Requests per second:    53.50 [#/sec] (mean)
Time per request:       560.712 [ms] (mean)
Time per request:       18.690 [ms] (mean, across all concurrent requests)
Transfer rate:          1291.25 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2  11.5      0      77
Processing:    80  555 152.3    549    1247
Waiting:       75  519 150.7    516    1223
Total:         80  557 153.6    550    1247

Percentage of the requests served within a certain time (ms)
  50%    550
  66%    588
  75%    621
  80%    648
  90%    742
  95%    821
  98%    946
  99%   1091
 100%   1247 (longest request)

I risultati parlano da soli e sono veramente notevoli, in ogni caso ho evidenziato i valori più importanti

• Numero di richieste gestite al secondo da Apache
• Tempo medio per l’esecuzione di una richiesta (in concorrenza)
• Tempo massimo per servire una richiesta

Questi tre valori cambiano nel seguente modo nei tre casi analizzati

Uso di APC come cache a livello utente

Un altro uso che può tornare molto utile di questa estensione è il caching dei dati applicazione. In alcune operazioni l’uso della cache può portare notevoli benefici in termini di velocità, ad esempio quando si eseguono query molto complesse su un database il cui risultato cambia molto raramente nel tempo, oppure quando si caricano dati da un webservice esterno. In tali casi si può memorizzare il dato calcolato in cache attraverso l’uso delle funzioni apposite, e, alla successiva esecuzione dello script verificare se il dato è presente in cache; in caso affermativo, si può restituire il dato preso dalla cache senza il bisogno di rieseguire il calcolo.

Apc può essere usata anche come  backend del componente Zend_Cache. Nei miei progetti in ZF utilizzo sempre il seguente codice in produzione, per evitare di ricaricare i metadati relativi alla struttura delle tabelle nelle classi che fanno uso/derivano da Zend_Db_Table

$frontendOptions = array ('lifetime' => 7200, 'automatic_serialization' => true);
$backend = extension_loaded('apc') ? 'Apc' : 'File';
// getting a Zend_Cache_Core object
$cache = Zend_Cache::factory('Core', $backend, $frontendOptions);
Zend_Db_Table::setDefaultMetadataCache($cache);

In questo modo il componente Zend_Db_Table caricherà i metadati per la tabella che rappresenta (nomi delle colonne, tipi, etc) una sola volta ogni 2 ore per ogni tabella, invece che ad ogni esecuzione. L’incremento di prestazioni che si ottiene con queste poche righe è veramente considerevole.

Gli usi possibili di un’estensione del genere spaziano moltissimo, chiaramente per l’utilizzo all’interno di un applicazione è necessario studiare bene l’impatto che può avere il caching di dati a livello logico, ma se implementata correttamente nei punti chiave di un applicazione, il guadagno che se ne ottiene giustifica ampiamente l’impiego di questo meccanismo.

Un buon metodo per capire su quali operazioni implementare la cache è sicuramente il profiling del proprio codice. Quando avrò un po di tempo scriverò un articolo su come applicare questa strategia.

Spesso capita di dover utilizzare un framework javascript per aggiungere funzionalità 2.0 al proprio sito, in tale contesto su siti sviluppati ad hoc è prassi comune includere i files javascript contenenti le librerie direttamente nel proprio dominio.

Questa procedura può e dovrebbe essere evitata andando ad utilizzare le versioni di tali librerie messe a disposizione da Google nella propria rete di distribuzione. Utilizzare tale approccio ha innumerevoli vantaggi tra i quali

• La rete di Google è distribuita e replicata attraverso innumerevoli host dislocati in tutto il mondo, nel risolvere l’hostname i dns di Google reindirizzeranno la richiesta al server geograficamente più vicino alla locazione del utente che fa richiesta della risorsa, garantendo tempi di download e di latenza migliori rispetto al vostro webserver.
• Più siti utilizzano questa tecnica (e ci sono già innumerevoli siti e portali che lo fanno, incluse le principali piattaforme di blogging), maggiore è la probabilità che la stessa richiesta che il browser dell’utente effettua sia già stata eseguita in precedenza. Dal momento che Google indica al browser di mantenere i file scaricati in cache per un anno, nella stragrande maggioranza dei casi il download del file richiesto non sarà neppure necessario, trovandosi esso in cache.
• Gli aggiornamenti dei framework sono gestiti da Google che mette a disposizione le ultime release stabili delle librerie disponibili.
• Con alcuni contratti di hosting la banda può essere una risorsa preziosa, in questo modo si svincola il proprio server dal dover inviare i files javascript portando ad un risparmio di banda notevole. Ad esempio, la versione attualmente disponibile di prototype pesa 143KB, mentre la versione compressa di jQuery pesa 56KB. Moltiplicate per il numero di utenti ed la banda impiegata cresce a dismisura.

Come utilizzare Google CDN

Ci sono due modalità d’uso per caricare le librerie dal CDN di google. La prima modalità è quella di utilizzare il loader javascript messo a disposizione da Google nella libreria Google Ajax API. Per usare questa modalità è sufficiente includere un singolo file javascript nel proprio sorgente che carica questa libreria con il seguente tag

<script src="http://www.google.com/jsapi"></script>

Una volta incluso tale file si ha a disposizione il loader di Google richiamabile attraverso il metodo google.load() indicando come primo argomento il nome della libreria da caricare e come secondo argomento la versione richiesta.

Per quanto riguarda il numero di versione è possibile indicare un numero completo di versione (e quindi specificare la release precisa) oppure specificare un numero parziale, in tal caso sarà restituita la sottoversione più recente di tale ramo di sviluppo. Ad esempio se di un’ipotetica libreria fossero disponibili le versioni 1.8.2, 1.8.4 ed 1.9.1, si avrà la seguente corrispondenza tra parametro e versione effettivamente caricata

• 1.8.2 => 1.8.2
• 1.8 => 1.8.4
• 1 => 1.9.1

È disponibile anche un terzo argomento con il quale si possono passare parametri aggiuntivi opzionali, ad esempio se caricare o meno la versione compressa del file javascript. La documentazione completa del metodo load si trova in questa pagina. Un esempio di utilizzo del loader è il seguente, dopo aver incluso il file javascript principale si può inserire nell’head del documento il seguente codice:

<script type="text/javascript">
      google.load("jquery", "1.3.2");
      google.load("jqueryui", "1.7.2");
      google.setOnLoadCallback(function () {$("#title").effect("pulsate");});
 </script>
...
<h1 id="title">Example Title</h1>

Utilizzare il loader ha anche un ulteriore vantaggio, si ha a disposizione un’interfaccia unificata per il callback onload, infatti i vari framework hanno differenti funzioni da utilizzare per eseguire codice al caricamento della pagina, quindi nel caso in cui si dovessero utilizzare più framework in una stessa pagina si eviterebbe di dover scrivere molteplici funzioni onload.

Il secondo metodo consiste nel caricamento diretto dei file javascript a cui siamo interessati usando il tag script. È sufficiente recuperare l’indirizzo del file, disponibile nella pagina apposita e inserire nel tag head il codice che carica il file

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"> </script>

Librerie attualmente disponibili

La lista delle librerie è in continuo aggiornamento, ed al momento comprende:

• jQuery
• jQueryUI
• Prototype
• script.aculo.us
• MooTools
• Dojo
• SWFObject
• Yahoo User Interface (YUI)
• Ext Core
• Chrome Frame

Inserendola in un computer con Windowx XP compariva in esplora risorse il messaggio “L’unità F: non è formattata, formattare?”

Fortunatamente la chiavetta mi è capitata in mano prima che qualcuno rispondesse avventatamente si a tale domanda.

Come recuperare i dati

La procedura che ho usato in questo caso è abbastanza semplice, richiede solamente un paio di programmi per provare il recupero testdisk e photorec. In più per lavorare con un buon margine di sicurezza e lasciarsi aperta la strada per tentare altri approcci di recupero conviene non lavorare direttamente sul dispositivo, ma su una sua immagine salvata su un altro harddisk. A questo scopo ci sono varie soluzioni, ma quella con cui mi sono trovato meglio è dd_rescue.

Se non si ha a disposizione un sistema Linux sul quale installare i programmi citati, può tornare molto comodo un disco di Knoppix, che contiene i tool necessari al recupero nelle loro ultime versioni disponibili. Nella fattispecie ho utilizzato la versione CD dove ho trovato tutto il necessario (tranne il compilatore c++ che servirà più avanti se si vuole installare la versione GNU di ddrescue).

Dopo aver masterizzato il disco con knoppix facciamolo partire in un qualsiasi computer in grado di fare boot da CD. In alternativa si può anche preparare una pendrive con knoppix se il vostro sistema supporta il boot da USB seguendo queste istruzioni.

Una volta che il sistema è caricato apriamo una finestra di terminale e diventiamo root con il comando sudo su. Dopo di ciò inseriamo la pendrive danneggiata nella porta USB. Esaminando l’output del comando dmesg saremo in grado di identificare quale nome è stato assegnato al dispositivo:

[12866.896026] usb 1-2: new full speed USB device using uhci_hcd and address 3
[12867.039523] usb 1-2: configuration #1 chosen from 1 choice
[12867.044738] usb 1-2: New USB device found, idVendor=13fd, idProduct=1618
[12867.044747] usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[20771.265739] sd 4:0:0:0: [sdc] 234441648 512-byte hardware sectors (120034 MB)
[20771.269228] sd 4:0:0:0: [sdc] Write Protect is off
[20771.269233] sd 4:0:0:0: [sdc] Mode Sense: 00 38 00 00
[20771.269235] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[20771.272999] sd 4:0:0:0: [sdc] 234441648 512-byte hardware sectors (120034 MB)
[20771.274137] sd 4:0:0:0: [sdc] Write Protect is off
[20771.274141] sd 4:0:0:0: [sdc] Mode Sense: 00 38 00 00
[20771.274144] sd 4:0:0:0: [sdc] Assuming drive cache: write through
[20771.274146]  sdc: sdc1
[20771.317017] sd 4:0:0:0: [sdc] Attached SCSI disk

In questo caso la pendrive viene riconosciuta come sdc ma anche qui non risulta possibile montarla in quanto non viene riconosciuto nessun filesystem al suo interno.

Una volta che si conosce il nome del dispositivo da utilizzare la prima cosa da fare è crearne un immagine sul disco fisso, quindi dopo aver montato uno dei dischi del computer “ospite”, proviamo prima con il comando dd_rescue presente in knoppix.

dd_rescue /dev/sdc /savepath/pendrive.image

A differenza del comando dd il software ddrescue evita di inchiodarsi sui settori non leggibili e completerà l’immagine anche in presenza di errori di lettura dal device.

Nel mio caso su 512MB ddrescue ha saltato per impossibilità di lettura circa 8MB, ma ha completato comunque l’immagine.

Ora se siete fortunati potreste anche riuscire a montare l’immagine creata e provare a vedere se risulta leggibile con l’opzione loop di mount in questo modo

mount -t vfat -o loop /savepath/pendrive.image /mnt/pendrive/

Se invece l’immagine non risulta montabile allora è il momento di passare a testdisk/photorec.

Per non lasciare nulla di intentato si può provare come dicevo prima ad utilizzare la versione GNU di ddrescue, c’è chi dice che sia più veloce e abbia risultati migliori. In tal caso serve un compilatore C++ che non è incluso nel CD di Knoppix (mentre dovrebbe essere incluso nel DVD). Per installarlo occorre essere collegati ad internet e digitare i seguenti comandi

aptitude update
aptitude install g++

Una volta installato va verificato che sia disponibile l’eseguibile c++, in caso contrario si può facilmente creare con il comando

ln -s /usr/bin/g++ /usr/bin/c++

A questo punto è sufficiente eseguire pochi comandi per compilare il programma ed ottenere infine l’immagine del device danneggiato

# download ddrescue
wget http://download.savannah.gnu.org/releases/ddrescue/ddrescue-1.8.tar.bz2
# extract the source code
tar xjf ddrescue-1.8.tar.bz2
# compile ddrescue
cd ddrescue-1.8
./configure && make
# first, grab most of the error-free areas in a hurry:
./ddrescue -n /dev/old_disk /dev/new_disk rescued.log
# then try to recover as much of the dicy areas as possible:
./ddrescue -r 1 /dev/old_disk /dev/new_disk rescued.log

Uso di testdisk

Se non siamo riusciti a recuperare niente con ddrescue, allora si può provare con questi due utilissimi tool.

Il primo serve per cercare di riparare partizioni danneggiate, mentre il secondo recupera i dati da dispositivi raw.

Il programma testdisk è un programma interattivo che va avviato passandogli semplicemente il nome del dispositivo (o dell’immagine) sul quale lavorare.

Una volta avviato l’eseguibile il programma si presenta con una schermata nella quale possiamo muoverci tra le varie opzioni con i tasti cursore. L’utilizzo è abbastanza intuitivo, in ogni caso viene spiegato molto in dettaglio sul sito del programma cosa si può fare con esso e come va usato.

Schermata principale di testdisk

Un’altra feature molto interessante di questo strumento è che può essere utilizzato anche per l’undelete dei files cancellati su partizioni NTFS, FAT ed ext2.

Utilizzo di photorec

Chiaramente nel mio caso il recovery della partizione non è andato a buon fine per nessuna delle 2 immagini create con le differenti versioni di ddrescue. A questo punto non rimane che una speranza, photorec. Però si tratta di una speranza ben riposta, perché questo software fa veramente miracoli ed è quanto di più banale ci sia al mondo da utilizzare.

Anche in questo caso per avviare il recupero è sufficiente avviare l’eseguibile seguito dal nome dell’immagine creata in precedenza. Una volta avviato il programma si devono indicare pochi dati per iniziare la ricerca dei files perduti (guida illustrata passo per passo), tra cui indicare la partizione da cui recuperare oppure il device raw da cui leggere, indicare tipo della tabella delle partizioni e tipo di filesystem di cui si tratta(va). Infine va selezionata la directory dove salvare il materiale recuperato, dare l’avvio ed aspettare incrociando le dita, quello che ci si presenterà davanti è questa schermata

Photorec in azione

Alla fine del recupero nella directory indicata troverete tutto il materiale recuperato, per cui se siete stati fortunati avrete nuovamente i file dati per persi.

Nel mio caso sono stato in grado di recuperare da una partizione completamente danneggiata (testdisk non è riuscito neanche a riconoscere il tipo di partizione) circa 441 files sui circa 500 presenti. Tra di essi alcuni documenti in formato excel sono risultati illeggibili mentre per quanto riguarda gli altri formati non ci sono stati problemi. Ovviamente mancava il documento più importante di tutti ma d’altronde si sa la legge di Murphy è sempre in agguato, per cui prima di essere costretti ad utilizzare questi programmi la parola d’ordine è sempre backup, backup, backup.

Normalmente per configurare l’invio dei messaggi si utilizza il seguente codice (ad esempio nel bootstrap):

$config = array('auth' => 'login',
                'username' => 'myusername',
                'password' => 'password');

$transport = new Zend_Mail_Transport_Smtp('mail.server.com', $config);
Zend_Mail::setDefaultTransport($transport);

Per liberarci di questo codice in ogni applicazione che utilizzi la classe Zend_Mail ho scritto una classe Application Resource da inserire nella propria libreria. Il codice della classe è piuttosto semplice

/**
 * Resource for creating smtp transports
 *
 * @uses       Zend_Application_Resource_ResourceAbstract
 * @category   Zend
 * @package    Zend_Application
 * @subpackage Resource
 * @copyright  Copyright (c) 2005-2008 Zend Technologies USA Inc. (http://www.zend.com)
 * @license    http://framework.zend.com/license/new-bsd     New BSD License
 */
class Zenit_Application_Resource_Smtp extends Zend_Application_Resource_ResourceAbstract {
	/**
	 * Transport
	 *
	 * @var Zend_Mail_Transport_Abstract
	 */
	protected $_transport = null;

	/**
	 * Parameters to use
	 *
	 * @var array
	 */
	protected $_params = array ();

	/**
	 * Server name
	 *
	 * @var string
	 */
	protected $_server = '127.0.0.1';

	/**
	 * @var string
	 */
	protected $_transportClass;

	/**
	 * Set the adapter params
	 *
	 * @param $params array
	 */
	public function setParams(array $params) {
		$this->_params = $params;
		return $this;
	}

	/**
	 * Validates the hostname provided as server
	 *
	 * @param string $server
	 */
	public function setServer($server) {
		if (Zend_Validate::is($server, 'Hostname')) {
			$this->_server = $server;
		} else {
			throw new Zend_Mail_Exception("Invalid server name $server");
		}
	}

	/**
	 * Returns the hostname for the server
	 *
	 * @return string
	 */
	public function getServer() {
		return $this->_server;
	}

	/**
	 * Transport parameters
	 *
	 * @return array
	 */
	public function getParams() {
		return $this->_params;
	}

	/**
	 * Determine the type of transport to use
	 *
	 * @param string $class
	 * @throws Zend_Mail_Transport_Exception if the given class doesn't exists
	 */
	public function setTransport($class) {
		if (false === strpos($class, '_')) {
			// allow short names such as smtp
			$class = 'Zend_Mail_Transport_' . ucfirst($class);
		}
		if (!class_exists($class)) {
			throw new Zend_Mail_Transport_Exception(
					"Unexistant transport class $class");
		}
		$this->_transportClass = $class;
	}

	/**
	 * Return the transport class to use
	 *
	 * @return null|Zend_Mail_Transport_Abstract
	 */
	public function getTransport() {
		if (null == $this->_transport && $this->_transportClass) {
			$class = $this->_transportClass;
			// instantiate class
			switch ($class) {
				case 'Zend_Mail_Transport_Smtp':
				case 'Zenit_Mail_Transport_Smtp':
					$transport = new $class($this->getServer(),
							$this->getParams());
					break;
				case 'Zend_Mail_Transport_Sendmail':
				default:
					$transport = new $class();
					break;
			}
			// check transport type
			if (!$transport instanceof Zend_Mail_Transport_Abstract) {
				throw new Zend_Mail_Transport_Exception(
						"Class $class is not a valid Zend_Mail_Transport_Abstract");
			}
			// set transport as default transport
			Zend_Mail::setDefaultTransport($transport);
			// assign it to local field
			$this->_transport = $transport;
		}
		return $this->_transport;
	}

	/**
	 * Defined by Zend_Application_Resource_Resource
	 *
	 * @return null|Zend_Mail_Transport_Abstract
	 */
	public function init() {
		return $this->getTransport();
	}
}

Come nel caso precedente, è sufficiente inserire questa classe nel proprio include_path e cambiare/registrare il namespace della libreria (nel mio caso Zenit).

Fatto ciò per configurare il trasporto da usare usando il file application.ini è sufficiente inserire queste righe:

; smtp stuff
resources.smtp.transport = "smtp"
resources.smtp.server = "smtp.example.org"
resources.smtp.params.auth = "login"
resources.smtp.params.username = "myusername"
resources.smtp.params.password = "mypassword"

Et voilà, il gioco è fatto. Ora si può usare in qualsiasi punto della propria applicazione la classe Zend_Mail per l’invio di messaggi ed il metodo di invio usato sarà quello configurato tramite il file application.ini.

È possibile usare anche classi personalizzate come transport, è sufficiente che tali classi estendano la classe Zend_Mail_Transport_Abstract e che prevedano un costruttore vuoto (in alternativa è necessario personalizzare il metodo getTransport per adattarlo alle proprie esigenze). Per utilizzare una classe personalizzata è sufficiente passare il nome completo della classe come valore dell’opzione resources.smtp.transport, mentre per le classi predefinite si può anche usare il nome breve della classe senza il namespace completo (nell’esempio “smtp”).

Se il server smtp non necessita di autenticazione per l’invio è sufficiente rimuovere le relative righe dal file di configurazione (4-6).

Per quanto mi riguarda attualmente sto utilizzando come transport l’estensione della classe Zend_Mail_Transport_Smtp consigliatami in questo thread del forum di Zend_Framework, in quanto la classe originale soffre di un memory leak nel momento in cui si invia un numero consistente di email nello stesso script, a causa di un log interno che viene salvato in una stringa in memoria. Non appena verrà rilasciato l’aggiornamento che includa la correzione discussa qui, tornerò ad usare la classe ufficiale (di conseguenza la linea case 'Zenit_Mail_Transport_Smtp': nel metodo getTransport verrà rimossa dal codice).

Per questo ognuno dei progetti su cui lavoro è gestito tramite un repository subversion nel quale memorizzo tutti i files di interesse. In tal modo ho sempre la possibilità di ricostruire le modifiche ad un file nel tempo, di poterne recuperare le versioni precedenti, di poter trasferire le modifiche con estrema semplicità da una macchina all’altra, insomma una versione super di Time Machine (chiaramente senza fronzoli grafici e non di così immediato utilizzo).

Quando si utilizza subversion, indipendentemente da come si accede al repository, tutto il contenuto (dati, revisioni e configurazione) è memorizzato nella directory del repository stesso, che è semplicemente una directory all’interno del filesystem. Per eseguire il backup di un repository si potrebbe pensare di salvare il contenuto di questa directory su supporto esterno ed amen. Sebbene questa soluzione potrebbe anche funzionare, di sicuro non è quella consigliata. Infatti una soluzione di questo tipo potrebbe corrompere lo stato interno del repository nel caso in cui venga effettuata una qualsiasi operazione sul repository stesso durante la copia, rendendo inservibile il backup creato.

Vediamo invece una delle strategie di backup possibili utilizzando gli strumenti messi a disposizione con la distribuzione standard di subversion.

Lo script hot-backup.py

Il primo strumento da utilizzare per creare un backup di un repository è lo script hot-backup.py. Questo script è progettato per eseguire una copia completa di un repository “a caldo”, ovvero anche se il repository è in uso crea una copia consistente di tutte le transazioni evitando di incorrere nei problemi descritti sopra. Per cui utilizzando tale script si otterrà una copia funzionante del repository pronta all’uso. L’utilizzo di questo comando è abbastanza immediato (su Debian lo script è installato di default in /usr/bin/svn-hot-backup):

# svn-hot-backup --help
USAGE: svn-hot-backup [OPTIONS] REPOS_PATH BACKUP_PATH

Create a backup of the repository at REPOS_PATH in a subdirectory of
the BACKUP_PATH location, named after the youngest revision.

Options:
  --archive-type=FMT Create an archive of the backup. FMT can be one of:
                       bz2 : Creates a bzip2 compressed tar file.
                       gz  : Creates a gzip compressed tar file.
                       zip : Creates a compressed zip file.
  --num-backups=N    Number of prior backups to keep around (0 to keep all).
  --help      -h     Print this help message and exit.

È sufficiente passargli il percorso del repository ed il percorso dove si vuole salvare il backup ed il gioco è fatto, copia creata:

# svn-hot-backup /home/svn/repositories/src backup/
Beginning hot backup of '/home2/svn/repositories/src'.
Youngest revision is 1663
Backing up repository to 'backup/src-1663'...
Done.

Il comando ha appena creato una copia perfettamente funzionante del repository in oggetto nella directory di backup.

Vediamo come utilizzare questo comando con le sue opzioni per programmare un backup a lungo termine. Le opzioni a disposizione sono solamente due, ma entrambe molto utili. La prima opzione è --archive-type=FMT, con questa opzione si può dire al comando di creare un archivio compresso in uno dei formati supportati dallo script, ovvero gz, bz2 e zip. La seconda opzione, --num-backups=N, invece consente di eseguire il rotate del log in maniera simile al comando logrotate, mantenendo solamente le N copie più recenti dei backup.

Combinando le due opzioni viste si può scrivere un cronjob per salvare il contenuto dei repository su un supporto di backup ad intervalli regolari. Nel mio caso ho inserito il backup nei cron settimanali della macchina, creando il file /etc/cron.weekly/backup-svn il cui contenuto è

#! /bin/sh

MAILTO='fabio@example.com'

# Backup svn repositories

test -x /usr/bin/svn-hot-backup || exit 0

# repositories list
REPOS_LIST="
/home/svn/repositories/src
/home/svn/repositories/src2"

# rotate every n backups
ROTATE=4

# backup path
BACKUP_PATH=/home/svn/backups

for REPOS in $REPOS_LIST; do
        svn-hot-backup --num-backups=$ROTATE --archive-type=bz2 $REPOS $BACKUP_PATH
done

In questo modo ogni settimana viene creata una copia integrale dei repositories indicati nella variabile REPOS_LIST mantenendo solamente gli ultimi 4 nella directory per i backup. Chiaramente se la directory BACKUP_PATH risiede sulla stesso disco del repository, è quasi inutile questo tipo di backup. Nel mio caso la directory contenente i backups viene copiata giornalmente tramite rsync su un’altra macchina. In alternativa è sufficiente aggiungere un comando dopo il ciclo for che copi il contenuto della directory dove meglio si crede (disco esterno, disco di rete, nastro, etc).

Un consiglio importante, in precedenza avevo provato ad impostare la variabile BACKUP_PATH con il percorso di un disco montato con nfs, e le prestazioni erano veramente ridicole, per cui se volete utilizzare un disco di rete (smb o nfs che sia) conviene creare prima i backup sul disco locale e poi copiarli. Non eseguite direttamente lo script hot-backup sull’unità di rete perché è spaventosamente lento.

Backup incrementale delle singole revisioni

Il metodo precedente crea i backup settimanalmente (anche se basta impostare diversamente cron per eseguirlo con cadenza differente), ma che succede se c’è un imprevisto dopo 6 giorni dal backup. Potenzialmente si possono perdere fino a 6 giorni di lavoro, e sicuramente si perdono tutte le singole revisioni di cui si è fatto commit dall’ultimo backup.

Una soluzione molto elegante a questo problema (che può funzionare anche come soluzione stand-alone di backup) è quella di utilizzare il backup incrementale delle singole revisioni di cui si fa commit utilizzando il programma svnadmin dump e gli hook scripts. Utilizzando questi due strumenti è possibile salvare ogni singola revisione del repository per poi reimportarla in un repository creato nella sezione precedente. In tal modo in casi di disastri si perderà poco o niente del proprio repository.

Per salvare il contenuto di ogni singola revisione in una directory a piacimento è sufficiente editare (o creare) lo script post-commit nella directory hooks del repository ed aggiungere il seguente contenuto

REPOS="$1"
REV="$2"

# backup of current revision to revision dir
svnadmin dump "$REPOS" -q -r $REV --incremental --deltas | gzip > /home/svn/backups/revisions/src.rev$REV.gz

In questo modo ogni volta che si fa commit il contenuto della revisione corrente viene salvato nel file src.rev<num>.gz e può essere utilizzato tramite il comando svnadmin load per ricreare la modifica su una copia del repository.

Una cosa estremamente importante a cui prestare attenzione è il flag --incremental, infatti senza di esso verrebbe salvato un dump completo del repository nel file di backup.

Per quanto riguarda invece il flag --deltas può essere anche omesso, esso serve per creare il dump in formato binario e in modo che contenga solo le differenze con la precedente revisione; questo fa si che il file che contiene la revisione sia sensibilmente più piccolo di quello ottenuto senza questo flag (che contiene una copia intera in formato testuale dei files modificati nella revisione corrente). Quindi usare o meno il flag --deltas è un compromesso tra spazio disco ed uso processore in fase di dump/load e di conseguenza in fase di commit. Questo è il raffronto in termini di costi tra un backup creato con e senza il flag --deltas su un repository di dimensioni medio-piccole. Da notare come, se compressi con gzip, i backup ottenuti abbiano più o meno la stessa dimensione finale.

# time svnadmin dump -q /home/svn/repositories/src --deltas > deltas.dump

real	0m16.554s
user	0m12.181s
sys	0m4.128s
# time svnadmin dump -q /home/svn/repositories/src > nodeltas.dump

real	0m9.240s
user	0m6.956s
sys	0m2.016s
# ll -h
total 86M
-rw-r--r-- 1 root root 28M 2009-11-13 22:12 deltas.dump
-rw-r--r-- 1 root root 58M 2009-11-13 22:13 nodeltas.dump
# ll -h
total 42M
-rw-r--r-- 1 root root 21M 2009-11-13 22:12 deltas.dump.gz
-rw-r--r-- 1 root root 22M 2009-11-13 22:13 nodeltas.dump.gz

I backup delle singole revisioni andrebbero memorizzati insieme ad i backup completi creati in precedenza, in modo tale da poterli utilizzare congiuntamente per ricreare il repository nello stato dell’ultima versione disponibile. Per eseguire un ripristino è sufficiente prendere l’ultima versione completa a disposizione del repository scompattarla e importarci tutte le successive revisioni di cui si ha il backup con il comando svnadmin load.