Per poter interfacciare i nostri applicativi ad un sitema bancario oggi mi sono trovato per la prima volta di fronte alla necessità di far funzionare una VPN ipsec.

Ci avevo giocato molto tempo fa’ con qualche risultato ma una volta maturate le vpn su SSL avevo abbandonato questa soluzione decisamente più incasinata.

Premesso che non volevo ricompilare un kernel apposta e che dall’altro lato ci sono apparati cisco ho pensato di provare il vpnclient di cisco appunto. Peccato che con il mio kernel non ne voleva sapere di compilare un modulo ben fatto, con una rapida googolata ho scoperto che il problema era ben noto e che le patch proposte per versioni precedenti del kernel cmq non davano risultati positivi.

Insomma dopo un’oretta di smarronamenti e compilazioni ho finalmente visto la luce: apt-get install vpnc

Nulla di più semplice! Un demone un user space che una un’interfaccia tun per il tunnel. Unica pecca è che ancora non supporta i certificati… ma questo per fortuna non è un problema visto che questa banca si fida delle credenziali xauth (brrrr…)

A completare la soddisfazione un perfettamente funzionante c3270 (purtroppo non Debianizzato immagino per problemi di licenza ma comunque compilato senza problemi)

‘sto server sta’ perdendo la memoria :-)

164  Memory size has changed    
289  DIMM 02 Row 02 has been disabled by the SMI handler.    
289  DIMM 01 Row 01 has been disabled by the SMI handler.    
289  DIMM 01 Row 00 has been disabled by the SMI handler.    
NMI DETECTED

…sono arrivati :-)

giacinto:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md1 9621752 1205240 7927744 14% /
tmpfs 453164 0 453164 0% /dev/shm
/dev/md0 101018 26767 69035 28% /boot
/dev/md2 19236244 131540 18127556 1% /var
/dev/md3 972280 16428 906460 2% /tmp
/dev/md4 47873120 32828 45408460 1% /opt
/dev/mapper/vg0-data 2929539072 528 2929538544 1% /data


Una delle prime cose che ho proposto quando ho iniziato a lavorare per l’inter (burp, 5 anni fa’) è stata la gestione centralizzata dei FAX per eliminare la carta. La cosa non era sembrata interessante. Evidentemente questo strumento non vuole cedere il passo ai tempi e il progettone è tornato alla ribalta un paio di giorni fa’ (…vuol dire che per comunicare con Telecom non dovrò più andare fino al fax in corridoio :-/ ).

E’ stato banale, recuperato un vecchio modem e una linea telefonica, mettere in piedi il tutto con hylafax. Non avevo avuto mai occasione di installarlo ma è di una semplicità imbarazzante. Solo un paio di note:
+ non ho trovato la possibilità di specificare il classico “0” per prendere la linea, così ho dovuto aggiungere una regular expression alle dialrules
+ il protocollo con i client è basato su ftp con la magagna che che il server ce l’ho in DMZ (visto che fa’ altre 1001 cose)… un macello per il firewall. L’unica soluzione pulita è stata quella di ricaricare il modulo ip_conntrack_ftp specificando la porta aggiuntiva su cui lavora hylafax (modprobe ip_conntrack_ftp ports=21,4559) con la menata di dover bloccare tutti un paio di minuti per poter rimuovere il modulo.

Un’altra cosa che propongo da un paio d’anni è quella di metter su un serverino asterisk e giocare un po’ con VoIP e centralino… magari prima o poi.

Mi è tornata la voglia di giocare un po’ con LDAP su Postfix.

Ho aggiornato s2b all’ultima versione di Phamm che prevede ora un suo schema abbandonando quello originario di Jamm.

Non mi convince molto, anche se la maggior parte delle cose funzionano… ci sono talmente tanti modi di fare la stessa cosa che non so mai decidermi. BTW, dovrei trovare il tempo di dare un’occhiata la directory server che ha rilasciato open Red Hat… anche se immagino che anche li ci sia un bello schema ad hoc.

Ho “scoperto” che oltre ad always_bcc ora (dalla 2.1) ci sono sender_bcc_maps e recipient_bcc_maps per le quali ho già un paio di ideucce :-)

Sapevamo tutti che sarebbe andata a finire così…

Possibile che *qualcuno* non lo sapesse? O forse il nostro taroccatore è stato scelto proprio per questa sua abilità… o forse, già che era spacciato è diventato un ottimo capro espiatorio…

Venerdi e sabato passati com Manuel a roma per aggiungere un nodo ad un cluster che abbiamo fatto a dicembre dell’anno scorso.

Già che ci sono vogliono aggiornare i sistema operativo: da RH7.3 a FC3!!! Proprio non capiso… un anno fa’ scelgono la 7.3 perché *stabile* e ora migrano all’ultima release di fedora. Per noi molto meglio visto che poi avevo dovuto ricompilargli a manina php con una marea di librerie inusuali. Per l’aggiornamento al 4.3.10 di fedora ho optato per tenere tutto il possibile della distro originale e cercare i binari dei moduli che mi mancavano… per fortuna ce la siamo cavata :-)

Bella la sorpresa di trovare le macchine con 385 giorni di uptime, nessun riavvio dall’ultimo aggiornamento! Un po’ meno bello scoprire che il load balancer non è mai stato configurato e, di fatto, ha sempre lavorato una sola delle due macchine in cluster. Immediata la conclusione che forse aggiungere la terza macchina non era necessario :-)

Positivo anche il lavoro dell’installer di Fedora. Ero molto titubante sul fatto che l’upgrade dalla 7.3 funzionasse senza problemi, anche perché c’erano rpm installati non di RH (ad esempio MySQL preso dal sito di MySQL AB) e parti ricompilate (come php appunto). Qualche versione fa’ anaconda si sarebbe fermato dicendo che non poteva continuare l’upgrade perché nel sistema c’erano rpm non di redhat.

Due giornate piuttosto cariche di lavoro ma anche divertenti. Niente male la cena di sabato in una trattoria scovata grazie alle “preziose” indicazioni del nostro albergatore: paglia e fieno e filetto al pepe innaffiato da un nero d’avola.

Ho finito di mettere insieme la sostituta di S2.

Ero partito con l’idea di realizzare il tutto con schema ldap il più standard possibili ma mi sono presto dovuto scontrare con la dura realtà: di fatto ogni produttore ha implementato un proprio schema :-/

Ho scelto quindi di utilizzare lo schema di JAMM ma senza usarne l’interfaccia grafica perchè scritta in java… a metà del lavoro ho scoperto l’esistenza del progetto phamm, per altro guidato da due italiani, che parte dall’idea di realizzare un’admin php per lo stesso schema.

Ho messo in piedi tutto il cinema: postfix, dovecot, amavis, clam, spamassassin, gnarwl con le configurazioni su ldap (openldap). Un pezzo alla volta, ora funziona tutto. Metterò online le configurazione appena le avrò limate a modino.

Oggi mentre seguivo il mio n-esimo lavoro sono stato allarmato dal Jamo e poi dal Corra su un problema che affligge le immagini sul sito.

Appena rientrato in casa ho dato un’occhiata: il problema si è palesato immediatamente:

arancia:~/tmp fabio$ wget -S http://www.inter.it/img/headers/ita/it_header_sky-materazi.jpg
--19:55:54-- http://www.inter.it/img/headers/ita/it_header_sky-materazi.jpg
=> `it_header_sky-materazi.jpg'
Resolving www.inter.it... 217.169.113.132
Connecting to www.inter.it[217.169.113.132]:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 Date: Wed, 19 Jan 2005 18:56:05 GMT
3 Server: Apache/2.0.52 (Debian GNU/Linux)
4 Cache-Control: max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600, max-age=600
5 Expires: Wed, 19 Jan 2005 16:10:12 GMT, Wed, 19 Jan 2005 16:20:02 GMT, Wed, 19 Jan 2005 16:20:18 GMT, Wed, 19 Jan 2005 16:31:09 GMT, Wed, 19 Jan 2005 16:31:56 GMT, Wed, 19 Jan 2005 16:42:07 GMT, Wed, 19 Jan 2005 16:42:13 GMT, Wed, 19 Jan 2005 16:52:22 GMT, Wed, 19 Jan 2005 16:52:22 GMT, Wed, 19 Jan 2005 17:03:15 GMT, Wed, 19 Jan 2005 17:04:57 GMT, Wed, 19 Jan 2005 17:15:14 GMT, Wed, 19 Jan 2005 17:15:15 GMT, Wed, 19 Jan 2005 17:25:19 GMT, Wed, 19 Jan 2005 17:25:29 GMT, Wed, 19 Jan 2005 17:36:09 GMT, Wed, 19 Jan 2005 17:36:27 GMT, Wed, 19 Jan 2005 17:46:27 GMT, Wed, 19 Jan 2005 17:46:32 GMT, Wed, 19 Jan 2005 17:56:37 GMT, Wed, 19 Jan 2005 17:57:37 GMT, Wed, 19 Jan 2005 18:07:38 GMT, Wed, 19 Jan 2005 18:07:41 GMT, Wed, 19 Jan 2005 18:17:41 GMT, Wed, 19 Jan 2005 18:17:57 GMT, Wed, 19 Jan 2005 18:28:06 GMT, Wed, 19 Jan 2005 18:28:34 GMT, Wed, 19 Jan 2005 18:38:34 GMT, Wed, 19 Jan 2005 18:38:38 GMT, Wed, 19 Jan 2005 18:48:40 GMT, Wed, 19 Jan 2005 18:48:49 GMT, Wed, 19 Jan 2005 19:01:55 GMT, Wed, 19 Jan 2005 19:02:17 GMT
6 ETag: "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014", "132f2a-8ade-41a49014"
7 Accept-Ranges: bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes, bytes
8 Last-Modified: Wed, 24 Nov 2004 13:43:48 GMT
9 Content-Length: 34389
10 Content-Type: image/jpeg
11 Age: 206
12 Keep-Alive: timeout=5, max=100
13 Connection: Keep-Alive

19:55:54 (492.55 KB/s) - `it_header_sky-materazi.jpg' saved [34389/34389]


Il nostro reverse-proxy-cache part time ZIO sembra impazzito… non ho ancora identificato il problema ma l’ho tolto dal pool di cache sotto il load-balancer. La cosa strana è che la configurazione è del tutto identica alle altre due cache che hanno funzionato bene finora.

Coincidenza ho anche qualche problema con la cache in test basata su squid… ogni tanto muore senza dare errori…

Grandi manovre sui server per cercare di ottimizzare un po’ le risorse che abbiamo.

In particolare:
1. Ho creato un *canale* preferenziale per l’accesso amministrativo anche quando la scheda di rete di veleno tende a saturare i suoi 100Mb
2. Sto’ testando squid come accelerator+cache in alternativa ad apache2

Unico problema al momento è mantenere una consistenza nei log. Visto che in squid non è possibile mandare i log in pipe ad un programma ho optato per una named pipe, e in background faccio girare:
cat /path/squid-pipe | cronolog ...

Risolta anche una magagna di rete, dovuta al fatto che se ho 2 interfacce di rete con due classi diverse e forzo una route statica di un singolo host della prima subnet sull’interfaccia di rete della seconda, i pacchetti che invio raggiungono si l’host ma, *giustamente*, con l’ip source della seconda interfaccia. Questo per esemplificare… in realtà la cosa è ulteriormente incasinata da altri fattori :-)

Purtroppo anche oggi (stanotte!) non ho avuto tempo di lavorare alla migrazione del server di posta elettronica.