Ceci n'est pas une pipe

Risposta minimalistica ad una domanda minimalistica: come faccio a clonare un server Debian replicandone completamente il software installato?

1) sul server da clonare esporta l’elenco dei pacchetti installati:

dpkg --get-selections > installed-software

2) passalo sul server clone:

scp installed-software pippo@nomeserver.test123.com:~

3) sul server clone importa l’elenco dei pacchetti da installare:

dpkg --set-selections < installed-software

4) sul server clone avvia l’installazione dei pacchetti selezionati:

apt-get dselect-upgrade

That’s all folks!

Chi utilizza Postgrey come componente di sistemi anti-SPAM complessi deve effettuare periodicamente un reset del database che l’applicazione ha generato. Questo perché da tempo i server di molti spammer riescono a mantenere lunghi periodi di operatività senza che niente e nessuno li riesca a fermare – facendoli finire in una delle blacklist di riferimento, ad esempio.

Il risultato è che sempre più spesso i server di alcuni grossi spammer finiscono nel database delle combinazioni considerate trustable dal nostro Postgrey, invalidandone di fatto l’efficacia. Per ovviare a scenari come questo esiste un metodo brutale ma efficace: resettare completamente i database di Postgery e i suoi file di lock, riportandolo alla situazione originaria.

Ecco come:

1. interrompere il daemon di Postgrey
2. eliminare la directory /var/lib/postgrey (consiglio vivamente di rinominarla)
3. creare una /var/lib/postgrey vuota
4. riavviare Postgrey

In altre parole, si deve procedere così:

# /etc/init.d/postgrey stop
# cd /var/lib
# mv postgrey postgrey_OLD
# mkdir postgrey
# chown -R postgrey:postgrey postgrey
# /etc/init.d/postgrey start

Queste istruzioni si riferiscono a Debian GNU/Linux – la mia distribuzione di riferimento – ma funzionano per quasi tutte le altre distribuzioni in circolazione. Controindicazioni? Nessuna, se non che dal reset in poi verranno ripresi in esame tutti i nuovi messaggi, anche quelli provenienti da server effettivamente trustable – ovvero che avevano già una loro triplet nel db di Postgrey – causando lievi ritardi nella consegna della posta elettronica. Per questo consiglio di effettuare il reset solo un paio di volte l’anno.

Su tutte le Debian Squeeze c’è una correzione al volo da fare al php.ini dedicato agli script eseguiti lato server (a.k.a. command line). La correzione è di vitale importanza, ma solo se avete messo in cron script php e non volete che il server si rifiuti di eseguirli perché richiedono più memoria di quella allocabile. Il problema è dovuto al parametro:

memory_limit = -1

Visto così sembrerebbe un flag disabilitato e ci aspetteremmo quindi che non ci sia alcun limite nella memoria allocabile, invece il comportamento è tutt’altro:

PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 64 bytes) in /var/www/clients/client21/web54/web/XXXXXX.php on line 212

Per ovviare al problema, è bene specificare quale effettivamente è il limite di memoria che intendiamo imporre ad uno script php eseguito da linea di comando. Il parametro si trova nel file:

/etc/php5/cli/php.ini

E la modifica da effettuare è la seguente:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
;memory_limit = -1
memory_limit = 128M

Also sprach Zio Vania

Oggi mi è capitata una di quelle cose che è bello dire solo quando sono finite. Stavo sistemando una serie di nuovi virtual host sul webserver di un cliente quando, del tutto improvvisamente, la macchina ha smesso di rispondere a qualsiasi forma di comando. L’ambiente bash in cui stavo digitando i miei comandi sembrava integra, nel senso che mi era possibile effettuare qualsiasi normale operazione purché non avesse a che fare con il filesystem: funzionavano perfettamente comandi come top e ps, ma era impossibile effettuare il less di un file o addirittura ottenere il man di un qualsiasi comando… In tutti i casi ottenevo un brutale e inequivocabile Input/output error, sintomo tristemente evidente di un problema sul filesystem.

Non che sia una situazione in cui mi sono trovato spesso, grazie al cielo, ma trattandosi quasi sicuramente di un problema del controller RAID e non dei dischi (entrambi nuovi di zecca) ho deciso di effettuare un reboot, ma anche questo comando restituiva il medesimo errore: non essendo disponibile in memoria in forma di processo il kernel lo deve per forza prelevare dal filesystem, quindi… Input/output error.

Fatta questa romanzesca e noiosissima introduzione, vengo al sodo e registro qui il paio di comandi con cui sono riuscito a comunicare al kernel le mie cattive intenzioni:

# echo 1 > /proc/sys/kernel/sysrq
# echo b > /proc/sysrq-trigger

Con la prima istruzione ho abilitato il flag sysrq che permette di inviare comandi direttamente al kernel, mentre la seconda istruzione costituisce a tutti gli effetti il comando di reboot. Ecco alcuni link utili per conoscere meglio questa potentissima e preziosissima modalità di interazione con il kernel di Linux:

• http://it.wikipedia.org/wiki/Magic_Sys_Req
• http://en.wikipedia.org/wiki/Magic_SysRq_key
• http://www.linuxhowtos.org/Tips%20and%20Tricks/sysrq.htm

Questa settimana ho dedicato molto del mio tempo al rifacimento di un server Dell PE1950. Non è la macchina più performante tra quelle che ho a mia disposizione ma è senz’altro un server di altissima qualità, destinato a durare molto nel tempo. Una delle mie esigenze più urgenti quando preparo server di questo livello è l’integrazione con Debian GNU/Linux dei software di monitoraggio del RAID-1. A seconda del controller montato sul server è necessario ovviamente installare uno specifico software e settare correttamente il kernel. Spesso questo tipo di operazioni richiede molto tempo e molta pazienza, specie nel benchmarking che deve sempre precedere la messa in produzione di un server dopo interventi di questo tipo. In questo caso è andato tutto nel migliore dei modi, devo dire più grazie alla qualità del controller e del software utilizzato che alla distro (nel senso che in questo caso Debian non ha meriti particolari nel corretto funzionamento del software). Leggi il resto »

Rispondo ad una richiesta di assistenza che mi ha raggiunto nel cuore della notte: un server Debian GNU/Linux 4.0 (Etch) si è perso – per motivi che meriterebbero un serio approfondimento – le chiavi pubbliche dei repository indicati in /etc/apt/sources.list. Si tratta – in poche parole – delle chiavi di crittografia GPG che permettono di verificare l’effettiva identità del repository, onde evitare il download di pacchetti contraffatti da chissà quale fonte.

La perdita delle chiavi pubbliche determina l’errore NO_PUBKEY ad ogni apt-get update:

W: GPG error: http://security.debian.org etch/updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY XXXXXXXXXXXXXXXX
W: GPG error: http://ftp.debian.org etch Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY XXXXXXXXXXXXXXXX
W: You may want to run apt-get update to correct these problems

Per risolvere il problema è sufficiente importare nuovamente le chiavi pubbliche:

gpg --keyserver subkeys.pgp.net --recv XXXXXXXXXXXXXXXX
gpg --export --armor XXXXXXXXXXXXXXXX | apt-key add -

Da oltre un mese noto sui miei server dove ancora gira Debian 4.0 (Etch) ripetuti tentativi di accesso ai database MySQL approfittando di una grave vulnerabilità di PHPMyAdmin. So che il problema è già stato segnalato su http://bugs.debian.org, ma ancora non è stata rilasciata alcuna patch. Ne parlo qui perché chi ha un server Etch e non ha debitamente protetto l’accesso al db da localhost possa correre ai ripari prima che accada l’irreparabile – mi si passi il gioco di parole. Leggi il resto »

Ci sono tutorial tanto semplici quanto  intramontabili, veri e propri ever green del bravo informatico che muove i primi passi nel magico mondo dell’amministrazione di sistema. Quelle che seguono sono semplici istruzioni che permettono di reimpostare data, ora e timezone su un server Linux. Li metto a disposizione di un cliente che me ne ha fatto richiesta proprio questa mattina. Onore al merito: gli originali di questi tutorial elementari ma utilissimi si trovano qui e qui.

Reimpostare la data

Per reimpostare solo la data su un server Linux è sufficiente accedere alla linea di comando come root e digitare quanto segue:

# date +%Y%m%d -s "20090217"

Reimpostare l’ora

Per reimpostare solo l’ora su un server Linux è sufficiente accedere alla linea di comando come root e digitare quanto segue:

# date +%T -s "11:12:00"

Reimpostare data e ora

Per reimpostare data e ora su un server Linux è sufficiente accedere alla linea di comando come root e digitare quanto segue:

# date -s "16 FEB 2009 11:12:00"

Reimpostare la Time Zone (soluzione A)

Se state utilizzando Fedora, RHEL o CentOS Linux digitate quanto segue:

# redhat-config-date

Oppure lanciate ‘setup’ e scegliete “Timezone configuration”:

Reimpostare la Time Zone (soluzione B)

Se utilizzate un’altra distribuzione o se – indipendentemente dalla distribuzione che utilizzate – vi sentite sufficientemente self-confident con Linux da mettere mano ai file di configurazione, procedere come segue:

1) spostatevi in /etc/

# cd /etc

2) create un link simbolico al file che contiene la timezone prescelta

# ln -sf /usr/share/zoneinfo/CET localtime

Reimpostare la Time Zone (soluzione C)

È sempre possibile utilizzare le variabili ambientali per ottenere il cambio della timezone:

$ export TZ=Europe/Rome


In questo caso, le impostazioni saranno valide per tutta la sessione ma saranno perse al primo reboot, a meno che non si aggiunga la stessa istruzione nei file di configurazione che gestitsono le variabili ambientali personalizzate, ma non è una scelta che io mi senta di consigliare, meglio a quel punto utilizzare la soluzione A o la soluzione B.

In questo post descrivo con la massima sinteticità e senza alcuna pretesa di completezza come si possa realizzare un RAID 1 (software) durante l’installazione di Debian Etch e come si configuri correttamente il LVM.

Su una delle mie workstation ho due hard disk identici da 320GB. Ho deciso di installarci l’ennesima Debian Etch e di mettere i due dischi in RAID. Ho avviato l’installazione e in un paio di minuti sono arrivato allo step in cui vanno effettuati i settaggi per il partizionamento dei dischi. Trattandosi di dischi S-ATA, il debian-installer me li ha riconosciuti come segue:

• SCSI1 (0,0,0) (sda)
• SCSI2 (0,0,0) (sdb)

Lo stesso discorso vale comunque anche per dischi IDE, in quel caso il debian-installer li vederebbe così:

• IDE1 (hda)
• IDE2 (hdc)

A questo punto ho creato una prima partizione di booting, di dimensioni minime (solo 512MB):

1. selezionare il primo disco SCSI1
2. scegliere come metodo di partizionamento “Manuale”
3. selezionare la voce “SPAZIO LIBERO” sotto SCSI1
4. scegliere “Crea una nuova partizione”
5. selezionare “Inizio” come posizione della nuova partizione
6. selezionare “Primaria” come tipo della nuova partizione
7. inserire 512M come dimensione della nuova partizione
8. scegliere “Volume fisico per il RAID” come modo d’uso della nuova partizione
9. scegliere “Preparazione di questa partizione completata”

Poi ho creato la partizione destinata a contenere il filesystem vero e proprio:

1. selezionare il primo disco SCSI1
2. scegliere come metodo di partizionamento “Manuale”
3. selezionare la voce “SPAZIO LIBERO” sotto SCSI1
4. scegliere “Crea una nuova partizione”
5. selezionare “Inizio” come posizione della nuova partizione
6. selezionare “Primaria” come tipo della nuova partizione
7. inserire 95% come dimensione della nuova partizione
8. scegliere “Volume fisico per il RAID” come modo d’uso della nuova partizione
9. scegliere “Preparazione di questa partizione completata”

Perché al punto 7 ho scelto di utilizzare solo il 95% del disco? Semplicemente perché, nel caso io debba sostituire uno dei due dischi, non avrò mai la certezza assoluta che il nuovo disco abbia esattamente lo stesso numero di cilindri etc. rispetto al disco originale, nemmeno se lo compero della stessa marca e dello stesso taglio. Ho bisogno quindi di un gap di tolleranza per mettermi al sicuro da possibili perdite di dati o inconsistenze durante la ricostruzione dei volumi. Certo, si spreca dello spazio che non verrà mai utilizzato, ma con dischi di queste dimensioni ce lo possiamo pure permettere.

Ora è necessario ripetere le operazioni appena descritte anche per il secondo disco (SCSI2) assicurandoci di avere effettuato esattamente le stesse scelte fatte per il primo.

Fatto questo, possiamo configurare il RAID 1 software. Per prima cosa creiamo il device multidisk destinato a contenere la partizione di boot:

1. scegliere “Configurare il RAID software”
2. confermare “Scrivere i cambiamenti sui dispositivi…”
3. scegliere “Creare un device multidisk (MD)”
4. selezionare “RAID1″ come tipo di device multidisk
5. confermare “2″ come numero di device attivi per l’array RAID1
6. confermare “0″ come numero di device “spare”
7. abilitare solo /dev/sda1 e /dev/sdb1 come device attivi
8. scegliere “Terminare”

Poi creiamo il device multidisk destinato a contenere il filesystem vero e proprio:

1. scegliere “Configurare il RAID software”
2. confermare “Scrivere i cambiamenti sui dispositivi…”
3. scegliere “Creare un device multidisk (MD)”
4. selezionare “RAID1″ come tipo di device multidisk
5. confermare “2″ come numero di device attivi per l’array RAID1
6. confermare “0″ come numero di device “spare”
7. abilitare solo /dev/sda2 e /dev/sdb2 come device attivi
8. scegliere “Terminare”

Ora possiamo passare alla creazione dei volumi logici. Per prima cosa creo il volume destinato a fare da swap del sistema:

1. scegliere “Configurare il Logical Volume Manager”
2. confermare “Scrivere le modifiche sui dischi e …”
3. scegliere “Creare i gruppi di volumi”
4. scrivere “VG00″ come nome del gruppo di volumi
5. abilitare solo /dev/md/1 come device per il nuovo gruppo di volumi
6. scegliere “Creare un volume logico”
7. selezionare il gruppo di volumi “VG00″
8. scrivere “swap” come nome del volume logico
9. scrivere “4GB” come dimensione del volume logico (almeno il doppio della RAM)

Poi creo il volume destinato al filesystem vero e proprio:

1. scegliere “Creare un volume logico”
2. selezionare il gruppo di volumi “VG00″
3. scrivere “filesys” come nome del volume logico
4. confermare il valore massimo disponibile proposto come dimensione del volume logico
5. scegliere “Terminare”

A questo punto posso creare le partizioni:

1. selezionare il n° 1 sotto “LVM VG VG00 LV filesys”
2. creare la partizione normalmente (scegliendo “Ext3″ come modo d’uso e “/” come mount point)
3. scegliere “Terminare”
4. selezionare il n° 1 sotto “LVM VG VG00 LV swap”
5. creare la partizione di swap normalmente (scegliendo “swap area” come modo d’uso)
6. confermare “Scrivere le modifiche sui dischi e …”

Fatto questo, è sufficiente procedere con l’installazione di Debian come di consueto.

Non ci sono mezzi termini: la mia esperienza con VirtualBox di Sun Microsystems è stata semplicemente entusiasmante! Ora posso utilizzare i software che girano meglio sotto Windows XP senza dovere ogni volta riavviare la mia Linux box. Indispensabile, provare per credere! Inutile perdermi in spiegazioni su come effettuare l’installazione perché è di una semplicità imbarazzante: è sufficiente installare il pacchetto con dpkg. In questo modo anche chi – come me – utilizza un kernel compilato ad hoc verrà assistito nella compilazione (completamente automatica) dei moduli necessari alla virtualizzazione. Ecco gli step:

1. visitare la pagina http://www.virtualbox.org/wiki/Downloads e clicca su Binaries (all platforms)
2. accettare le condizioni d’uso e scaricare il file corretto (nel mio caso: virtualbox_1.6.4-33808_Debian_etch_i386.deb)
3. installare con dpkg:
   #dpkg -i virtualbox_1.6.4-33808_Debian_etch_i386.deb

[Mostra presentazione]