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

Pubblicato il Pubblicato in #sysadmin

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

Pubblicato il Pubblicato in #sysadmin

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

Pubblicato il Pubblicato in #sysadmin

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

Pubblicato il Pubblicato in #sysadmin

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.

 

Sieve, il linguaggio per filtrare le email

Pubblicato il Pubblicato in #sysadmin

Sieve è un linguaggio che serve solamente a programmare dei filtri per le email: ha una grammatica molto semplice, pochi comandi, qualche estensione, non ha variabili e cicli, è compilato, è davvero molto sicuro proprio perché il suo ristrettissimo campo d’azione lascia ben pochi spazi alla scrittura di codice malizioso ed il suo migliore amico è deliver, l’LDA di Dovecot (ma va d’accordo anche con altri LDA).

Per chi non lo sapesse l’LDA (Local Delivery Agent) è l’ultimo processo per il quale passa una email, ovvero il processo che si occupa di memorizzarla sul filesystem dentro la giusta casella e nel corretto formato (mbox, maildir, etc, etc). Se l’LDA dispone di funzionalità di filtraggio potrà anche, in base a delle regole globali o per-utente, memorizzarla in una particolare cartella, scartarla o modificarla.

Dovecot, ad esempio, dispone di un plugin Sieve per programmare il suo LDA deliver al filtraggio delle email senza la necessità di dover aggiungere un ulteriore hop installando e configurando software tipo procmail o maildropfilter (le cui regole hanno una sintassi ben più ostica di Sieve!).

Per abilitarlo basta semplicemente aggiungere il plugin alla sezione lda di dovecot.conf:

protocol lda {
mail_plugins = sieve
}

Dovecot andrà a cercare l’esistenza del file .dovecot.sieve nella posizione in cui memorizzerà l’email, ovverlo la mail_location preconfigurata.

Vediamo un semplicissimo script sieve che sposta nella cartella CronDaemon tutte le email originate da Cron:

require "fileinto";

if header :matches "Subject" "Cron <root@*" {
fileinto "CronDeamon";
} else {
keep;
}

Ovviamente è anche possibile impostare script globali che vengono eseguiti solo quando manca lo script utente oppure script che vengono eseguiti prima o dopo lo script utente! Io ad esempio ho impostato uno script globale eseguito prima di quello dell’utente per spostare le email contrassegnate da spamassassin come spam nell’apposita cartella. L’ho messo in /var/mail/sieve.before ed indicato nella sezione plugin di dovecot.conf:

plugin {
sieve_before = /var/mail/sieve.before
}

e contiene

require "fileinto";

if header :contains "X-Spam-Flag" "YES" {
fileinto "Spam";
}

Come potete vedere è molto semplice e non bisogna essere dei guru delle espressioni regolari per smistare la posta!

Ecco qui qualche risorsa più approfondita e dettagliata:

Script per lo spindown automatico dei dischi esterni USB

Pubblicato il Pubblicato in #sysadmin

Prima di tutto -per chi non lo sapesse- lo spindown è lo spegnimento del motore di un hard disk. Alcuni hard disk esterni hanno la possibilità di essere impostati indipendentemente dal sistema operativo per effettuare lo spindown come risparmio energetico dopo un tot tempo di inattività, ma la maggior parte degli hard disk (esterni ed interni) no: girano all’infinito anche se non sono utilizzati.

Oltre ad un fattore energetico (un hard disk è un dispositivo meccanico e tra quelli che consumano più energia in un sistema) c’è un fattore acustico dato dal rumore prodotto dal motore (che può essere più o meno fastidioso, anche più o meno conciliante la notte se ti ci abitui) e c’è un fattore termico: girando il disco si surriscalda ed anche se deve riscaldarsi proprio parecchio per danneggiarsi non mi piace affatto l’idea di avere un hard disk termosifone, soprattutto in estate.

Per i dischi che non vengono gestiti dal sottosistema SCSI di Linux si può impostare il valore di timeout per lo spindown con il buon vecchio hdparm:

hdparm -S valore-in-multipli-di-5-secondi /dev/hdX

Per i dischi che invece vengono gestiti dal sottosistema SCSI la questione è un po’ più complicatuccia perchè hdparm non funziona e sdparm non sempre ci azzecca. E’ comunque possibile forzare lo spindown con un comando e la soluzione più compatibile è fare uno script periodico che metta in spindown il disco se non è stata rilevata un’attività recente.

Uno dei migliori che ho trovato sta qui: http://www.linuxquestions.org/questions/linux-hardware-18/howto-spin-down-external-usb-firewire-hard-drives-on-idle-593192/.

Per i più pigri l’ho messo in questo file: idle-drive.sh.gz. Necessita di sdparm e gawk quindi:

sudo apt-get install sdparm gawk

Prende come argomento l’uuid del disco che si vuole monitorare, io l’ho installato in /usr/local/bin/idle-drive.sh e lo richiamo ogni 5 minuti tramite cron:

echo '*/5 * * * * root /usr/local/bin/idle-drive.sh uuid=1703f12f-e133-356f-aee2-ecb75cca15b2' > /etc/cron.d/idle-drive

MySQL: Ripristinare un solo DB da un dump completo

Pubblicato il Pubblicato in #sysadmin

Un buon DBA sa come si fa… io l’ho imparato ieri perchè ancora non mi era mai capitato!

Ipotizziamo che abbiamo fatto un backup dell’intero DB con

mysqldump -h host -p'password' --all-databases > dump.sql

all’occorrenza è possibile ripristinare solamente un database con

mysql -h host -p'password' --one-database database < dump.sql

per tutto il resto c’è mysqlimport

OpenBSD, Impostare il livello fisico per una scheda di rete che fa i capricci

Pubblicato il Pubblicato in #sysadmin

Quando si ha a che fare con schede di rete vecchiotte, specie se c’è un hub economico di mezzo, si possono avere dei problemi con l’autonegoziazione della modalità di trasmissione a livello fisico. Praticamente la scheda di rete non riesce a mettersi d’accordo con quelle delle altre macchine in lan su quale velocità utilizzare.

I led si accendono, segnalano che il collegamento c’è… ma il dhcp non funziona e nemmeno impostando a mano l’indirizzo si riesce a pingare.

Molto probabilmente servirà impostare a mano la scheda a 10 mbit/s.
Questa –triste– operazione generalmente si fa con ifconfig (opzione media) anche se su linux c’è il comando apposito mii-tool, tra l’altro molto comodo per verificare al volo se c’è un collegamento fisico, magari quando potrebbe esserci un cavo difettoso.

Come si imposta questa opzione su OpenBSD?
Lo script che si occupa di configurare la rete su OpenBSD è /etc/netstart. Per ogni scheda di rete rilevata cerca il file /etc/hostname.nomeInterfaccia e da in pasto ad ifconfig ogni sua riga.

Nel mio caso l’interfaccia si chiama xl0, dunque:
# cat /etc/hostname.xl0
media 10baseT
dhcp

Se non vi è mai capitato, date un’occhiata alle man page di ifconfig e mii-tool! ;)