Fumetto's Blog

Non sempre tutto il male viene per nuocere… e in questo caso mai proverbio fu più veritiero. Ma cominciamo dall’inizio…

La mattina del 29 Aprile un provider italiano (nello specifico Aruba) ha avuto un problema per cui il loro datacenter è stato “spento”. La loro nota riporta che “la mattina del 29 aprile, alle 04:30 un corto circuito negli armadi batterie degli Ups ha causato un principio di incendio, rilevato dal sistema di protezione che ha attivato quello di estinzione. La combustione della plastica delle batterie ha generato fumo che ha saturato i locali. Il sistema ha interpretato il fumo come una prosecuzione dell’incendio, interrompendo la fornitura di energia elettrica.”
In termini pratici il loro datacenter e tutti i siti e servizi/sistemi che forniscono sono andati offline. Ciò si è trasformato nell’impossibilità di visitare siti internet da loro “ospitati” e il non ricevere posta per tutto il tempo che i loro server erano kaputt.

Tale evento (il male di cui sopra) ha provocato in alcuni individui la consapevolezza che forse quel fesso di pseudoconsulente che da anni va predicando che un’azienda seria deve avere un suo server con la sua posta e il suo dominio presso la propria sede aziendale con una linea ridondata e tutte le sicurezze del caso non ha tutti i torti. E così mi cominciano a piovere addosso diverse telefonate… 🙂

Caso volle che, in tale frangente, una segretaria intrapendente e speranzosa di risolvere il suo urgente problema ha pensato che probabilmente sarebbe stata cosa buona e giusta togliere di netto la corrente al server aziendale che non riceveva più le email (prelevandole dai server  Aruba). Al server tale fatto non è piaciuto molto, infatti per dispetto ha fatto saltare uno dei due HD interni e tale guasto non permetteva nemmeno il funzionamento del server in quanto a un successivo avvio il BIOS rimaneva inchiodato cercando di capire quale periferica era collegata a uno dei sui canali IDE senza che tale periferica rispondesse adeguatamente…

Dopo i controlli del caso si decide quindi che bisogna sostituire tutto il server per paura che ci possa essere anche qualcos’altro di guasto (incredibile!!! tale decisione è stata presa dalla direzione senza che alcuno gli fornisse una benchè minima base logica per tale sostituzione…). Mi sono quindi trovato a dover cambiare l’hardware di uno SME server.
Operazione semplice e indolore pensavo io… di solito in questi casi risolvevo con un “backup su desktop” e un successivo “restore da desktop” tramite l’apposita procedura dal server-manager di SME ma… era da un po che non la facevo!!! Mi accorgo quindi (ovviamente DOPO aver aspettato 4 ore per il completamento del backup sul desktop) che dalla versione 7.4 dello SME server il restore da desktop è stato eliminato… 😯
Mi sono quindi ritrovato a utilizzare una procedura per me nuova (mai fatto prima in questo modo) ma che si è rivelata molto più performante e semplice di quanto pensassi…

Il sistema è illustrato nel dettaglio in questa pagina; in pratica si mettono due server (vecchio e nuovo) nella stessa rete e con pochi e semplici comandi da console si fa il “trasporto” di dati e configurazioni da un server all’altro in un colpo solo. Riporto qui i passaggi effettuati (che sono gli stessi descritti nella pagina linkata prima… hai visto mai dovesse andare offline il sito di SME e mi serve la procedura… :D).

Intanto bisogna controllare ceh i due server siano aggiornati e quindi uno “yum update” su entrambi e d’obbligo. Devono inoltre essere raggiugibili via SSH dalla rete impostando opportunamente dal server -manager il sistema di accesso. Una volta effettuato ciò bisogna installare sul server nuovo il contrib che permette la gestione della procedura con i comando

yum install --enablerepo=smecontribs smeserver-affa

Una volta installato e riavviato il server tramite i classici “signal-event post-upgrade & reboot” bisogna configurare il contrib digitando da console

db affa set AffaGlobalDisable yes
db affa set prodserv job
db affa setprop prodserv remoteHostName IPdelServerVecchio
db affa setprop prodserv RPMCheck yes
affa --make-cronjobs

Quindi bisogna generare una chiave DSA e inviarla al server di produzione (quello “vecchio” diciamo) tramite il comando

affa --send-key prodserv

Ci verrà quindi richiesta la password del server di produzione e una volta inserita ci verrà confermato l’invio tramite un apposito messaggio a video.
Cominceremo quindi la copia dei file delle impostazioni del server tramite il comando

affa --run prodserv

Alla fine di questa procedura c’è da controllare un file (/var/affa/prodserv/rpms-missing.txt); se tale file è vuoto significa che possiamo andare avanti con la procedura, diversamente verranno indicati in questo file i pacchetti che sono installati nel server di produzione ma che non sono presenti in quello “nuovo”. In quest’ultimo caso occorrerà aggiornare/installare i pacchetti pe rpoter procedere.
Ipotizzando che il file sia vuoto (e quindi nessun problema) bisogna finalizzare la procedura. Da questo momento in poi inizia il downtime del server.
Intanto bisogna fermare alcuni servizi sul server di produzione; quindi sul server vecchio bisogna inserire le seguenti righe

SVC='qpsmtpd sqpsmtpd crond imap pop3 imaps pop3s ftp httpd-e-smith atalk smb qmail'
for s in $SVC; do service $s stop; done

Quindi sul server nuovo daremo di nuovo

affa --run prodserv

Tale comando sincronizzerà solo i dati che sono stati eventualmente modificati dall’ultima volta che abbiamo lanciato questo stesso comando poco prima.
Terminato ciò bisognerà spegnere il vecchio server con “poweroff” e finalizzare la procedura sul nuovo server con successivo riavvio tramite i comandi

affa --rise --all prodserv
reboot

Dopo il riavvio il nuovo server sarà “pronto all’uso” come se fosse il vecchio. Qui termina il downtime del server

L’ultima operazione da eseguire è la pulizia dei residue di Affa, pulizia che si effettua con i comandi

/bin/rm -rf /var/affa
yum remove smeserver-affa perl-Filesys-DiskFree perl-Compress-Bzip2
rm -f /etc/cron.d/affa-status /etc/cron.d/affa
rm -rf /home/e-smith/db/affa /home/e-smith/db/affa-report
rm -rf /var/log/affa

questo eliminerà Affa e tutti gli archivi/file/sarcazzi che la procedura ha creato con ovvio risparmi di spazio sull’HD.

Scrivevo sopra che la creazione del backup su desktop ha richiesto circa 4 ore… la procedura suindicata ha richiesto meno di 10 minuti (9Gb il file creato in 4 ore precedentemente)… un bel risparmio di tempo eh… 🙂

E’ d’obbligo un “grazie Stefano” per avermi suggerito l’utilizzo di questo sistema… un bel risparmio di tempo… e si sà… il tempo è denaro!!! 😀