#sysadmin

Raccogliere i log da remoto con rsyslog, differenziarli in base all’IP e ruotarli con logrotate

Le indicazioni di questo post sono state testate con delle antenne Ubiquity e sono valide per qualsiasi sistema che utilizzi ancora rsyslog e logrotate e qualsiasi hardware che sia in grado di spedire i propri log in remoto. Lo scenario è quello di un logserver Debian che riceve i syslog di access points e stations e li divide in base all’IP di provenienza.

Per prima cosa bisogna dire ad rsyslog di ascoltare su una porta UDP o TCP per poter ricevere i log, su /etc/rsyslog.conf decommentare le righe inerenti al protocollo che si desidera utilizzare:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Successivamente, sempre su /etc/rsyslog.conf o come snippet in /etc/rsyslog.conf.d/ vanno inserite direttive tipo queste:

if $fromhost-ip startswith '192.168.10.' then /var/log/ubnt-stations.log
& ~
if $fromhost-ip startswith '192.168.2.' then /var/log/ubnt-stations.log
& ~

if $fromhost-ip startswith '192.168.1.' then /var/log/ubnt-APs.log
& ~

Molto utile ed importate è la riga ” & ~ ” posta immediatamente dopo la singola direttiva, vuol dire: “fermati li dove hai loggato e non andare avanti”, per evitare di spammare altri logfile tipo syslog o messages. Un restart di rsyslogd ed andiamo avanti.

Ultimo step è quello di configurare logrotate per ruotare anche questi nuovi logfile ed evitare che /var/log/ si riempia troppo presto. Le politiche più adatte spettano a voi, potete anche riciclare delle impostazioni già esistenti tra /etc/logrotate.conf.d/ o crearne una vostra, a seconda di quanto vi serva tenere i log.

Nel mio caso bastava una settimana ed ho aggiunto quei file di log (anche con wildcard) allo stesso snippet che fa ruotare syslog, ovvero ogni giorno e per una settimana, /etc/logrotate.conf.d/rsyslog:

/var/log/syslog
/var/log/ubnt-*.log
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Moodle, opcache e le pagine bianche

Mi è capitato di installare Moodle su ISPConfig e riscontrare spesso e volentieri delle pagine bianche nell’interfaccia di admin che lo rendevano davvero poco utilizzabile. Dopo un po’ di troubleshooting ed una ricerca sono riuscito a trovare il problema: opcache, parte di Zend. Conosco ancora poco moodle e non so il motivo esatto di questo comportamento nè quanto possa effettivamente giovarne in performances riuscendolo a farlo funzionare correttamente con opcache attivo… resta il fatto che disattivando opcache scompaiono le pagine bianche.

La direttiva per disattivarlo è opcache.enable:

php.ini:

opcache.enable = 0

apache (conf vhost o .htaccess):

php_admin_value opcache.enable Off
php_flag opcache.enable Off

ISPConfig: snippet da incollare per il rewrite HTTP a HTTPS

Anche se il rewrite ad ssl è una pratica sconsigliata per motivi di compatibilità e performance in alcune situazioni è un workaround necessario :/

ISPconfig -> Siti -> [vhost sito] -> Opzioni -> Direttive Apache

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Riapplicare i filtri #sieve ad una maildir da riga di comando

Anche se dovecot ha il suo tool per riapplicare i filtri sieve a maildirs già esistenti, su un sistema di posta già configurato ed in produzione può essere più conveniente reimmettere le email nell’intera catena di filtri.

Questa serie di comandi combinati in una riga permettono di rispedire tutti i messaggi presenti in una cartella Maildir rifacendoli passare per la catena di filtri sieve.  E’ molto utile per testare le modifiche alle regole:

$ cd mail-storage/dominio.it/utente/
$ for i in cur/* ; do (/usr/lib/dovecot/deliver -d utente@dominio.it < $i ; echo rm $i) ; done

Vi consiglio di testarlo su una cartella con poche email prima di togliere echo a rm.

Trovare ed eliminare i Core Dump files

I file core dump vengono generati dal sistema operativo dopo un crash di un processo e contengono un dump della memoria del sistema ed altre informazioni utili alla diagnosi del bug applicativo o sistemistico che ha causato il crash.

La loro dimensione varia da quanta memoria stava utilizzando il processo che è crashato ed in alcune situazioni possono creare qualche fastidio sui server, sia per l’effettivo spazio su disco che occupano sia perchè solitamente non sfuggono ai controlli di sicurezza che comunque li scansionano generando alert ed aggiungendo carico di lavoro alla macchina.

Su linux il nome del file è core.$PID, con find e le regex è possibile trovarli e cancellarli in sicurezza, se non vi interessa tenerli per fare del debugging:

find /home -type f -regex '.*/core.[0-9]*$' -exec rm -f {} ;

;)

Risolvere il problema di surriscaldamento delle schede video ibride ATI/AMD, spegnendone una

Questo post è per chi ha un portatile con una scheda video ibrida AMD/ATI non più supportata dai driver Catalyst (fglrx).

Facciamo un po’ di chiarezza, anche se è alquanto difficile fare chiarezza sullo stato dei driver proprietari Catalyst e capire quali schede video siano davvero supportate e quali no, tra Catalyst e Catalyst Legacy, Xorg e kernel che cambiano le ABI e rompono la compatibilità binaria con i vecchi driver… so solo che leggo nella pagina degli ultimi rilasci di AMD che la mia scheda video dovrebbe essere supportata in produzione su Ubuntu 12.10 ed invece non funziona.

Prima di oggi l’unica soluzione che i motori di ricerca mi suggerivano era: “comprati un’altra scheda video o cambia portatile“. Tanto che mi ero convito che fosse davvero l’ultima soluzione e stavo iniziando a preparmi a vendere un portatile per il quale ho sudato sette camicie a staccare lo stampino di WINDOWS per attaccarci su quello di UBUNTU. Figuratevi a venderlo… «…si però se ci installi una distro con un kernel maggiore del 3.2 surriscalda troppo e si spegne perchè non ci sono i driver della scheda video…», chi cazzo se lo sarebbe comprato, per usarlo con WINDOWS ma con lo stampino di UBUNTU. Avrei potuto venderlo solamente ad un fanatico di WINDOWS che lo avrebbe usato come dimostrazione che GNU/Linux non funziona.

Invece no. Me lo tengo. Perchè funziona. Con i driver opensource che funzionano meglio degli fglrx.

Continuiamo a fare chiarezza, ma stavolta riguardo i driver opensource, perchè con i Catobrepa… Catobepla… Catoblepa… Catalyst ho chiuso.

Lo stato dei driver opensource è ottimo, il #pobblema è un altro: è necessario SPEGNERE la scheda video dedicata, perchè altrimenti sembra che resti attiva, a palla, e si surriscaldi fino a far andare in protezione il sistema in estate o a tenere le ventole al massimo in inverno, quando di certo non va in protezione ma ci diventi cretino e sordo. Semplicemente basta spegnerla. E come si fa?

echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

Con questo comando si dice al kernel di SPEGNERE la scheda che non si sta utilizzando.

Su qualsiasi distro, perchè è una questione di kernel, se nel vostro sysfs esiste quel percorso potete controllare le due schede video, scegliere quale delle due usare e spegnere l’altra. Magicamente la temperatura inizierà a diminuire, le ventole a rallentare, lo stesso comportamento di quando si usano gli fglrx.

Adesso sto utilizzando la scheda video integrata e va benone con i driver opensource, molto meglio di quella discreta con i driver fglrx: l’esperienza desktop in generale è molto più fluida, non c’è proprio paragone.

E’ non è finita… chi è nella mia stessa condizione ha notato anche che il portatile, senza gli fglrx, ha problemi a spegnersi ed a riavviarsi. Credevo fosse un problema di ACPI, ed in effetti in tutto ciò c’entra l’ACPI ma siamo sempre li: visto che una scheda video non è SPENTA il sistema semplicemente ASPETTA che si spenga inibendo il riavvio e lo spegnimento.

Adesso il mio portatile si spegne e si riavvia tranquillamente, senza dover forzare l’operazione con il tasto hardware e con tutti i rischi del caso.

Vediamo velocemente come liberarci dai Catalyst, o fglrx che dir si voglia. Ho solo questo portatile HP Pavilion dv6 3034sl e non so per altri modelli di schede video, a quanto ho capito dovrebbe funzionare per tutte le schede video ibride riconosciute come tali dal kernel.

1. Rimuovere i Catalyst

sudo apt-get autoremove --purge fglrx*

2. Riavviare il computer

3. Rilassarsi e prepararsi ad ignorare il fastidio delle ventole a palla ed il calore sotto la mano destra

4. Controllare nei log di Xorg quale scheda video attualmente si sta utilizzando (dovrebbe essere quella integrata di default, o comunque quella legata al primo framebuffer /dev/fb0).

$ more /var/log/Xorg.0.log
[    24.620] (--) PCI:*(0:1:5:0) 1002:9712:103c:1440 rev 0, Mem @ 0xd0000000/268435456, 0xf0400000/65536, 0xf0300000/1048576, I/O @ 0x00004000/256
[    24.620] (--) PCI: (0:2:0:0) 1002:68c1:103c:1440 rev 0, Mem @ 0xe0000000/268435456, 0xf0200000/131072, I/O @ 0x00003000/256, BIOS @ 0x????????/131072

è quella con l’asterisco, nel mio caso la 4200 (che mi basta ed AVANZA, io nemmeno la volevo un’altra)

$ lspci
01:05.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RS880M [Mobility Radeon HD 4200 Series]
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series] (rev ff)

5. aggiungere queste righe a /etc/rc.local prima di exit 0

echo OFF > /sys/kernel/debug/vgaswitcheroo/switchecho low > /sys/class/drm/card0/device/power_profileecho low > /sys/class/drm/card1/device/power_profile

ovvero: spegni l’altra scheda ; imposta il profilo energetico basso ad entrambe (per scrupolo, visto che l’altra è spenta)

Maggiori info: http://wiki.ubuntu-it.org/Hardware/Video/GraficaIbrida/Vga_switcheroo

Montare una immagine disco VDI di VirtualBox (quasi) in loopback

Grazie a questo post (in inglese) ho scoperto che è possibile montare ed accedere ad una o più partizioni contenute in una immagine disco VDI, in una maniera molto simile al loopback: tramite il Network Block Device e le utility di qemu. Verificate che nel sistema sia installato l’eseguibile qemu-nbd, casomai installatelo dal pacchetto qemu-kvm.

qemu-nbd si occupa di collegare una immagine disco ad un device node nbd /dev/nbdX e di esporne al sistema le partizioni contenute come sottodevice.

sudo -i
modprobe nbd

#per collegare il file .vdi al device
qemu-nbd -c /dev/nbd0 <vdi-file>

#per scollegarlo dopo aver smontato i filesystem
qemu-nbd -d /dev/nbd0

Una volta collegata l’immagine appariranno i sottodevice /dev/nbdXpY, ad esempio la partizione che da dentro virtualbox sarebbe /dev/sda1 diverrà accessibile su /dev/nbd0p1, e così via.