ott 31
Questo ve lo devo assolutamente segnalare:
http://blog.davejamesmiller.com/2011/03/how-to-install-php-5-2-fastcgi-on-debian-6-0-squeeze
(copia HTML zippata: PHP52_on_Squeeze.zip)
Ci trovate istruzioni chiare e semplici per installare PHP 5.2 su Debian Squeeze senza effettuare il downgrade globale di PHP5! In altre parole in questo modo fate convivere tranquillamente sullo stesso server entrambe le versioni – la 5.3 con la 5.2 – ovviando i numerosi problemi introdotti dal cambio di versione per applicazioni web fondamentali, come Drupal 5.* che su Squeeze non vuole saperne di girare, come sanno ormai in molti – a proprie spese 
lug 04
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:
- interrompere il daemon di Postgrey
- eliminare la directory /var/lib/postgrey (consiglio vivamente di rinominarla)
- creare una /var/lib/postgrey vuota
- 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.
giu 24
Tra le molte applicazioni disponibili per tenere sotto controllo il consumo di banda di un server ce n’é uno che fa davero bene il suo lavoro: si tratta di vnStat, un network traffic monitor per sistemi BSD e Linux. Questa applicazione si comporta in pratica come un logger che tiene traccia dei volumi di dati in entrata e in uscita attingendo alle informazioni fornite in tempo reale direttamente dal kernel. Ecco quali sono le caratteristiche principali di vnStat così come vengono presentate sul sito web ifficiale del progetto:
- quick and simple to install and get running
- gathered statistics persists through system reboots
- can monitor multiple interfaces at the same time
- several output options
- summary, hourly, daily, monthly, weekly, top 10 days
- optional png image output (using libgd)
- months can be configured to follow billing period
- light, minimal resource usage
- same low cpu usage regardless of traffic
- can be used without root permissions
- online color configuration editor
La sua installazione è in effetti molto semplice e immediata, specialmente sui sistemi Debian-derivati:
# aptitude install vnstat
Una volta installato il pacchetto, è necessario inizializzare un database dedicato al logging per ogni scheda di rete che si vuole monitorare. Se si vuole monitorare la scheda eth0, ad esempio, è sufficiente lanciare il comando:
# vnstat -u -i eth0
Fatto questo, per tenere monitorato il traffico su quella specifica scheda di rete è sufficiente lanciare il programma senza alcun argomento:
ivan@biberon:~$ vnstat
Database updated: Fri Jun 24 01:00:01 2011
eth0
received: 4.71 GB (13.0%)
transmitted: 31.58 GB (87.0%)
total: 36.29 GB
rx | tx | total
-----------------------+------------+-----------
yesterday 1.74 GB | 11.92 GB | 13.66 GB
today 31.97 MB | 162.10 MB | 194.07 MB
-----------------------+------------+-----------
estimated 720 MB | 3.67 GB | 4.38 GB
E’ possibile generare diverse tipologie di report semplicemente passando al programma l’argomento necessario, ma credo che già l’utilizzo standard indicato sopra possa essere più che sufficiente per le ordinarie operazioni di monitoraggio. Maggiori informazioni le trovate a questi indirizzi:
- http://humdi.net/vnstat/
- http://www.debian-administration.org/articles/330
nov 06
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:
lug 22
Se volete rendere il vostro server inaccessibile ad un indirizzo IP da cui provengono troppi, sospetti tentativi di autenticazione, fail2ban è lo strumento che fa per voi. Si tratta di uno script in Python che esegue automaticamente una di quelle noiosissime operazioni che spesso un sistemista UNIX/Linux deve effettuare manualmente: fail2ban cerca nei log di sistema tutti gli indirizzi IP che hanno tentato senza successo di accedere al server; se i tentativi di accesso superano un certo numero massimo consentito in un certo arco di tempo, allora quell’IP viene tagliato fuori mediante iptables per un (altrettanto) certo lasso di tempo. Leggi il resto »
lug 21
Un paio di giorni fa abbiamo ricevuto la notifica via email dal daemon di un server Debian GNU/Linux che ci informava senza alcun tatto di un disastro imminente. Il server in questione gestisce due dischi da 500GB/15k in RAID1 software ed uno dei due dischi ha deciso di fare testamento e mettersi in cammino per l’ultima, ineluttabile destinazione. La notifica non lasciava dubbi: la sincronizzazione con il disco /dev/sda non era più possibile a causa di ripetuti errori nella gestione della partizione /dev/sda1, urgeva quindi la sostituzione del disco.
L’intervento è andato liscio come l’olio, pertanto lo appunto qui a vantaggio di tutti, cercando di essere il più sintetico possibile. Leggi il resto »
mag 12
La versione originale di questo script gira ormai da oltre un lustro su molti dei miei server, almeno su quelli più puri dove ancora bastano una manciata di script nudi e crudi messi in cron per gestire sia il monitoraggio che la manutenzione ordinaria dell’intero sistema. Quello che fa lo script è elementare: interroga il kernel mediante il comando uptime, dal cui output ricava i 3 valori del l0ad average; se questi superano il limite impostato nella variabile $NOTIFY, un messaggio email contenente un breve avviso e l’output del top viene inviato all’indirizzo email impostato nella variabile $EMAIL.
Il valore da assegnare alla variabile $NOTIFY varia da sistema a sistema, spesso individuare quello ottimale per un server non è una operazione del tutto immediata – richiede un minimo di esperienza e senza dubbio almeno un breve periodo di osservazione. Questo per evitare di ricevere un numero eccessivo di warning o, di contro, non ricevere notifiche per eventi che meriterebbero invece un po’ di attenzione. Leggi il resto »
apr 23
Lo scrivo qui a titolo di promemoria per la prossima volta che dovesse succedermi… Questa mattina ho messo a disposizione di un collega un nuovo accesso FTP ad uno dei miei server Debian, su cui gira da sempre un ProFTPD molto ben performante.
Il collega mi ha segnalato gravi problemi di lentezza e ripetuti timeout sulla connessione FTP, fenomeno che in oltre un anno di produzione quel server non aveva mai evidenziato: decine di clienti accedono regolarmente via FTP alle DocumentRoot dei proprio VirtualHost godendo della piena disponibilità di banda e spazio disco.
Dopo avere verificato che il problema riguardava solo l’accesso FTP al mio server e dopo esserci assicurati che la sua connessione non avesse problemi sulla porta 21, dalle nebbie della mia scarsa memoria è riemersa come per magia la questione del reverse lookup! Disabilitarlo in ProFTPD ha infatti risolto completamente il problema… è stato sufficiente accodare al file /etc/proftpd/proftpd.conf le due direttive che seguono:
UseReverseDNS off
IdentLookups off
Riavviato ProFTPD il problema è tornato nel nulla da cui era provenuto
apr 01
Un dritta veloce per chi mi ha chiesto un modo per ovviare al timeout delle connessioni SSH. Premetto che si tratta di una situazione sempre più diffusa, dovuta alla configurazione di default dei nuovi di router distribuiti da Telecom per Alice ADSL. Il problema può essere ovviato passando al comando ssh il parametro:
-o ServerAliveInterval=10
Il parametro manda un messaggio di noop al server ogni n secondi (in questo caso: 10) notificando al router che la connessione è di fatto operativa, anche in mancanza di alcun tipo di attività. Dato che non è comodissimo digitarlo ogni volta, è possibile aggiornare il proprio file .bashrc con un alias che incorpori l’opzione nel comando base:
alias ssh="ssh -o ServerAliveInterval=10"
Questo è quanto 
ott 05
Anche se esistono metodi certamente più ortodossi, ricorrere al vecchio e deprecabile protocollo FTP per mantenere la sincronizzazione tra directory collocate su due server a volte è semplicemente l’unica soluzione. Mi riferisco a situazioni in cui il cliente chiede il backup giornaliero di una vecchia applicazione che risiede su di un server a cui è possibile accedere – per motivi insondabili – solo ed esclusivamente mediante FTP.
Detto tra noi: il cliente non ha quasi mai ragione, e lo dico per esperienza: lui guarda le cose da una prospettiva quasi sempre conservativa, anche e soprattutto quando le cose non vanno per niente bene. La filosofia del cliente tipo è molto spesso la seguente: ha sempre funzionato, quindi funzionerà per sempre. O, peggio: ha sempre funzionato male, ma ha sempre funzionato, quindi funzionerà male ma funzionerà per sempre. Un sillogismo agghiacciante… Leggi il resto »
