Finalmente, dopo *mooolltoooo* tempo che avevo in progetto di farlo ho trovato la voglia e l’opportunità di migrare il server di posta di inter su una nuova macchina. L’hardware non ce la faceva più… per non parlare del sw, una vecchia RH ultra patchata con ormai quasi tutto ricompilato per obsolesceza dei pacchetti binari ormai non più mantenuti.

La grossa difficoltà era fermare un servizio in produzione che tutti snobbano ma che appena non funziona qualcosa tutti se ne accorgono ed iniziano a chiamare :-/ Ho colto l’occasione del 24 aprile in cui la maggior parte degli utenti era “offline” per fare lo switch sulla nuova macchina, praticamente senza interruzione del servizio.

E con questa mi sono tolto dalle scatole anche l’ultima macchina non debianizzata!

Questa settimana ho dovuto skillarmi un po’ sulle soluzione multipath per linux. Tipico esempio: cluster basato su uno storage in fibra, con doppio controller, al quale arrivano 2 fibre da ogni macchina, una per controller ovviamente, per garantire l’HA.

La soluzione più semplice è delegare il tutto ai driver degli host adapter (spesso le qlogic) che, di fatto, rendono del tutto trasparente il multipath al sistema operativo.

Questa soluzione è pero da alcuni produttori sconsigliata e subentra quindi la problematica di gestire il tutto a livello più alto. Con i kernel 2.4 se non ricordo male la soluzione più adottata anche dai prodotti commerciali di cluster era l’uso dei device multipath md. Visto che era troppo semplice con il 2.6 la situazione si è incasinata parecchio con l’uso del device-mapper (con target multipath) e un daemon in user space che permette di monitorare lo stato dei path e di aggiornare prontamente i path da usare. Quest’ultima soluzione è quella, ad esempio, consigliata e supportata da SuSE.

BTW, sempre per questo lavoretto ho dovuto installare la SLES9. Quando è nata SuSE l’avevo messa un po’ da parte per la polemica sulle licenze proprietarie di parte dei tool… d’altra parte ho sempre ammirato molto il fatto che pagassero bravi hacker come Arcangeli per sviluppare il kernel. Poi è arrivata Novell…

Boh… devo dire che l’impatto visivo è notevole. L’installer è veramente notevole e in fase di installazione si possono definire file system cifrati, EVMS o, ad esempio, un CA e autenticazione su LDAP. Poi il frame buffer senza l’output durante il boot… molto markettaro…

Premesso che mi piacerebbe vivere di sola Debian mi sono reso conto che ho perso un po’ lo stato dell’arte delle altre distro… dovrò dedicare un po’ di tempo ad aggiornarmi, almeno su quelle che i clienti ossessionati dalle certificationi sono disposti a pagare salate.

Giornata persa a sistema xorg dopo un dist-upgrade… sia la versione 6.9.0 in unstable e testing, sia la 7 in experimental non funzionano con il driver della matrox…

per la prima volta ho dovuto far ricorso al snapshot.debian.org… fantastico, sono riuscito a ripristinare l’ormaio obsoleta ma funzionante 6.8.2

(… burp, mi accorgo solo ora che è venerdi 17… mah…)

Ogni volta che devo aggiornare un certificato devo andare a recuperare come fare… Questa volta poi ho scoperto che thunderbird si lamentava del seriale non univoco del nuovo certificato percui ho scoperto anche il parametro -set_serial :-)

per generare il certificato e la chiave privata:
openssl req -new -x509 -nodes -out dovecot.crt -keyout dovecot.key -set_serial 01 -days 365

per verificarne il contenuto:
openssl x509 -text -in dovecot.crt

La procedura è ovviamete la stessa anche per apache.

In caso si abbia un certificato con passphrase e la si voglia eliminare:
openssl rsa -in server.key -out server-without-pass.key

Problema risolto *brillantemente* (LOL) dai tecnici Telecom.

Dopo un po’ che cercavano di bloccare il traffico sui loro border firewall senza successo gli ho suggerito che *forse* l’ip sorgente dei pacchetti udp era spooffato e che probabilmente la macchina (o le macchine?) che sta’ inviando i pacchetti è all’interno del data center.

Gli suggerisco di mettere una ACL sul router a monte della nostra VLAN ma la cosa prevede l’intervento di un altro tecnico… io però me ne sono andato a letto.

Sembra che il problema sia stato sistemato alla 1.15… immagino con l’ACL ma dubito che avrò mai i dettagli :-/ Speriamo solo che trovino la macchina responsabile del danno prima che decida di spooffare un altro ip :-)

Devo dire che a differenza di altre volte l’helpdesk di telecom non è stato male… quanto meno ho avuto a che fare con persone collaborative, senza manie di omniscienza, che hanno accettato qualche suggerimento.


19:14:24.707770 IP (tos 0x0, ttl 46, id 0, offset 0, flags [DF], proto: UDP (17), length: 29) 207.142.136.60.51838 > 217.169.113.132.53: [udp sum ok] [|domain]
0x0000: 4500 001d 0000 4000 2e11 a9d7 cf8e 883c E.....@........