** Nota: quanto raccontato in questa lunga pagina è un fatto reale, anche se potrebbe non sembrare cosi. Posso fornire prove. **

Che bel lavoro che faccio? Ma tu sei fuori come un balcone… mo’ ti racconto io cosa mi è successo negli ultimi 4 giorni, cosi ti rendi un po’ conto di cosa significhi fare il consulente informatico.

Tutto comincia mercoledi, quando a fronte della richiesta di essere venerdi a Treviso per tenere alcuni esami EUCIP IT Administrator, chiamo $cliente di Magenta per chiedere se posso spostare la settimanale giornata del venerdì al giovedì.

A risposta affermativa, confermo la mia presenza a Treviso e comincio a pianificare la giornata di giovedi da $cliente. Visto che a seguito di un aggiornamento del sistema (obbligato dalla necessità di utilizzare openvpn come richiesto da $cliente), da quattro giorni ricevo una telefonata quotidiana, all’apertura dell’azienda, perché non riuscono a fare il login nel dominio (samba che gestisce il dominio con gli utenti su mysql, mysql per qualche motivo si riavviava e bisognava riavviare samba), decido che è l’occasione buona per dare un’occhiata al problema e metterlo a posto. L’elenco delle cose da fare comunque non è breve, quindi una giornata piena la passerò a Magenta.

Giovedi mattina, arrivato da $cliente, a Magenta, alle 8:00 e posto che non c’è ancora quasi nessuno in ufficio, opto per un riavvio del server, in modo da partire ad analizzare la situazione da una base chiara e consolidata (sono ormai 200 giorni di uptime, con aggiornamenti, anche di librerie, successivi).
Passano 5 minuti ed il server (che gestisce TUTTO al cliente, se esistessero le fognature IP gestirebbe anche il cesso) non torna su. Vado in sala macchine, accendo il monitor, e mi trovo di fronte la richiesta di password per accedere alla console di manutenzione. Motivo? Sul sistema (una gentoo, per scelta del precedente amministratore di sistema, $admin) manca device-mapper, indispensabile per gestire il raid “dmraid” (altra scelta di $admin…).

Passo la mattinata a fare debugging (prima di scoprire che il raid era gestito da device-mapper, ci ho messo quasi 2 ore), e poi a cercare di districare il casino, armato di live-cd e santa pazienza (in sala macchine non c’è che una sedia e non mi consente di arrivare alla tastiera, posizionata sopra una scaffalatura). Alle 16:00, ormai disperato, dopo innumerevoli installazioni di device-mapper, dmraid, kernel e initrd vari, decidiamo (di comune accordo con i responsabili dell’azienda) di portare il server “da noi”, e verificare cosa si possa fare. Nel frattempo, l’attività di $cliente è completamente ferma dalla prima mattinata (possono usare solo il telefono, e solo perchè l’ho allacciato altrove), ci vogliono alcune ore di lavoro, e quindi mi vedo costretto a rinunciare alla giornata a Treviso. Cerco un sostituto all’ultimo secondo (per fortuna c’è gente disponibile), e dico $cliente, uscendo, che avrei cercato di avere la macchina pronta per la mattina successiva, al massimo nel primo pomeriggio.

L’idea è quella di prendere il sistema, fare un bel backup (i backup remoti ci sono, ma non si sa mai), comprare due dischi nuovi e rifare la macchina. Acquistati i due dischi in CDC, mi appresto a fare un bel backup. Avvio da live-cd, lancio il riconoscimento del raid, monto tutte le partizioni nel loro ordine, e parte una bella copia ricorsiva dal sistema installato ad un disco usb-2 acquistato per l’occasione. Passa un’ora e mezza, e vado quindi a controllare che tutto sia in ordine.
Verifico lo spazio occupato sui due dischi, ed è diverso. La cosa comincia a puzzare. Esploro le directory e scopro che manca parecchia roba. Riprovo a fare un backup, stavolta andando di rsync. Passa 1 ora e finalmente i dati sono stati copiati. Necessaria una verifica, naturalmente: diff ricorsiva delle due partizioni (ci impiega 1 ora buona), tutto in ordine, i files ci sono tutti.

Prima di lanciarmi a rifare la macchina da zero, dovendo lavorare sotto pressione con $cliente che vuole lavorare (ormai è venerdì mattina, non c’è speranza di avere la macchina rifatta e riconfigurata in tempo utile), proseguo con i tentativi di recuperare il sistema installato, nella speranza di mettere una pezza al problema e poter lavorare al nuovo sistema con maggior calma. Nel frattempo, riesco a mettere il cliente in condizione di proseguire con le attività: la mail è accessibile tramite una webmail dal provider, i siti web vengono rapidamente migrati su una macchina di fortuna e giro i dns su di quella, al web accedono dopo una veloce riconfigurazione (al telefono) del router in modo che consenta l’accesso dalla rete dei client anzichè dalla dmz. Nel frattempo la giornata di venerdì è quasi terminata, e visto che sabato mattina ho da fare non uno ma due deploy di server da altri clienti ($cliente2 e $cliente3), devo assolutamente terminare un altro paio di cose. Sospendo i lavori, e alle 3:00 riesco ad andare a dormire (dopo aver tra l’altro scoperto che il database mysql di $cliente4 a cui devo fare un preventivo non è raggiungibile dall’esterno della loro rete).

Sabato mattina: ore 9:00 appuntamento da $cliente2. Programma: installazione del firewall di rete e deploy del server (LAMP+mail) in azienda. Collego il firewall, lo avvio e mi appresto a configurarlo per le esigenze della rete del cliente (non potevo farlo prima perché mancavano una serie di dati). Utente root, password, accesso negato. Riprovo, stesso risultato. Chiamo il mio collega che ha preparato l’installazione, e nemmeno lui si ricorda quale password avesse il sistema installato su quella flash-card. Ok, pazienza, vedrò come fare più tardi. Deploy del server, collego, configuro per gestire la mail, tutto funziona correttamente. Mi appresto a configurare il router Pirelli fornito da $monopolista_dell’ultimo_miglio_in_in_Italia, e scopro che quando cerco di impostare un “virtual server” (devo girarmi una serie di porte sul server), il sistema non risponde. Bon, rogne del provider, li chiamerò. A questo punto, inutile anche mettere in piedi il firewall, tanto non servirebbe a nulla: me lo riporto in ufficio, e ci metto le mani con calma. Riordino tutto (ricablo “l’armadio”) ed esco (13:15) per andare a fare il deploy da $cliente2 (4 server carrozzati, solo da collegare a rete ed alimentazione, in pratica). Nel frattempo prendo accordi con $admin (quello di $cliente) perché venga in ufficio da me alle 15:00, in modo da progettare insieme il nuovo sistema per $cliente.

Sono le 13:45 quando arrivo alla sede di $cliente2 ed il collega che mi ha commissionato il lavoro non tarda a raggiungermi. Pochi minuti dopo arriva anche $cliente2, e portiamo le macchine in ufficio, dove però l’elettricista a dato buca in settimana e quindi non c’è ne rete ne alimentazione. Depositiamo le scatole, prendiamo appuntamento per la prossima volta, e mi avvio verso l’ufficio. Per strada, compro da McDonalds (drive-in) un panino volante, che mangerò in ufficio.
Entro in sede, e scopro che la rete non funziona. Vado a verificare il router fornito da $concorrente_del_monopolista_di_prima ed effettivamente non viene su. Dopo quattro o cinque tentativi, desisto e provo a chiamare l’assistenza. Peccato che per parlare con un operatore in carne ed ossa, bisogna inserire il numero di telefono della linea (che ne è sprovvista) oppure il numero di cellulare segnato sul contratto di fornitura (che io non ho, e non risulta essere nessuno di quelli aziendali a me noti). Ciccia.

Riconfiguro il portatile in modo da uscire da un’altra linea (dalla quale si esce solo sulla porta 80, fatto sul quale non posso intervenire), e guardo l’orologio: le 16:00. Devo andare a prendere Laura fuori dal lavoro. Toccata e fuga, la porto a casa, ed al mio rientro trovo (finalmente) $admin ad attendermi. Entriamo (cestino il panino ormai freddo, pazienza), e ci mettiamo al lavoro sul server. Smontiamo i dischi, montiamo quelli nuovi, avviamo la netinstall di Debian, partizioniamo, e il sistema si pianta. Ottimo. Console? WriteError. Sarà il cassettino estraibile? Proviamo a montare i dischi (serial-ata) direttamente sul controller.
Riproviamo, niente. Sdb continua a dare errori di scrittura. Provo a switchare i due canali, ed ora è Sda che da errori. Deve essere fottuto il disco (nuovo!). Pazienza: che si fa? Usciamo per andarne a comprare un altro (sono le 17:30), altrimenti dovremo fare l’installazione con il raid su un disco solo per poi aggiungere l’altro più tardi, con tutte le rogne che questo comporta. Dove andiamo? CDC? E’ sabato, sono chiusi. Computer Discount, ce n’è uno su Viale Fulvio Testi. Dieci minuti per arrivarci, e scopriamo che si sono trasferiti su Viale Marche, a Milano. Ottimo. MediaWorld? Figurati se ha dei dischi serial-ata uguali a questi… vabbeh, proviamo. Venti minuti fumati (è sabato, la gente dorme in auto), ed ovviamente la previsione era fondata. $admin telefona ad un conoscente di Computer Discount che scopriamo lavora in Viale Marche. Tra una chiacchiera e l’altra, pare che siano aperti. Ottimo, andiamo? $admin ha un impegno, quindi deve rientrare. Lo riporto in ufficio, e parto per Viale Marche. Trenta minuti per arrivarci, e naturalmente scopro che è chiuso. Pazienza. Rientro in ufficio, lancio l’installazione con un disco solo nel raid, lo partiziono, e scopro che debian esige di uscire in ftp per scaricare i pacchetti dal mirror, e quindi (posto che la linea principale è giù e da quella di backup si esce solo in http) non c’è niente da fare, dovrò lavorarci domani.

A questo punto, mi accingo a scrivere questo post (al quale tanto non crederà nessuno) che mi telefona $client1 dicendomi che il monitor lcd che avevamo collegato al nuovo server da problemi di refresh.

Fanculo. Vado a Lourdes. Ah no… non posso…

ps: questa mattina, la rete di $concorrente_del_monopolista_di_prima è ancora giù, poi si parla di connettività in Italia, di garanzia del servizio… bah. Mi porto il server a casa e vedo di installarlo da li…