Noi Non Abbiamo Toccato Niente
E finalmente, dopo una settimana di influenza spaccacranio, ritorno in ufficio
e mi scontro subito con un bel casino. Ne sentivo la mancanza.
Ho gia' descritto anche troppo il nostro famoso "cluster" di scansione
della posta. Basti dire che esistono 'n' (con n==4) server di ingresso.
Questi non solo accettano la posta ma fanno anche il primo controllo
(blacklisting, spf, dkim, graylisting e vari riti voodoo per purificare
il contenuto delle mail). Orbene, io arrivo in ufficio alle otto
del mattino, attacco il mio lapdog e scopro che tutti e 4 i server di
input sono inattivi.
Morti, cadaveri, kaputt. Niente ping, ssh, smtp. Nada!
Mi attacco alla console remota e scopro che tutti e 4 i server sono in
Kernel Panic. Prima che il Panic venga ai nostri clienti decido di avvisare
subito Bert (cosi' sa cosa raccontare quando cominciano a telefonare) e
poi procedo a riavviare i servers.
Avvia il primo, avvia il secondo ed il primo e' di nuovo in panic. Riavvia
il primo, avvia il terzo ed il secondo e' in panic... Dopo aver madonnato
per una buona oretta continuando a saltare da una console all'altra come
un giocoliere che cerca di tenere dei piatti in bilico sui bastoni, i quattro
maledetti ripigliano vita e la posta ricomincia a fluire.
Un rapido controllo pare imputare il problema al solito maledetto XFS che
si incarta ogni due per tre. Ergo, decido di prendere il toro per le corna,
acchiappo DaBoss e gli propongo la reinstallazione seduta stante
di tutto l'ambaradan usando la nuova configurazione
da me messa a punto.
Quindi acchiappo un paio di server ed
8 (otto) dischi fissi
ed installo
4 server (1 server di input, 2 server di scan, 1 server di output) in
modo da sostituire meta' di uno dei cluster in un colpo solo. Dopo di che,
mi dirigo rapidamente alla colo ed effettuo la sostituzione dei dischi.
Tutto sembra andare per il meglio.
Il mattino dopo ricomincio l'installazione sui dischi che ho rimosso dal
cluster il giorno prima per sostituire anche l'altra meta'. A questo punto
pero' arriva l'imprevisto, nella forma di una telefonata da parte di CL
di $ditta che lamenta che non gli arriva piu' posta.
IO - Ma non vi arriva piu' posta da quando?
CL - Ma, direi da almeno 3 o 4 giorni...
mepensa: e adesso mi telefoni?
IO - Che dominio hai detto?
Guardo sul log e noto che tutte le mail dirette al loro dominio sono in
coda con un bel "timed out while sending end of data". Oh che gioia.
IO - Vedo qui che il nostro server prova a mandarvi la posta ma sembra
che ci siano dei problemi nella connessione e va' in timeout. Voi per
caso avete fatto qualche cambiamento nella connessione di rete? Aggiunto
dei pezzi, cambiato configurazione nel router, cambiato provider...
roba cosi'?
CL - No no, noi non abbiamo cambiato niente.
Sicomeno...
Io penso un momento: non e' possibile che sostituire UN server di output
cambi le cose su tutti i server insieme, ed io non ho alterato la configurazione
di rete. Ergo, deve essere un problema relativo al networking... hummm
fammi vedere un po'... telnet ip.server.cl.qui 25... Connection refused.
Hummm... "connection refused"? Controllo e vedo che questi beduini usano la porta
2525 perche', apparentemente, il loro provider gli blocca la porta 25. Ok.
Telnet ... 2525 e mi becco l'HELO del loro server. Ovviamente un
bellissimo sexchange 2000.
IO - Il vostro server e' un po' vecchiotto... come' che non lo avete mai aggiornato?
CL - Heeeuuuu.... E' una storia un po' lunga...
IO - E la versione corta magari e' "costo delle licenze"?
CL - Hemmm...
Provo ad inviare una mail da telnet e viene accettata senza problemi. Ooookkeey....
Quindi una mail da telnet funziona mentre una mail 'normale' no... dimensione della
mail? Mi viene un dubbio atroce. Visto che gia' ho avuto questo stesso problema piu'
volte, e sempre con in mezzo un qualche server Microsoft, provo "al buio" a loggarmi
su uno dei server di output ed a dare un bel ifconfig eth0 mtu 1000 e poi a
ri-accodare i messaggi di posta per CL. Ed indovina un po': Funziona! Con l'MTU
a 1000 la posta viene consegnata senza problemi.
IO - Okey, ho trovato il problema...
CL - Adesso riceviamo posta!
IO - Si', ho appena detto che ho trovato il problema...
CL - A bene, benissimo grazie ta...
IO - AHO' MA FAMMI PARLA'! Il problema e' che la vostra connessione di rete ha un
MTU troppo basso e non invia correttamente i messaggi ICMP per la negoziazione in
modo automatico...
Ovviamente, di tutto questo CL non capisce un accidente. Mettete qui', se vi pare,
una lunghissima spiegazione delle intricazioni del TCP/IP, il tutto fatto
cercando di non mandare il cervello di CL in kernel panic ovviamente.
Dopo un bel po' un pelo di luce rischiara le tenebre nel suo cranio.
CL - Quindi... cosa dovremmo fare?
IO - Contattare il vostro provider o chi vi fa assistenza sulla vostra rete e
fargli controllare i parametri di connessione.
CL - Ma se io resettassi il cosi li' per la connessione ad internet?
IO - Lo avete resettato di recente?
CL - No, noi non abbiamo toccato niente.
Sicomeno.
IO - E allora lascialo stare e chiama chi vi gestisce la rete.
CL - Ma non possiamo lasciare le cose come sono adesso che funziona?
IO - No, perche' in questo modo sprechiamo un terzo della nostra banda
per consegnare la posta a voi. E dato che di oltre 8000 clienti voi siete
gli unici che hanno questo problema, ritengo che la cosa migliore sia
per voi scoprire cosa c'e' che non va nella vostra connessione di rete e metterla
a posto. O farlo fare al vostro isp che pagate per questo.
CL - Ah-hummm... vabbe'...
Passa una mezz'oretta e mi ri-suona il telefono.
CL - Allora, ho provato a riavviare il router...
IO - Ma hai parlato prima con il vostro provider?
CL - No.
mepensa: ecchemipareva...
CL - Solo che adesso non riusciamo piu' a connetterci ad internet...
Io controllo e noto che, in effetti, il server di CL adesso e' completamente
irraggiungibile.
IO - Ma perche' non lo dici al vostro provider?
Ovviamente, loro non hanno mai toccato niente...
Davide
25/01/2010 08:00
Previous Next
![8 (otto) dischi fissi](javascript:openwindow("/img/softland/mscaninabox.jpg","",1000,800)){kind=link}