sysadmin panics: usare X dal terminale...

Il protocollo X-Window, con tutte le sue pecche di sicurezza ed efficienza, risulta comunque uno strumento molto utile per il lavoro da postazioni remote.

Fortunatamente Unix basa tutta la sua configurazione su file di testo, ma a volte questi sono veramente difficili da editare per un umano. Capita allora che per aggiornare il vecchio printcap si usasse una utility grafica. Si noti che sto parlando di printcap, quindi l'era prima di cups, tmux e altre utility che hanno agevolato ulteriormente il lavoro remoto.

Ma non è questo il problema, il vero problema è che il sysadmin inesperto non sa di poter usare X a suo vantaggio. E così, invece che far eseguire l'applicativo grafico sulla macchina remota e visualizzarlo sulla propria, scende alcuni piani di un edificio per andare fisicamente ad agire sulla console della macchina!

Nulla di grave, se non fosse che quando non si trova fisicamente nell'edificio il sysadmin deve prendere la macchina...

Sysadmin panics: history

Uno dei metodi migliori per imparare una cosa è l'emulazione, ovvero il tentativo di ripetizione di un insieme di operazioni.

Capita allora di incontrare qualche sysadmin che, forse imbarazzato dal chiedere spiegazioni o aiuto, inizia a emulare i comandi dati da un altro sysadmin nella speranza di riuscire a fare le stesse cose.

Capita anche che si voglia non condividere la soluzione ad un problema, e quindi non si voglia essere emulati.

A me capitò di essere "spiato" attraverso una delle funzioni piu' stupide e banali: la shell history.

E' presto detto: io inserivo dei comandi attraverso il mio utente, tali comandi rimanevano nel ring della shell history e un altro sysadmin, mediante superutente, leggeva i miei comandi. Addirittura in tail come fosse un log.

La cosa ovviamente mi mandò su tutte le furio, ed ecco che linkare la history a /dev/null e azzerare il numero di entries fu' la mia reazione immediata. Per poi trovarmi i settaggi rimodificati al login successivo.

Ovviamente non si può molto contro un superutente, ed ecco quindi che viene in mio soccorso ancora una volta Emacs: dired e un qualche package per terminale e la battaglia fu' presto vinta.

Sysadmin Panics: eliminare i commenti

Quando si produce del codice, in qualunque linguaggio, sia di scripting che di programmazione, i commenti rappresentano una parte fondamentale del sistema stesso. Si prenda esempio da quei progetti che non permettono a buon codice di "colpire" l'albero principale se non è opportunamente commentato e documentato.

L'idea è ovvia: anche se il codice è funzionalmente il migliore del mondo deve essere manutenibile da altre persone, che potrebbero non capire a prima vista (e anche alle viste successive!) il comportamento stesso.

Io credo, ho sempre creduto anzi, nell'importanza dei commenti nel codice, a qualunque livello.

Altri esperti non la pensano come me.

Mi è quindi capitato, mantenendo un sistema composto da diversi server, di trovare alcuni miei script modificati da un giorno all'altro. La modifica era semplice: tutti i commenti erano stati rimossi.

Motivo? Portavano via spazio!

Meglio non commentare sia l'azione che la motivazione.

Vediamo però di essere maliziosi: se si è un dipendente il costo/stipendio non viene stabilito in base al tempo nel quale si risolve un problema, e anzi si cerca di ottimizzare lo stipendio fisso risolvendo piu' problemi nello stesso tempo. E' quindi di importanza strategica la documentazione per una rapida comprensione di cosa un programma/script/task sta tentando di fare.

Se invece si è un consulente esterno, pagato a tempo, il fatto che occorra piu' tempo per leggere e comprendere un programma decommentato non è un problema per il sysadmin stesso, anzi potrebbe essere fonte di ulteriori guadagni...

Pensateci la prossima volta che vi trovate da uno dei due lati della barricata: potreste evitare figuracce o costi inutili.

Sysadmin Panics: usare rottami per server

Uno degli indiscussi vantaggi di molti software Open Source, in particolare dei sistemi operativi, è che spesso non sono ingordi di risorse hardware. Ci sono varie spiegazioni per questo: alcuni progetti vengono di fatto sviluppati su computer datati (per mancanza di fondi), altri progetti come OpenBSD si obbligano ad essere compatibili con la loro base di installato, e in generale non c'è la necessità di dover spingere sul mercato una nuova release che forzi l'utente a comprare nuovo hardware.

In breve quindi con il software Open Source anche un vecchio computer può funzionare egregiamente. Quante volte si è sentito dire che anche un datato Pentium I può fare da firewall! Io stesso ho recuperato pc vetusti con i quali poi ho fatto videoconferenze o il rendering di una stanza di casa...

Ma un conto è riciclare un vecchio computer, un conto è basare la propria filosofia di deployment su questo concetto. Sia chiaro, tutti vorrebbero risparmiare sull'hardware, ma a me sono capitati casi raccapriccianti.

Piu' volte sono stato forzato ad usare dei vecchi server HP, del peso di una lavatrice, come firewall. E concettualmente tutto funzionava: qualche scheda di rete buona, un paio di dischi SCSI, un po' di memoria, e a regime nessuno si accorgeva dell'età del server. Fino a quando non c'era un problema e il server andava reboottato: improvvisamente tutti gli utenti si accorgevano di quesi 3 minuti spesi nel controllo POST del BIOS e dal minuto necessario al controller SCSI per essere sicuro di aver enumerato tutti i dischi!

Ancora peggio: una volta mi venne chiesto di usare un firewall già riciclato come server per una installazione satellite. Ricordo un solo computer che alla pressione del comando ls faceva passare un secondo prima di mostrare il risultato, ed era l'8088 di mio nonno. Ebbene il server di cui sopra faceva passare due secondi. Ma non era costato nulla!

Nei casi di cui sopra, piccoli esempi in fondo, si parla comunque di hardware buono, e quindi adatto a lavorare in un deployment classico (computer sempre acceso, dischi continuamente in utilizzo, alimentatori ridondati, ecc.). Ma quando si passa a voler usare un EEE PC come server solo perché sopra ci si può installare Linux e un qualche database relazionale....beh forse è il caso che si riprogetti il tutto.

Il solo fatto che hardware vetusto, o hardware compatto, possa svolgere allo scopo non significa che debba. Le velocità dei dischi contanto, e la risposta del database può far infuriare i vostri utenti, arrivando a vanificare il risparmio ottenuto. L'hardware conta: il buon hardware costa, ma spesso ripaga.

L'hardware vetusto trova ancora spazio, se in buone condizioni e con la giusta ridondanza. L'hardware compatto va bene per gli esperimenti e le postazioni di emergenza.

 

cron > /dev/spam

Penso sia capitato piu' o meno a tutti i sysadmin di qualunque razza, età e professionalità di crearsi uno o piu' programmi o script per il monitoring di una qualche risorsa specifica. Non importa quale sistema di monitoring si usi, prima o poi occorre qualche riga di codice Perl o Shell per tenere sotto controllo una risorsa, il classico quick and dirty.

E siccome i sysadmin sono anche pigri, meglio dotare il proprio script di un alert via e-mail quando qualcosa va male.

E per essere proprio sicuri che il disastro non passi inosservato si manderà tale alert a piu' persone, in modo che anche in caso di assenza qualcuno possa dominare la situazione.

Fin qui tutto regolare, nulla di sconvolgente.

Se non fosse che ci sono sysadmin che semplicemente ignorano gli alert inviati da cron (e per esperienza sono gli stessi che fanno un update senza leggere le release notes!). Diversi anni fa ne ho conosciuta una tipologia che non solo ignorava gli alert, ma li classificava anche come spam!

Come ci si accorge di un simile atteggiamento? Ebbene io diversi anni me ne accorsi perché, durante una giornata di ferie, ricevetti una telefonata che mi informava che il servizio di posta si rifiutava di inviare nuove e-mail. Apparentemente un problema al demone stesso, o questo è quello che si pensa subito, fino a quando non ci si collega e si trova nella propria inbox qualche pagina come segue:

In breve il server di posta aveva, in un certo senso, fatto il suo dovere collassando sotto l'enorme mole di e-mail inviate da uno script che ogni minuto controllava una risorsa non disponibile inviando poi una mail di lamentela.

E ovviamente, nessuno prima si era accorto del fattaccio perché le e-mail veniva scartate a priori....

Quindi meglio essere sicuri che le e-mail siano trattate per quello che sono: delle risorse che vanno anch'esse controllato (manualmente). E meglio anche evitare che ogni minuto uno script fatto a mano si incazzi!

Sysadmin Panics: script di backup (ma non di recovery!)

Ogni tanto inciampo ancora in qualche script ben fatto per il backup automatico dei sistemi *nix, e spesso mi torna alla mente quanti script orrendi ho dovuto correggere a tal proposito in passato.

Due erano gli errori piu' ricorrenti che mi causavano diversi grattacapi:

1) test sbagliati o fallimentari sull'esistenza di backup precedenti;

2) mount errato o multiplo di locazioni di backup remote.

Per quanto riguarda il primo, test sbagliati sull'esistenza di backup precedenti, l'errore era spesso tanto semplice quanto subdolo: lo script presentava uno "slurping" test che non eseguiva il backup in caso di assenza di una copia precedente. In altre parole qualcosa del tipo:

if [ -f backup.zip ]

then

  mv backup.zip old_backup.zip

  # fai nuovo backup

fi

Ora in cosa e' fallimentare questo test? Se viene rimosso l'entry che segnala la presenza di un backup l'intero script non esegue. Ok, ma perche' dovrebbe essere rimosso da storage il backup precedente? Perche' ad esempio si e' aggiunto un disco nuovo (vuoto) o perche', in una fase di panico, si e' cancellato tutto il backup pregresso per fare un punto zero. E lo script di cui sopra puo' fallire silenziosamente facendo trovare il sysadmin di turno in una situazione in cui il backup di fatto non c'e'!

La soluzione e' ovvia e semplice:

if [ -f backup.zip ]

then

  mv backup.zip old_backup.zip

fi

# fai nuovo backup

Il secondo tipo di problema e' un po' piu' complesso: se il backup deve essere fatto su uno storage esterno e' bene che questo sia montato e smontato quando serve, per evitare contaminazioni dei dati. Il problema e' che spesso questo storage esterno viene condiviso via SMB o NFS, e il primo in particolare consente lo stacking mount ricorsivo, causando qualche problema nello smontaggio. La soluzione anche qui e' semplice ma un po' laboriosa: occorre montare e smontare i volumi testando il valore di ritorno delle chiamate di sistema. Altrimenti si rischia di non smontare un volume o, peggio, di fare il backup su una directory invece che su una share (e magari riempendo tutto il filesystem)!

E in generale l'insegnamento spesso dimenticato e' che non si puo' dire che una procedura di backup funzioni fino a quando non si e' fatto almeno un recovery positivamente.

Sysadmin panics: history al posto della documentazione

Non ho mai fatto molto affidamento sulla history della shell, in parte perché sono troppo pigro per cercare nella history, in parte perché non tutte le shell si comportano in maniera analoga riguarda l'history e infine perché invece che ricercare e ripetere lunghi comandi cerco sempre di realizzare degli script.
Ma quella che vado a narrare è una storia che mi capitò diversi anni fa quando l'history venne usata per spiarmi. Eh si, perché invece che domandarmi come si facesse a fare determinate cose, un mio ex collega penso' bene di usare l'history di account condiviso per imparare e controllare le mie azioni.
Ok, ci sono due errori qui: il primo è quello di avere un account condiviso, ma ogni tanto serve un compromesso; il secondo è quello di lasciare la storia attiva su un account appunto condiviso, ma ogni tanto si deve concedere fiducia al genere umano.
Ma quando ho capito che, invece che leggere la documentazione che ogni volta scrivevo e manutenevo, il collega pigro non faceva altro che consultare l'history e ripetere a scimmia i comandi senza nemmeno capirli, decisi di prendere provvedimenti. Il primo e ovvio fu quello di rimbalzare l'history a /dev/null, e magicamente tutte le sessioni precedenti si svuotarono dei loro comandi. Oggi dovessi trovarmi nella stessa situazione userei un "trucco" ancora migliore e maggiormente impenetrabile.
Ad ogni modo il rimbalzo di /dev/null non fu sufficiente a sviare l'ex collega dalle intenzioni maliziose, a tal punto che lo trovai che spiava le mie sessioni interattive direttamente guardando il mio monitor e usando il tracking dei miei processi...
Ma leggere la documentazione e le istruzioni che fornivo non era piu' facile?

RAID: Redundant Array of IDiots!

RAID, ovvero Redundant Array of Inexpensive Disks.

Una sigla che tempo fa solo i sysadmin di alto livello conoscevano, e ora un acronimo che si trova sulla confezione di parecchie motherboard di fascia commodity.

Ne ho configurati tanti di sistemi RAID, sempre a livello enterprise. I primi software, perché l'I(nexpensive) è troppo spesso sinonimo di gratis. Poi sono arrivati i controller hardware, tanto costosi quanto veloci e affidabili. Sia chiaro, non mi sono mai pentito di un RAID software e, complice la fortuna, non ho mai avuto dei problemi che un softraid (ora md) o un GEOM non sia stato in grado di risolvere. E se oggi dovessi fare un RAID nuovo valuterei il software come primo investimento.

Ma questo post non è relativo a ciò che io penso del RAID, quanto alla esperienza accumulata vedendo sysadmins configurare RAID in modo piuttosto sconclusionato.

Pazienza fare il RAID fra dischi di taglio differente, dopotutto con un po' di lavoro su MBR ci si riesce ancora. Ma usare dischi di velocità differenti è veramente da virtuosi! 

Per non parlare di quando si tenta di fare un RAID con il numero sbagliato di dischi, o con troppi dischi di spare (comprare 8 dischi per fare un RAID con due dischi di spare, ad esempio). O di quando si pensa che un RAID 5 sia robusto quanto un RAID 6 e, per pura assunzione matematica, un RAID 10 è il top perché è semplicemente quello con il numero piu' alto...

E per finire: configurare una serie di dischi in un modo RAID per poi trovarsi con molto meno spazio di quello stimato. E pensare pure di aver fatto le cose giuste senza rendersi conto che si è solo sbagliato livello di RAID.

Dalla gigabit ehternet ai gigabyte USB

In Network Flow Analysis, l'autore M. W. Lucas inizia con una frase che può essere tradotta grossomodo come:

tutti gli amministratori di qualunque livello sognano una sola cosa: che gli utenti stiano zitti

Ebbene conosco casistiche inverse, ove sono gli utenti a sperare che il sysadmin stia zitto (e possibilmente fermo!). Ho visto intere reti LAN spaccate a metà in dimensione e velocità, utenti arrabbiati per malfunzionamenti e velocità ridotte alla pari di un modem ISDN. Ebbene cari amministratori di sistema e/o di rete, quando i vostri utenti iniziano a trasferire i dati su chiavetta USB invece che usare la rete, ponetevi qualche domanda, perché il vostro refactoring non è andato a buon fine!

Sysadmin panics: nomi di risorse

Qualche giorno fa seguivo un interessante thread su quali nomi vengono dati alle proprie macchine/servizi, e questo mi ha riportato alla mente alcuni esempi di cattiva nomenclatura.

Mi è capitato di assistere ad un cattivo uso dei nomi da parte di un sysadmin immerso nel suo panico: ogni workstation, ogni utente, ogni stampante, ogni cartella di rete prendeva un nome dipendente dal numero di telefono dell'utente stesso. Anzi, per dirla tutta, non dipendente dal numero di telefono, ma uguale (ove possibile) al numero di telefono stesso. Ovviamente mi riferisco al numero di interno, quindi 3-4 cifre al massimo.

Perché la cosa non ha senso?

La prima motivazione, abbastanza ovvia, è che avere uno username numerico su un sistema è una idiozia. Si provi a pensare all'output dei comandi di amministrazione anche piu' banali che riportano, a fianco del PID (numerico) di un processo uno username anch'esso numerico; la confusione è presto garantita! Inoltre alcuni sistemi non accettano username completamente numerici, e questo era il caso di cui sopra, ove si era quindi creata una certa eterogeinità fra username alfanumerici, cartelle numeriche, stampanti numeriche, ecc.

La seconda motivazione, forse meno ovvia, percui questa scelta sia ridicola, è che non scala efficientemente. Le persone cambiano numero di telefono, anche se non spesso, e questo significa dover riconfigurare hostname, username, cartelle, nomi delle stampanti, code di stampa, permessi...quando la persona di fatto è rimasta la stessa, e la cosa cambiata non ha nemmeno influenza sul sistema informativo. Molto meglio allora nominare le cose sulla base delle persona, con il classico , in modo da poter identificare ad-personam le risorse.
Terza motivazione, ancora meno evidente: le persone vengono sostituite anche solo temporaneamente. Supponiamo che alla postazione 666 la persona si assenti per un periodo (es. maternità) e venga sostituita dalla persona della postazione 999: che identificativo deve avere la persona che cambia la postazione? La logica vorrebbe che abbia 666 come identificativo, per rispettare la postazione sulla quale lavora, ma di fatto questo riflette una situazione non reale e poco gestibile: che permessi deve acquisire la persona? Quelli della postazione 666 uniti a quelli della postazione 999? I permessi in XOR?
Insomma, di tutti gli schemi dei nomi che ho visto fino ad ora, questo è sicuramente il piu' imbarazzante con il quale mi sono trovato a lavorare. Chissà, forse ha qualche lato positivo, ma io francamente lo ignoro.

Sysadmin panics: EOL

EOL in informatica puo' significare diverse cose: "End Of Line", se visto da un programmatore, oppure "End Of Life" se visto dal lato di un sysadmin. Ed e' proprio questo aspetto argomento di questo post.

I sistemi informatici solitamente hanno un ciclo di vita ben definito, e la scelta di un sistema piuttosto che un altro, nonché di una versione piuttosto che di un'altra è proprio un argomento che va affrontato controllando anche la EOL del prodotto stesso, cosa che spesso viene trascurata.

La EOL è importante perché il produttore, sia esso commerciale, una community o un singolo sviluppatore, non fornira' nessun tipo di supporto per un prodotto che ha raggiunto la EOL. Questo ovviamente non significa che il prodotto smetterà di funzionare, ma usare un prodotto EOL significa essere soli e navigare a vista. In altre parole, se viene identificato un bug su un prodotto EOL, nessuno si occuperà ufficialmente di preparare un bug-fix. Il che, è giusto chiarirlo, non significa che non ci saranno bug-fix, ma che se questi si trovano solo dovuti alla buona volontà di qualcuno o all'uso di risorse indipendenti (anche commerciali) non mainstream.

Eppure, nonostante queste banali considerazioni, vedo molti miei colleghi in panico perché scoprono, improvvisamente, di avere prodotti EOL e di non saper prendere la decisione se aggiornare o meno. La resistenza all'upgrade è sempre la stessa: se funziona, perché cambiarlo? E spesso la scelta che viene fatta è quella di fare l'upgrade solo quando si presenta un reale problema da giustificare un downtime.

Inutile dirlo: è la scelta sbagliata!

La EOL dei prodotti solitamente è di anni, 5 o forse piu', mai meno di 2 (almeno dalla mia esperienza pratica). Se un prodotto va in EOL significa che non sono stati fatti aggiornamenti importanti negli ultimi 2 anni almeno, ovvero non ci si sta curando dei propri sistemi.

Inoltre noto che molto spesso si raggiunge la EOL perché si presta attenzione solo alla numerazione, che magari varia di poco. Se il prodotto "x" passa dalla versione 8 alla 9 nel giro di qualche anno, il salto tecnologico è sicuramente notevole, ma visto l'incremento di un solo valore decimale, spesso non gli viene data importanza. Si consideri ad esempio FreeBSD: al momento in cui scrivo la versione (-stable) piu' recente è la 9.1, e le versioni disponibili sono la 9.0, 8.3. Il salto da 8.2 a 9.1 non sembra così grande, ma in realtà la 8.2 è del 2011 e si trova al momento in EOL.

Se posso essere (parzialmente) concorde con chi sostiene che non ha senso correre dietro ad ogni minor release, spero che almeno queste considerazioni sulla EOL dei prodotti spinga qualche collega nel panico a prevedere regolari update.

Sysadmin panics: cheap hardware

Uno degli effetti principali dei movimenti Free/Open e' stato il supporto ad architetture dismesse e/o obsolete. In breve, non dovendo piu' forzare gli utenti a comprare nuovo hardware per soddisfare una qualche alleanza con i vendor (o per mascherare i propri bug ed inefficienze con un sistema piu' potente), l'utente ha la liberta' di eseguire il sistema operativo e le applicazioni sull'hardware che ha a disposizione.

Effetto collaterale: molti sysadmin si fanno vanto di riuscire a fare deploy di interi stack full-feature su macchine obsolete e quindi a basso costo.

Ed e' possibile, sia chiaro! Io stesso ho usato piu' volte vecchi server "di riciclo" per fare upgrade o repliche. Per non parlare del mio parco computer personale: vecchi PC e Mac ai quali ho restituito dignita' grazie a sistemi Open Source non avari di risorse.

Quindi qual'e' il punto?

Essere coscienti dei limiti del proprio hardware.

L'hardware si usura.

L'hardware si rompe.

L'hardware puo' avere dei bug (o meglio il suo firmware puo' averli).

Usare quindi hardware di riciclo invece che un sistema opportunamente dimensionato pone il sistema che si implementando ad una serie di rischi di sicurezza, durata, stabilita' che devono essere tenuti in considerazione.

Usare un netbook come server di rete e' possibile, ma si perde, ad esempio, la possibilita' di fare un RAID dei dati. Ora, se questi sono sottoposti a regolari backup, e la continuita' operativa non e' stringente, la cosa e' possibile. Spacciare invece una simile soluzione come una "genialata" che fa risparmiare soldi al cliente e' invece un azzardo.

Comprare vecchi server per pochi euro non significa aver risparmiato: significa aver comprato una macchina dismessa e prossima alla morte fisica dell'hardware. Nulla a cui affiderei i miei dati piu' importanti.

La soluzione e' quindi comprare sempre hardware nuovo fiammante? No!

E' semplicemente prendere coscenza di quello che si ha per quello che si spende. Un po' come quando si compra una macchina usata e ci si interroga su come il precedente proprietario l'abbia trattata.

E si presti attenzione: il fatto che il proprio OS preferito giri su tale pezzo di metallo non significa che i risultati siano eccellenti.

Sysadmin Panics: changelog, commit, copy-and-paste

Per un motivo che non riesco a spiegare esistono ancora su questo pianeta dei sysadmin che usano gli strumenti di controllo delle versioni in modi barbari. Ora, e' vero, gia' e' una gran cosa che usino tali strumenti, ma almeno che spendano una manciata di secondi (si noti, secondi!) in piu' per usare tali strumenti al meglio.

Capita infatti che alcuni sysadmin in evidente stato confusionale usino gli strumenti di controllo delle versioni come un CHANGELOG: in sostanza associato ad ogni modifica (o peggio ancora in ogni singolo file) questi mantengono un changelog il cui contenuto e' esattamente identico a quello dei loro messaggi di commit.

Il caso piu' demenziale al quale ho assistito e' stato quello di un sysadmin che sistematicamente inseriva, in cima ad ogni file (!) un changelog delle modifiche appena fatte come ad esempio:

31/12/2010: ho fatto foo

per poi fare copia in colla del messaggio (!!) all'interno del messaggio di commit del sistema di revisione. In sostanza quindi leggere i log del sistema di revisione e/o ogni singolo file produce lo stesso risultato, che e' quello di avere un changelog. Tuttavia questo richiede sforzo doppio da parte del sysadmin...e francamente non ho mai trovato nessun programmatore fare una simile cosa, penso perche' dotato di maggiore comprensione degli strumenti.

Se quello che si vuole e' veramente avere un log anche all'interno dei file in questione si abbia almeno la decenza di usare le variabili auto-magiche che il proprio ambiente di revisione mette (sicuramente) a disposizione.

Sysadmin panics: mailto /dev/null

Uno dei grossi vantaggi delle e-mail e' che fondamentalmente se ne possono mandare una grande quantita' in poco tempo e con poco sforzo.

Ecco quindi che molti server e servizi sono configurati per mandare delle e-mail di notifica ai propri sysadmin per avvisarli di qualcosa che non va (il sysadmin e' solitamente pigro e usa il principio "nessuna nuova, buona nuova" che impone di leggere avvisi solo per cose che realmente non funzionano!). Ma se le disperate richieste di attenzione da parte di un server lasciato solo al proprio destino non vengono considerate dal  sysadmin, cosa succede? Il server solitamente e' piu' educato del sysadmin e manda nuovamente una mail al suo owner sperando in un po' di compagnia e comprensione.

Ho conosciuto un sysadmin che, fiero e spavaldo, affermava di cestinare tutte le e-mail dei suoi server perche' ne riceveva troppe. Ah, se mi avesse dato retta e avesse configurato i server per mandare le informazioni solo quando necessario, forse si sarebbe accorto delle oltre 1000 e-mail spedite in meno di 24 ore dai suoi sistemi. E si badi, non e' solo un problema di "mark all, delete" nella inbox del sysadmin: se un server invia grosse quantita' di e-mail in poco tempo viene facilmente catalogato come spammer e si corre il rischio di vedere cestinato future comunicazioni inviate a terzi. E se poi ci passa un week-end di mezzo, la possibilita' di essere marcati come spammer diventa rapidamente una certezza.

Sysadmin panics: Stupid Smoking Humble!

...oppure SSH, la differenza risiede solo nel fatto che i sysadmin in panico di cui racconto non hanno ancora capito cosa questo dono del progetto OpenBSD sia. Eh si, perche' loro, i sysadmin in panico, sono cresciuti nell'ovatta del Telnet e guardano con disgusto a questo "nuovo" modo di connessione remota in terminale. 

Sembra incredibile, ma ho conosciuto sysadmins che non avevano mai sentito parlare di X-forwarding, e che ogni volta che un accesso al terminale X era richiesto si alzavano dalla sedia per raggiungere la console. Ora il fatto che ci sia X in console e' un'altra storia; il punto nodale qui e' la mancanza di controllo. Va bene, se la console e' vicina (un'altra stanza? un altro piano?) si puo' anche fare, e due passi non possono che fare bene.  a se la console si trova in un altro edificio? In un'altra citta'? 

PuTTY ha fatto un gran servizio facendo approdare SSH anche sui client Microsoft Windows, ma ha sbagliato una cosa fondamentale permettendo, nella pura logica Windows, di memorizzare la password di  login. 

Come come? Un SSH client con la password pre-impostata? 

Ebbene si, ho assistito anche a queste  configurazioni, e a nulla e' valso il mio modesto tentativo di spiegare le chiavi SSH. 

Chiavi SSH?  

Perche' SSH va messo in moto come un auto? Gia', le chiavi SSH, grande mistero dell'universo dopo le donne!

Una volta mi venne chiesto come mai una connessione di copia (rsync) via SSH da un giorno all'altro aveva  niziato a chiedere la password.  Chissa', forse perche' qualcuno ha modificato le chiavi del server?  Addirittura una volta sono state rimosse le chiavi dell'utente per fare spazio (come le chiavi occupassero cosi'  anto spazio). 

E il file known_hosts? Che rottura: ogni volta che si aggiornano le chiavi di un server anche questo va modificato di conseguenza. Soluzione rapida del sysadmin in panico: cancellare il file! Ebbene si, perche' e'  piu' facile rispondere "yes" ad ogni nuovo host che deve essere memorizzato (nuovamente) piuttosto che  modificare una singola riga di un file di testo! E speriamo che nessuno abbia compromesso uno di quei server  a cui fingerprint dobbiamo nuovamente accettare. 

SSH fa del suo meglio, avvisando il sysadmin che "IT IS POSSIBLE THAT SOMEONE IS DOING  OMETHING NASTY!". 

Povero SSH, non sa che e' proprio il sysadmin a compromettere il sistema!

Sysadmin panics: stranezze

chmod? chown!

Piu' volte ho visto l'uso di chmod al posto di chown.
Situazione: si vuole dare accesso ad un file o una directory ad un utente che non e' proprietario o non risulta
nel gruppo proprietario.
Cosa si fa quindi?
Un bel chmod 777 e si risolve il problema.
O se ne creano altri (di problemi)?

Eh si, perche' un chmod 777 implica dare anche il permesso di esecuzione a tutto il mondo. E' veramente questo che si vuole? Si vuole poter eseguire un file di testo (che magari viene inavvertitamente infettato e si  tramuta in uno script malevolo)? 

No, quello che si vuole e' zittire rapidamente l'utente dandogli l'accesso. 

La soluzione corretta e' quella di inserire l'utente nel gruppo giusto, facendo nel caso un chown del 

file/directory in modo da consentire la corretta profilazione. 

Se poi si e' dei virtuosi, le ACL possono aiutare!

crontab & chmod = chmod on steroids!

Si e' mai visto una linea in crontab del tipo:

* * * * * * chmod 777 /path/to/some/public/share/*

Io l'ho vista!
Cosa fa?
Modifica ogni minuto i permessi di ogni file in una cartella pubblica dando ogni permesso ad ogni possibile
utente del mondo. Si valuti se la configurazione della share e' quella desiderata e se veramente lo spool del
server debba essere usato come un keyboard-monkey!




Pippo, Pluto e Paperino

Come non sopporto la gente che continua a nominare i file come "pippo", oppure "pluto" oppure "paperino".

Alcuni studenti lasciano la loro home directory piena anche di file dai nomi ben piu' volgari, ma che un  sysadmin debba usare ancora nomi cosi' ridicoli per i propri file di configurazione e' una vergogna.  

Ma ancora peggio e' chi inserisce tali file in un sistema di controllo delle versioni: che senso ha memorizzare la storia di un file di nome pippo127.sh che, evidentemente, o non cambiera' mai (sara' sostituito da pippo128.sh) oppure cambiera' totalmente!

Cavi, label, diagrammi e mount point

Ovvero: siate ordinati, siate coerenti. Se un server dispone di piu' schede di rete, le si rinomini opportunamente e si etichettino i cavi e le prese. E possibilmente, quando si modifica qualcosa si tenga il sistema dei nomi aggiornato! E' frustrante cercare di capire come mai il firewall sta facendo passare il traffico  fra l'interfaccia WAN1 e DMZ indiscriminatamente solo per scoprire che la prima interfaccia e' stata riconfigurata per operare come LAN...
E a tal proposito, si scelgano dei mount point con nomi significativi: non serve a niente montare un device in rete come /mnt/storage, a meno che il dispositivo remoto non si chiami effettivamente "storage". Molto meglio codificare il nome del dispositivo, come ad esempio NAS_p1_s37 (NAS al primo piano nella stanza 37) e si usi un mount point opportuno come /mnt/NAS_p1_s37. Meglio ancora, si suddividano i mount point  per tipo e priorita', cosi' che gli script possano smontare o rimontare tutti i device agilmente come ad esempio /mnt/NAS/NAS_p1_s37.



Commenti da lasciare senza commenti!

Gran cosa i commenti: consentono al sysadmin di aggiungere delle annotazioni nei file di configurazione per  indicare perche' si sta facendo quello che si sta facendo. O almeno per esprimere al mondo quello che si vorrebbe fare (che poi ci si riesca e' un'altra cosa!). Ma i commenti sono utili solo se sono mirati, ossia se sono posizionati nel punto della configurazione alla quale il commento si riferisce. In altre parole, mettere dei commenti in cima ad un file specificando cosa si fa nel file in un punto imprecisato (tipicamente almeno una  videata sotto) e' totalmente inutile. E peggio ancora e' tenere la storia dei commenti nello stesso file: si usi un  sistema di controllo delle versioni per tenere traccia della storia evolutiva di un file.

Sysadmin panics: boot & mail

Almost (un)booting...

Capita che anche i server decidano di riavviarsi. Che si tratti di un panic, di mancanza di corrente (al punto da spegnere il gruppo di continuita') o di un problema hardware, il risultato piu' o meno e' lo stesso: il server deve fare un nuovo boot. 

Capita anche che il sysadmin in panico non abbia ben compreso la modalita' di boot della sua creatura, e magari confonda un System V per un BSD o viceversa. 

Ecco quindi script di boot mal configurati che montano cartelle di rete prima che il networking sia pronto. O peggio ancora, script di boot che bloccano completamente il boot chiedendo per password di root o altro. Vale la pena testare sempre l'ambiente di boot del proprio server...

Sendmail and Friends

Alcuni sysadmin ancora faticano a comprendere che sendmail non solo e' un demone di posta, ma e' anche un programma client che si collega ad un SMTP qualsiasi. Ne consegue che quest'ultimo puo'  essere usato per inviare e-mail automatiche anche attraverso SMTP differenti da Sendmail stesso!

Sendmail and Foes

Ormai tutti i server, di qualunque razza, inviano delle e-mail automatiche anche solo per notificare il syadmin di cosa sta succedendo. Ebbene, se la configurazione del demone di spedizione del server e' configurata opportunamente per fare il relay su un server MX di fiducia, per quale motivo ogni sysadmin pretende di installare il proprio mail client che richiede una differente  configurazione di relay? Si usi il "relay ufficiale" e si stia in pace con il mondo. Quando si cambiera' configurazione di posta ci si scordera'  di sicuro che il proprio client deve essere riconfigurato...

Sysadmin panics: gestione

Qualche altro racconto, mano a mano che mi tornano alla mente, sulle sventure dei sysadmin.

Mannaggia a 'sto LDAP!

Ebbene si, mi sono sentito rivolgere anche questa domanda da un sysadmin impavido (e impertinente): "ma a cosa server tutto 'sto LDAP?". Lo ammetto, la gestione LDAP è sicuramente piu' complessa di quella plain, ma è sicuramente migliore di quella NIS (si, mi è capitato di dover gestire anche questo). Inoltre molti dei tools LDAP sono buggati e non funzionano benissimo, cosa che complica ancora di piu' la gestione di molti account. Tuttavia, proprio perché gli account sono molti, si pensi al tempo risparmiato per impostare con un unico account i livelli di accesso a diversi servizi (storage, condivisione file, terminali interattivi, chat, ...).

Tutti 'sti gruppi?

Continuando sulla falsa riga del precedente paragrafo, non si sia avidi nel creare gruppi di utenti: servono per la profilazione e possono essere molto utili. Quindi invece di continuare a creare gli utenti nel gruppo users o peggio ancora in quello staff (perché almeno voglio sperare che nessuno usi wheel), si definiscano dei gruppi per ogni tipologia di applicazione/servizio.

 rc, questo sconosciuto

Capita di trovare sysadmin incompetenti anche fra il personale docente dell'università, a volte addirittura fra i docenti di Unix! E così alla domanda "ma che cosa significano quelle string RC all'inizio di un file?" ci si può sentire rispondere un semplice "non lo so, mai capito e mai usato". Ah, che bella invenzione il controllo delle versioni dei file di configurazione!

Sysadmin panics: aggiornamenti

Gli aggiornamenti sono qualcosa che ogni sysadmin vorrebbe evitare come la peste, ma che purtroppo vanno tenuti in considerazione.

Aggiornamenti in produzione

E' inevitabile, prima o poi i server di produzione devono essere aggiornati. Le procedure di aggiornamento di molti sistemi oggi semplificano la vita ai sysadmin, fin troppo. Capita allora che qualcuno decida di fare a tappeto un aggiornamento del tipo yes-yes-confirm di un server in produzione a pieno carico di lavoro.
Si, so che può sembrare assurdo, ma l'ho visto dal vivo!
Cosa può succedere di male? Che qualche configurazioni non faccia piu' partire alcuni demoni! 
Risultato: server quasi inusabile. 
Backup? No! 
Piano di recovery? No!  
Buona fortuna!

Sindrome del reject-update

Ovvero  tutto quello che non c'è non si rompe!

Gli aggiornamenti sono importanti: risolvono bug, aumentano la sicurezza, aumentano (in genere) le prestazioni. Possibile che ci sia ancora chi pensa che non si possa aggiornare un sistema perché c'è troppo lavoro di configurazione? Ho visto procedure stagnare per colpa di demoni non aggiornati. Ci si domandi se non si è sbagliato a rendere la configurazione così version-dependent e si abbia il coraggio di riprogettare. Nel lungo periodo questa scelta pagherà di piu' e il monte ore risparmiato sarà maggiore di quello speso ad aggiornare.

RTFM!

Ammetto che questo capita anche a me, ma solitamente solo sul mio computer e non su sistemi in produzione. Si legga sempre cosa si sta aggiornando, e se tale aggiornamento rompe una qualche compatibilità e si valuti cosa fare. Ci si prepari comunque al peggio.

Sysadmin panics: maestra non sono stato io!

(ovvero Bikeshed on steroids!)

Grande invenzione le e-mail! Consentono di raggiungere tantissime persone alla distanza di un solo click. E proprio per questa semplicità la maggior parte delle persone, ivi inclusi certi sysadmin che ho avuto il (dubbio) piacere di conoscere, vengono usate in modo errato.

Situazione: un utente notifica il sysadmin di un problema tecnico. Non importa quale sia il problema nello specifico: potrebbe essere un demone fermo, un servizio malfunzionante, un problema di autenticazione o di profilazione, insomma, qualunque cosa di competenza del sysadmin. Ora, piu' o meno diligentemente il sysadmin verifica quanto detto dall'utente e realizza che non c'è nulla che non funzioni nei sistemi segnalati. Il guasto è quindi apparente e forse causato da un erroneo utilizzo dell'utente. 

Bene, cortesia vuole che il sysadmin risponda all'utente informandolo della non riscontrata anomalia. Questo basterebbe a chiudere il caso con buona pace di entrambe le parti.

Eppure un sysadmin dubbioso delle proprie capacità, per paura forse di essere crocifisso in sala mensa come nella classica tradizione di Fantozzi, si affretta a mandare risposta all'utente mettendo in copia anche i propri superiori.

Il dialogo quindi appare come segue:

From: utente generico

To: sysadmin di fiducia

Subject: Malfunzionamento?

Caro sysadmin,

oggi non sono riuscito ad usare/accedere/fruire del servizio/processo/procedura XYZ. Per favore, puoi controllare se qualcosa non sta funzionando a dovere?

From: sysadmin di fiducia

To: utente generico

Cc: superiore 1, superiore 2, capo supremo, god

Subject: Re: Malfunzionamento?

Caro utente,

non ho riscontrato alcun malfunzionamento. I servizi funzionano ogni giorno, ogni ora, ogni minuto nello stesso modo e con regolarità. L'errore deve essere tuo, per favore controlla di aver seguito la procedura di utilizzo in tua dotazione.

Quante volte ho assistito a dialoghi del genere, e forse parecchi anni fa sono caduto anche io (nel ruolo di sysadmin) in una simile trappola.
Cosa c'è che non va?
Il fatto che il sysadmin invii la comunicazione anche a dei superiori.

Quali superiori?
Beh, bisogna distinguere: se sono superiori del sysadmin, dell'utente generico o di entrambi.

Si consideri il primo caso (superiori del sysadmin): in questo caso il sysadmin sta gridando maestra non sono stato io!, ovvero sta cercando di dimostrare attraverso un semplice dialogo con l'utente finale di aver fatto tutto quanto in suo potere per garantire il funzionamento del sistema. L'effetto finale però è che l'utente percepisce l'insicurezza del sysadmin, che ha bisogno non solo di confermare quanto pensa, ma di confermarlo anche ai suoi superiori. Una sorta di "guardate quanto sono diligente".

Si consideri ora il secondo caso (superiori dell'utente generico): in questo caso il sysadmin sta comunicando qualcosa che suona come "oh, questo utente mi sta seccando, si lamenta di cose che non esistono". Il risultato finale è che l'utente non si fiderà piu' del sysadmin, visto che viene preso a pesci in faccia con una comunicazione riservata resa pubblica allo scopo di tentare una umiliazione.

Ma non è finita qui: in entrambi i casi i superiori in questione vengono tirati in ballo in una conversazione privata fra due parti (sysadmin e utente) della quale probabilmente non vogliono e/o non hanno interesse ad essere informati (altrimenti lo sarebbero stati fin dalla prima e-mail). Si consideri il tempo che una persona impiega per leggere la mail di cui sopra, pari a 1 minuto (incluso il tempo per fare click sul messaggio). Si sommi la distrazione del superiore, che viene gettato in una conversazione mentre era impegnato a fare altro. Si moltiplichi tale tempo per il numero di persone in Cc nella e-mail: si ottiene l'ammontare del tempo che il sysadmin, di sua iniziativa, ha deciso che l'azienda e le persone devono sprecare con una sterile polemica.

E comunque non siamo ancora arrivati al peggio.

Mi è capitato personalmente, qualche anno fa, di inviare una comunicazione confidenziale sul malfunzionamento di un server amministrato da un altro sysadmin. Questi mi ha risposto mettendo in Cc un terzo sysadmin cercando di fargli prendere non solo parte alla discussione, ma indirizzandolo verso lo schieramento a suo favore.

Soluzione al problema?
Francamente non ne ho. Posso solo consigliare tutti i sysadmin e, in generale, tutti gli utenti, di riflettere prima di inviare una e-mail: esiste veramente la necessità di coinvolgere le persone nella discussione o lo si sta facendo solo per acquisire sicurezza?