rsync su cygwin tra NTFS ed exFAT

Pubblicato il Lascia un commentoPubblicato in #sysadmin

Per una serie di questioni prolisse da raccontare mi sto ritrovando ad usare Windows 7 e dover fare dei backup di dati con rsync su cygwin verso un hard disk esterno USB formattato in NTFS.

Il problema è proprio questo, NTFS. Credevo fosse il filesystem più compatibile tra dispositivi diversi, invece quest’ultimo è exFAT perchè non ha tutta la parte dei permessi ed ownership dei file che tra sistemi diversi diventa un bagno di sangue.

Certo, da un punto di vista Enterprise questi medatati sono sicuramente utili ed importanti, ma per una singola persona no: usate exFAT che la tab sicurezza-col-tasto-destro-proprietà nemmeno ce l’ha!

$ rsync -avr /cydrive/$ORIGINE/ /cygdrive/$DESTINAZIONE/ --progress --delete --size-only --no-perms -O

ISPConfig: snippet per reverse proxy con socket.io

Pubblicato il Lascia un commentoPubblicato in #sysadmin

Qualche settimana fa stavo uscendo pazzo per un problema alla UI di una web app dietro reverse proxy, mi sono accorto che era un problema sul reverse proxy ispezionando la pagina con le WebTools di Chrome e notando che alcune richieste non andavano a buon fine: tutte quelle di socket.io.

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

ProxyRequests Off
ProxyPreserveHost On
ProxyPass /.well-known/ !
ProxyPass /               http://10.8.10.11/
ProxyPassReverse /  http://10.8.10.11/

ProxyVia on      
RewriteEngine On

RewriteEngine On
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://10.8.10.11:8080/$1 [P,L]

ProxyPass               /socket.io http://10.8.10.11:8080/socket.io
ProxyPassReverse        /socket.io http://10.8.10.11/socket.io

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

Pubblicato il Pubblicato in #sysadmin

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: (altro…)

Moodle, opcache e le pagine bianche

Pubblicato il Pubblicato in #sysadmin

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. (altro…)

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

sudo senza password e le distro moderne, tipo #ubuntu

Pubblicato il Pubblicato in #sysadmin
«L’esperto è colui che evitando tutti i piccoli errori punta dritto alla catastrofe» 
(cit. Arthur Bloch)

Dunque facciamo gli esperti e vediamo la maniera più semplice, veloce, sicura e potenzialmente insicura per diminuire drasticamente la frequenza con cui sudo ci chiede di verificare tramite password se siamo davvero noi a richiedergli i privilegi di amministratore:

sudo visudo

---

come esemplificato sotto, spostate il cursore sulla riga dopo il commento, yy = copia la riga e p = incollala immediatamente sotto, commentate la vecchia riga e tenetevela di backup, non si sa mai; modificate la nuova riga appena incollata ciò vuol dire letteralmente: "gruppo(%) sudo? allora NO PASSWORD amigos!"

---

# Allow members of group sudo to execute any command
#%sudo ALL=(ALL:ALL) ALL
%sudo  ALL=NOPASSWD: ALL

---

:wq

Vi avevo detto la maniera più semplice e veloce sicura perchè si abilita una funzionalità di sudo strettamente dal suo file di configurazione e col suo comando di configurazione, senza mettere le mani da altre parti o peggio abilitare l’utente root (e ora vi spiego perchè IMHO); potenzialmente insicura perchè comunque ormai sudo la password non ve la chiede più, ne a voi ne a tutti gli altri utenti amministratori, appartenenti al gruppo sudo.

Abilitare l’utente root ed acquisirne i privilegi con su direttamente, su una distro moderna che integra ed utilizza già sudo e te lo mette a disposizione pure già configurato, a volte può essere necessario, sicuramente è da provare almeno una volta nella vita ma FWIW sudo -i vi da una shell di root esattamente come su, senza dover abilitare la password di root, se proprio avete bisogno di vedere root@localhost:~# per smontare una partizione.

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: