Se E' Rotto... Lascialo Come'
E si... qualche volta le cose rotte e' meglio lasciarle rotte... si fanno
meno danni.
Ma andiamo con ordine.
Seguendo i vari panegirici organizzativi, mi trovo ad operare dalla nostra
base di Washington DC, sorvolo sulla organizzazione (o mancanza di) esistente
in tale ufficio. Comunque, non appena arrivato, il facente-funzioni di
DaBoss qui' a WDC (d'ora in avanti per comodita' riferito come DaBoss),
mi ha rifilato tutta una serie di 'semplici lavoretti', consistenti nel
mettere a posto o correggere vari problemucci che, per mancanza di tempo,
di voglia o di qualcuno che ci capisse qualche cosa, non sono mai stati
sistemati.
Uno di questi "problemucci" riguardava il backup di uno dei database usati
dall'ufficio. Tale database e' estremamente importante in quanto
contiene numeri di carte di credito, conti bancari e chi piu' ne ha piu'
ne metta. Come e', come non e', si tratta di un database Access...
ok, smettetela di vomitare adesso... e si', lo so che 'Database' e
'Access' nella stessa frase non hanno molto senso senza una negazione
in mezzo...
Data la necessita' di sicurezza di tale arnese, la procedura di backup
fa una copia del db, la cripta usando PGP e quindi la trasferisce su
di un'altro server dotato di tape library per la copia finale su nastro.
Il che sarebbe bellissimo... se non che la criptazione fallisce
miseramente e tutto cio' che e' trasferito su nastro e' il messaggio di
errore ritornato da PGP. Insomma, non c'e' un backup.
Cosi', dopo essere stato adeguatamente istruito sull'importanza e la
"centralita'" della cosa, e dopo aver atteso una mezza eternita' perche'
DaBoss mi fornisse le password per accedere al maledetto server, mi sono
messo a guardare sta cosa.
Prima cosa che noto: lo script di backup viene eseguito via cron con una
clausola HOMEDIR=/ che 'resetta' la homedir dell'utente a '/'. Si capisce
quini che poi pgp non trova piu' le sue chiavi di crittografia. Un'altra
cosa e' che il file viene prima copiato in locale e poi dovrebbe essere
crittografato. Ma la copia locale non viene cancellata. Domando spiegazioni.
DaBoss - Dato che la procedura di crittografia e copia su nastro non
funziona ho preferito lasciare una copia in locale, cosi' se qualche
cosa non funziona possiamo ripristinare da quello almeno.
Ok, ha senso... piu' o meno... se uno si dimentica tutta la storia di
sicurezza e balle varie.
Dopo un po' di panegirigi rimetto a posto lo script di backup e lo
collaudiamo con successo: adesso il db viene criptato correttamente e
trasferito correttamente su nastro.
IO - Allora che fo'? La elimino la copia locale non-criptata?
DB - Si si, adesso non ci serve piu'.
Le ultime parole famose ovviamente.
Fast forward di circa una settimana, quando CL entra in ufficio terrorizata
e scalpitante.
CL - Il database $quellofamosoinsomma non funziona piu'!!!
DB - Come "non funziona piu'"?
CL - Quando cerco di aprirlo mi dice errore di operazione proibita e si
blocca tutto!
IO - Mah, strano, ma sei sicura di non averlo gia' aperto da qualche altra
parte?
CL - Si, ma succede sempre, solo che di solito prendo l'altro e lo copio
su questo e poi funziona!
Io e DaBoss ci guardiamo un'attimo.
IO - Come "prendi l'altro e lo copi su questo"?
CL - Nella stessa cartella (e daje co ste' "cartelle"...) c'e'
un'altro database con un nome buffo, io lo copio su questo e
funziona. Ma adesso quello col nome buffo non c'e' piu!
E cosi' si scopre che, il famoso superimportantissimo database si introia
a cadenza settimanale e la copia non crittografata che, in
teoria, non avrebbe dovuto servire a niente, veniva usata regolarmente per
ripristinare la situazione.
IO - (rivolto a DaBoss) Ok, niente di male, abbiamo le copie su nastro,
si tratta solo di ripristinare da quello.
DB - Si.... ma come?
IO - Come "ma come"? Si tira fuori dal nastro e lo si decripta no?
DB - Si, ma come si decripta quel coso?
IO - ...usando lo stesso programma che usi per criptarlo?
DB - Non lo so mica se funziona.
IO - Come "non lo so mica se funziona"???
Cosi' ci mettiamo alla consolle per eseguire l'operazione. E scopriamo che...
la Chiave Privata per decriptate il db, sul server non c'e'.
IO - Dove sta la chiave di decriptazione?
DB - A me lo domandi?
IO - E certo che lo domando a te! Sta roba era gia' qui' quando sono arrivato,
la chiave di CRIPTAZIONE e' presente, ci deve essere anche la chiave
di DE-CRIPTAZIONE da qualche parte. Chi l'ha messa in piedi sta roba?
DB - Hemmmm.... io.
IO - E quando hai creato la chiave come hai fatto?
DB - Micameloricordo...
IO - ...osantaapollonia...
Ebbene si'! I pisquanotti adesso crittografano regolarmente i loro database,
ma non hanno modo di de-crittografarli per ripristinare i dati!
E dato che la copia non-crittografata non e' mai stata backuppata su nastri,
siamo rimasti con un database sputtanato (da ricostruire dal cartaceo) ed
una serie di inutili backup perfettamente sicuri. Il che dimostra che,
certe volte, le cose che non funzionano, e' meglio lasciarle che non
funzionano...
Davide
17/01/2009 14:01
Precedente
Successivo
)
