Incremento messaggi di spam

Negli ultimi giorni stiamo rilevando un sensibile aumento di messaggi di spam a causa, probabilmente, dei nuovi virus che stanno infettando i PC degli utenti.
Come misura difensiva abbiamo approntato una blacklist interna in grado di bloccare alla fonte gli indirizzi IP dei mittenti: stiamo popolando la blacklist con gli IP rilevati nelle email che giungono ai nostri indirizzi aziendali; nel caso in cui rileviate anche Voi dello spam, vi chiediamo di inviarcelo come allegato (è necessario che siano presenti tutti gli header) all’email spam@azns.it.
Vi ricordiamo che, usando la webmail, è possibile configurare il livello di blocco antispam per ogni singola casella email.
Grazie

Gnome: driver ATI OpenSource vs Catalyst

Sono da sempre una persona che non ha mai voluto fare guerre di religione sulle distribuzioni, questo perchè mi hanno sempre annoiato i flame “di principio” in qualsiasi ambito (è più elegante un abito di Armani o di Valentino, corre di più un Ferrari o una Lamborghini…).
Parlando della distribuzione “di uso quotidiano”, va da se che la sto cambiando spesso (forse troppo): lo scorso anno, quando ho acquistato il nuovo portatile, vivevo il mio “periodo minimalista” e ho installato Arch Linux con Xfce (che tuttora uso sul mio NetBook); poi, stanco di usare un DE troppo minimalista, ho vissuto il mio “periodo comodo” e ho installato Ubuntu 12 LTS con Unity con cui non posso dire di essermi trovato male, anzi. Poi è arrivata l’estate, il caldo e il compiz di Ubuntu stressava così tanto l’hardware (e parliamo pur sempre di un Core I7) che mi sembrava di lavorare su un fornello da cucina, per cui ho cambiato di nuovo.
Visti i miei trascorsi con Gentoo, ho voluto provare Sabayon con Gnome e ho trovato un DE leggero, simile per alcuni aspetti a Unity ma con una gestione multimonitor fantastica; ultimamente è uscito Gnome 3.6 e quindi fremevo dalla voglia di provarlo: ho atteso qualche giorno nella speranza che Sabayon si aggiornasse alla nuova versione ma nulla di nuovo all’orizzonte.
Bene, mi sono detto: torniamo alle origini: i repository testing di Arch Linux hanno Gnome 3.6. Ieri ho ceduto, altro cambio di distribuzione.

Sia su Sabayon che su Arch ho installato i driver ATI Opensource. Su Sabayon mai un problema, ogni tanto mi sgranava lo sfondo del desktop quando andavo in “Attività”, ma non ci ho fatto mai più di tanto caso e comunque ammetto di aver sempre dato la colpa al tema personalizzato.
Su Arch con Gnome 3.6… un mezzo disastro: senza alcun motivo particolare, mi ritrovavo con la title bar piena di caratteri “strani”, le icone che sparivano, le finestre con un’aurea bianca che mi faceva pensare a KDE (che personalmente non mi piace). Inizialmente ho pensato ad un problema di gioventù di Gnome, poi mi sono accorto dello sfondo sgranato andando in “Attività” e allora ho immaginato che il problema non fosse Gnome ma riguardasse il driver video.

Passare al driver Catalyst non è proprio così semplice: come già detto, per avere Gnome 3.6 uso i repository testing e, di default, ho Xorg 1.13 che è incompatibile con i driver catalyst di testing. Dopo un po’ di ricerche, ho installato il driver catalyst-testing da AUR che fortunatamente sono compatibili con Xorg 1.13; i problemi di visualizzazione sono spariti (spero definitivamente) e ora mi sento pienamente soddisfatto del mio DE (chissà per quanto, però).

Per chi volesse intraprendere la mia stessa avventura, una dritta: leggete bene il messaggio alla fine dell’installazione del driver; se non l’avete letto…

pacman -S acpid
systemctl start acpid
systemctl enable acpid
systemctl start atieventsd
systemctl enable atieventsd

VM sul cloud e storage clusterizzato

La velocità dello storage è una questione davvero importante nella scelta del servizio cloud: difatti i filesystem clusterizzati che sono alla base di molti sistemi di cloud, sono estremamente robusti e scalabili, però non sono certo paragonabili ad un server con hard disk interno.

Inutile dire che, più di una questione software, in questo caso si tratta di una questione hardware: per minimizzare i costi e massimizzare la dimensione dello storage, è facile trovare alla base dello storage dei dischi SATA di grandi dimensioni; i dischi SAS girano mediamente a velocità più elevate per cui sarebbero un prodotto più performante anche se meno capiente ed economico; i dischi SSD, all’estremo, mal si adattano a mio avviso all’utilizzo in uno storage in quanto degradano nei processi di scrittura.

Se, conti alla mano, avete deciso di optare per uno storage su filesystem cluster basato su server con dischi SATA capienti, dovete monitorare con molta attenzione le performance dei singoli nodi che compongono il cluster per scongiurare sovratulizzi: per questo il semplice comando “top” ci fornisce tutte le informazioni necesarie per capire cosa succede. Difatti il sovrautilizzo del disco si riperquote sul carico del nodo (load average) ed è facile capire se la CPU è impegnata in calcoli o in attesa dell I/O attraverso il valore “wa” che indica la percentuale di carico dovuta all’attesa dell’I/O.

In un esempio concreto, usando il filesystem MooseFS, se il carico supera frequentemente i 4-5 processi in coda è ora di agire: è necessario aggiungere nuovi nodi e, in caso, agire anche sul numero di repliche.

La semplice aggiunta di nodi, permette di distribuire i dati tra più server e quindi, se abbiamo dati “diversi” (ad esempio tanti siti internet con poco traffico oppure un sistema di posta elettronica) ne trarremo beneficio. Se, invece, il nostro storage contiene dati usati con molta frequenza (ad esempio un sito web molto visitato) è utile agire anche sul numero di repliche: avere lo stesso dato presente su più server, permette al sistema di effettuare letture “in parallelo” da diversi server.

Sempre come termine di paragone, una configurazione “mirror” con due repliche su due server può essere una buona base di partenza per un ambiente di test, ma in produzione per me un buon compromesso è avere 5 server con 3 repliche.

Nota a margine: se si usa un qualsiasi sistema di storage basato su FUSE e KVM come virtualizzatore, è necessario verificare la compatibilità dello storage con la cache settata in KVM: nelle vecchie versioni di MooseFS, infatti, era necessario impostare la cache in modalità “writeback”, cosa che rallentava ulteriormente il sistema rendendo necessario scalare lo storage pesantemente pena continui errori sul disco delle VM. Nelle nuove versioni fortumatamente la modalità “default” fa il suo dovere.

Ma cosa fare se si è “dall’altra parte” e si utilizzano VM istanziate su uno storage lento? Il problema del timeout del disco è da tenere in considerazione: i vecchi kernel andavano in kernel painc bloccando il server, i nuovi sono più “smart” e agiscono rimontando il disco in modalità read-only per avere un sistema per lo più funzionante. In qualsiasi caso, se si verifica una simile situazione, sarà necessario riavviare la VM e correggere manualmente gli errori sul disco. Errori simili sono visibili da console:

ATA1.00: exeption Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ATA1,00: failed command: READ DMA

oppure il più grave:

end_request: I/O error, dev sda, sector xxxxx
aborting journal on device sda-x
journal commit I/O error
ext_4journal_start_sb: Detected Aborted journal
Remounting filesystem read-only

Consci del fatto che il timeout è causato dalla lentezza dello storage e non da dischi corrotti, è utile settare valori di timeout sull’I/O più elevati con il comando:

echo 180 > /sys/block/sda/device/timeout

Ovviamete è necessario sostituire sda con l’identificativo del disco e 180 con il numero di secondi di timeout.

Attivato disaster recovery geografico

Nell’ottica del continuo miglioramento delle politiche di sicurezza aziendali, oltre al già attivo sistema di backup dati incrementale giornaliero e al disaster recovery mensile locale, è stata attivata anche la copia delle immagini di disaster recovery su un datacenter remoto.

Attraverso questo sistema sarà possibile ritornare operativi con tempi tecnici di qualche giorno anche in caso di distruzione del datacenter principale (speriamo che non accada mai).

Per i più esigenti, ricordo che abbiamo a catalogo anche l’hosting geograficamente distibuito sia di siti basati su tecnologia LAMP (Linux-Apache-MySQL-PHP) sia di siti Ruby on Rails con base dati MongoDB. Attraverso queste soluzioni realizzate in modalità shared-nothing, il Vostro sito rimarra visibile anche in caso di guasto momentaneo in uno dei datacenter.