Socrate Reloaded

Storia dell'aggiornamento di un server LAMP in produzione

Socrate è la macchina che gestisce il sito Openskills.info, un assemblato generico in via di obsolescenza informatica discretamente carrozzato per fare un buon LAMP (Linux, Apache, MySql, PHP) in grado di gestire traffici medio-bassi.

Raccontare come si è gestito il suo aggiornamento è probabilmente un azzardo in termini di sicurezza, ma, vista la natura del sito che vive su Socrate, ci sembra una scelta coerente e dovuta.
Ci piace pensare a Socrate come un sistema ed un esperimento aperto, la cui stessa natura è spiegata, testata, condivisa ed esposta, nella speranza che di questo non apra troppe porte ad abusi.

Un buon modo per gestire l'aggiornamento di un singolo server in produzione, senza la comodità di avere una farm ridondata da cui è possibile aggiungere e togliere macchine senza interruzioni del servizio, è quello di preparare una nuova macchina, sincronizzare i dati con l'alter ego online e poi procedere ad uno switch degli indirizzi delle rispettive macchine, portando il nuovo sistema in produzione e ripulendo le arp table sui dispositivi di rete che hanno a che fare con questo server.
Questo approccio assicura un rollback rapido in caso di problemi ed evita interventi a livello di DNS.

In questo caso, invece, abbiamo voluto procedere in modo diverso:
Si vuole mantenere l'hardware esistente ed eseguire l'installazione del nuovo sistema su un hard disk separato, momentaneamente collegato ad una macchina muletto, con l'intento, al momento dello switch, di sostituire fisicamente solo l'hard disk del computer su cui gira il sito.
Si prevede quindi una normale installazione, aggiornamento e sincronizzazione del nuovo Socrate, basato su RedHat 9.0, mentre il vecchio Socrate, su RedHat 7.3 continua ad erogare il servizio.
Il downtime previsto è quello fisicamente necessario per spegnere la macchina in produzione, cambiargli l'hard disk e riavviarla. I tempi di un eventuale rollback sono analoghi.
Il tutto dovrebbe risolversi in pochi minuti, salvo rifiniture e aggiustamenti successivi o interventi pesanti dell'amico Murphy.

INSTALLAZIONE
Si è fatta una normale installazione di RedHat 9.0 in modalità testuale con la scelta predefinita dei pacchetti per un server.
Al primo reboot si è proceduto a sfrondare dall'avvio i servizi non necessari tramite ntsysv e si sono lasciati solo questi servizi attivi:
crond - Indispensabile. Non usandoli, abbiamo disattivato anacron e atd.
httpd - Apache. Apre la porta 80 al pubblico.
kudzu - Non è necessario su un server in cui non cambia l'hardware, ma sarà fondamentale per gestire lo switch sulla macchina in produzione.
network - Indispensabile per un server in rete.
random - Utile e innocuo.
rsync - Lo usiamo per eseguire un backup remoto. Porta 873.
sendmail - Per inviare mail, il servizio di default è bindato su 127.0.0.1 porta 25 e non raggiungibile via rete.
sshd - Amministrazione remota, porta 22.
syslog - I log sono indispensabili.
vfsftpd - FTP server fornito di default da RedHat 9 (è una relativa novità, in passato sono stati usati wu-ftpd e proftpd). Per l'upload dei contenuti web. Porta 21.
xinetd - Necessario per gestire i servizi NON standalone (in questo caso solo rsync)
Fra le porte aperte solo la 80 verrà lasciata accessibile da Internet, le altre rimarranno accessibili solo da IP di amministrazione.

Aggiornamento dei pacchetti
L'aggiornamento  degli RPM di un sistema RH viene fatto di default con up2date direttamente sul RedHat Network, in questo caso preferiamo autorpm, che va scaricato via rete.
La procedura di aggiornamento di tutti i pacchetti installati è relativamente rapida e viene fatta da repository locale con tutti gli rpm dei CDROM sincronizzati con un pool di mirror redhat-updates ufficiale.
Viene aggiornato anche il kernel e per gestire senza problemi lo switch sull'hardware diverso si mantiene l'abbondante kernel modulare di RedHat. In totale vengono aggiornati circa una trentina di pacchetti in pochissimi minuti.
Per evitare warning sulla provenienza degli RPM, si procede ad importare la chiave GPG ufficiale di RPM: rpm --import /usr/share/doc/redhat-release-9/RPM-GPG-KEY.
Durante l'aggiornamento di mutt, che tral'altro non usiamo, abbiamo fatto l'infelice scelta di procedere alla risoluzione delle sue dipendenze, invischiandoci in un imprevisto ritardo dovuto al fatto che autorpm si è messo a scaricare e controllare tutti gli rpm sul repository per risolvere una dipendenza di una dipendenza.

Customizzazioni
Successivamente verranno scaricati ed installati a mano altri pachetti:
tripwire - Il più comune Host IDS su Linux. La configurazione, l'inizializzazione del database e il relativo tuning vengono fatti in tempi successivi.
mysql - Non è stato installato di default e, fondamentalmente per maggiore familiarità, lo preferiamo a PostGreSQL
php_mysql - Il modulo Mysql per Php è un rpm autonomo e non è stato installato di default.
sysstat - Interessante e comodo per monitorare con sar lo storico sullo stato del sistema

Si sono impostate poche comode customizzazioni post-installazione:
- /root/.forward è stato editato aggiungendo una mail esterna a cui forwardare tutte le mail di sistema destinate a root.
- E' stato creato un semplice script /etc/cron.daily/ntpdate che ogni notte sincronizza l'ora sul server.


MIGRAZIONE DEI DATI
Abbiamo provveduto a copiare tramite rsync -av dal vecchio Socrate a quello nuovo vari file di configurazione e script custom:
/openskills/ - E' una directory in cui abbiamo mantenuto tutti gli script custom fatti per le varie funzionalità del sito
/etc/crontab - /etc/cron.* - Si riproduce quanto viene attualmente crontabbato sul vecchio server (dopo una rapida verifica che tutti i comandi invocati siano installati)
/var/log/apache - Viene fatta una prima, lunga, copia dei log di Apache, una copia successiva, solo con le differenze nei contenuti, verrà fatta appena prima di procedere allo switch.
/usr/local/apache/conf - Viene copiata la configurazione di Apache. Sul vecchio Socrate era stato compilato a mano, su quello nuovo per pigrizia, spirito di documentazione e test, si mantiene quello ufficiale distribuito tramite rpm. Il passaggio da un Apache 1.3 ad un Apache 2.0 ci ha fatto optare per la scelta di partire dalla conf 2.0 di default e su questa aggiungere le parti custom, piuttosto che una copia brutale della precedente configurazione.
/etc/rsyncd.conf - La configurazione di rsync (comodo, come si vede, sia per i backup che per il trasferimento di grossi file fra server (scp è una alternativa altrettanto valida, più praticabile (ssh è più diffuso di rsync) ma meno rapida nel gestire grossi file).
/etc/rc.d/rc.firewall - Il file che imposta le regole di iptables sul server. Sul nuovo Socrate abbiamo salvato le regole che questo script impone sul file di configurazione standard: iptables-save > /etc/sysconfig/iptables, in modo da gestire il firewalling come un nomale servizio: /etc/init.d/iptables start|stop.
/dump.db - Il dump dell'intero database MySql viene eseguito sul vecchio Socrate con mysqldump --add-drop-table --all-databases > /dump.db, il file viene copiato sul nuovo e importato una prima volta con mysql < /dump.db per verificare se ci sono problemi di importazione e se il sito funziona correttamente, prima dello switch verrà fatto un ulteriore dump-copia-restore del database. Un simile approccio, piuttosto grezzo, è possibile su Openskills perchè gli inserimenti nel database non sono molto frequenti e le sue dimensioni non sono esagerate. In altri casi potrebbero essere necessarie più complesse procedure di sincronizzazione dinamica del database.

Configurazione di Apache
Socrate non deve gestire una gran quantità di traffico (ha massimo 512Kbit a disposizione e questo risulta essere il suo collo di bottiglia) per cui la configurazione è fatta in base alla sicurezza e alle feature che servono, senza eccessiva attenzione alle performance.
Rispetto all'httpd.conf di default si sono cambiate le seguenti parti:
- Impostato KeepAlive On - Per evitare nuovi handshake TCP/IP ad ogni GET dello stesso client al server
- E' stato commentato il caricamento di vari moduli non utilizzati: proxy* , alcuni auth*, include, cern_met, expires, headers,usertrack, unique_id, dav, asis, dav_fs, imap, speling, userdir.
- Sono stati rinominati i file di configurazione per python, perl, ssl in /etc/apache/conf.d in modo da non caricare i rispettivi moduli.
- Sono state scommentate le righe relative alla location server-status in modo da renderla pubblicamente accessibile (sconsigliato su un normale server).

La configurazione del server ftp è piuttosto semplice se non si hanno esigenze particolari (in questo caso l'accesso ftp è solo per un numero limitato di utenti fidati), di fatto, rispetto al /etc/vsftpd/vsftpd.conf di default si è aggiunta la riga: chroot_local_user=YES che chroota alla loro home gli utenti che si collegano.

LO SWITCH: CRONACHE DI UN SUCCESSO SUDATO
Dobbiamo ammetterlo, questo è il secondo tentativo di aggiornamento di Socrate che abbiamo fatto.
Il primo, qualche settimana fa, è miseramente fallito: il sistema si bloccava dopo Grub, il kernel non veniva nemmeno caricato.
Il motivo era probabilmente l'imperdonabile leggerezza di installare il sistema su un hardware basato su Athlon Amd, mentre Socrate ha un Pentium 3 Intel, si presume che l'installazione abbia messo un kernel ottimizzato per Athlon e incompatibile con l'Intel definitivo.
Questa volta è andata decisamente meglio, anche se abbiamo passato lo stesso i nostri 10 minuti di sudore.
Poco prima di spegnere il muletto su cui è stata fatta la nuova installazione abbiamo di nuovo reimportato il database e eseguita la sincronizzazione dei log.
Staccato l'hard disk dal muletto, si è spento il vecchio Socrate, si è sostituito l'hard disk e riavviato.
Tutto è filato liscio: il kernel ha bootato senza problemi e kudzu, come sempre, ha fatto il suo lavoro: rimosse le configurazioni del vecchio hardware (scheda di rete, bus USB) ha riconosciuto senza sbavature quello nuovo e migrata la configurazione del network.
Il reboot si è completato in meno di 1 minuto e se avessimo fatto le cose con più attenzione il downtime totale sarebbe stato di un paio di minuti, che nel nostro caso sono più che accettabili.
Ma ovviamente abbiamo sbagliato qualcosa e ci abbiamo messo tempi diversi per capirlo:
- Default gateway: ci siamo dimenticati di impostare quello nuovo. Ovviamente la connettività di rete è stata una delle prime cose che abbiamo verificato e il problema si è risolto in pochi secondi.
- Il Sito non si vedeva! Eppure i processi httpd e mysqld erano attivi, gli access log fluivano apparentemente regolari e alcune pagine (statiche) si vedevano. Qui abbiamo perso tempo, 10 o 15 minuti, a verificare configurazione di Apache, accesso da IP diversi, regole di firewalling, log ecc.
Alla fine è stata risolutiva un'occhiata un minimo attenta di un netstat -nat: le connessioni al db venivano fatte ad un IP sbagliato, quello temporaneo che aveva la macchina appena installata prima di andare in produzione. A quel punto è bastato correggere il file /etc/hosts assegnando a Socrate il suo giusto IP pubblico.

CONSIDERAZIONI FINALI
La procedura che abbiamo adottato per l'aggiornamento di un server in produzione NON è certo quella ideale, ma risulta essere interessante, relativamente rapida e di fatto efficace se ci si può permettere un downtime di alcuni minuti, se non si ha un database in costante aggiornamento e si vuole mantenere l'hardware esistente (hard disk escluso, ovviamente).
Le cose sono andate nel verso previsto, gli unici problemi avuti sono imputabili a nostre disattenzioni e leggerezze, nonchè una fretta generale nel pianificare e gestire la migrazione.
Va notata la grande capacità di "adattamento" di un Linux con kernel modulare ad hardware diverso, una cosa simile con il plug&play di Windows sarebbe impensabile (e con Windows XP comporterebbe probabilmente l'invalidazione della chiave di attivazione).
In tutto, dall'inizio dell'installazione sul muletto al primo boot in produzione, abbiamo riavviato il nuovo Socrate 3 volte: la prima a fine installazione, la seconda, dopo tutti gli aggiornamenti di software e kernel, per testare il corretto ripristino del sistema, la terza direttamente in produzione su hardware diverso. In totale sono state impiegate circa 6 ore, oltretutto interrotte da altre attività.
Con Linux questo ed altro è possibile, ed è per questo che ci piace.