Se dessimo retta alle pubblicità, alla propaganda aziendale e alle recensioni delle riviste (una terna che ha più punti in comune di quanti non si ammettano), ogni tre/sei mesi l’informatica compie passi da gigante scoprendo nuove tecnologie che nemmeno gli ultimi dieci minuti di un telefilm di Star Trek riuscirebbero ad eguagliare.

Purtroppo io mi trovo quasi ogni giorno da un numero incredibile di anni ad aver a che fare con server morti o in avanzato stato di compromissione. Ho cominciato il mio viaggio in questa terra di server problematici con Novell NetWare 2.x proseguendo con NetWare 3.x, NT 3.x, NT 4.x, Linux, Windows 200x. Diciamo che ho visto tanti cadaveri quanti ne ha visti un coroner, solo che i miei cadaveri sono al massimo polverosi, non sanguinolenti.

Vorrei esaminare qui due casi reali, ma reali davvero: non simulazioni con VMware, bensì due server che, per cause diverse, hanno avuto dei problemi e bisogna cercare di rimettere insieme i cocci.

Lo sappiamo tutti che ci vorrebbe un buon backup, un UPS con un reattore nuclare integrato, una computer room adatta e tante altre cose che però sono delle mere idee platoniche.

Prendo in esame, quindi, due casi reali simili: un server in cui le directory dei file binari di sistema sono andate irreparabilmente a pallino: in Linux CentOS parliamo di /bin e /lib, mentre in Windows 2003 SBS parliamo di %SystemRoot%\SYSTEM32

In entrambi i casi, un CD Live di Knoppix (o similare) e uno storage esterno USB ci permettono di salvare i dati. Il tempo di salvataggio è funzione della quantità di dati ed è, quindi, indipendente dal sistema installato. Nella nostra ipotesi immaginiamo che l’utente non abbia backup, ma che tutti i dati sul disco siano integri e leggibili.

Installazione del sistema operativo. CentOS 5.2 si installa in 20/30 minuti, più altri 20 minuti circa per gli aggiornamenti. Windows 2003 SBS Standard richiede almeno 60 minuti per l’installazione, a cui vanno aggiunti altri 60 minuti per l’applicazione del service pack, ulteriori 30 per gli altri aggiornamenti e 30 per il service pack di Exchange 2003. CentOS un’ora, Windows SBS 3 ore.

Ripristino della condizione precedente. Questo è il vero punto dolente di Windows. Per come sono strutturati i programmi di Linux, è sufficiente rimettere i file di configurazione (inclusi gli elenchi degli utenti, gruppi e password di accesso) e i file di dati al loro posto utilizzando il normale comando di copia dei file, avviare i servizi e tutto torna come prima. Tra operazioni vere e proprie e verifiche, ci balla un’altra ora. In poche parole, un Linux con SQL server, mail server, webmail, POP3, eventuale file sharing di rete con Samba, greylisting, antispam e orpelli vari torna online in due ore circa, facciamo tre ore: il tempo che Windows SBS impiega ad installarsi e ad aggiornarsi.

Ma il peggio deve ancora venire. Sotto Windows se non si dispone di un backup fatto con NTBACKUP (ah! in Windows 2008 non è più compreso nel sistema, grazie Redmond!) o un programma similare che registra lo stato del sistema, non è possibile ripristinare gli utenti. Se li si ricrea con il medesimo nome avranno comunque un ID differente da prima, quindi tutti i riferimenti di sicurezza vanno persi. Per questo stesso motivo non è possibile rimpiazzare brutalmente i file di dati di Exchange facendo una sorta di restore a freddo. Auguri.

Le noie non finiscono qui perché sui client bisogna ricreare il profilo utente ed eventualmente migrare quello precedente (c’è un trucco per farlo e fino a XP funziona senza problemi). Se si vogliono fare le cose fatte bene, balla una mezz’oretta a client circa, tra reboot copie e altro.

La bottom line. Windows server non è un sistema complesso, è un sistema inutilmente complicato, fatto di strati di compatibilità oramai inutili, di tecnologie abbandonate partorite del marketing. Fa un uso eccessivamente complicato dell’interfaccia grafica quando un sistema di interfaccia più spartano aiuterebbe l’amministratore di sistema. Se Windows server fosse veramente quel prodotto evoluto che ci sbandierano i signori del marketing, le operazioni di manutenzione sarebbero facili e immediate; sarebbe possibile ripristinare velocemente un sistema in panne; si potrebbe amministrare il sistema senza cercare ogni volta su Google la soluzione perché l’opzione che cerchiamo o è al sesto livello di sottofinestra o è una voce di registry che per qualche oscuro motivo non ha un elemento di interfaccia che la governa; non ci sarebbero help in linea mal tradotti, inutili e tautologici che servono solamente a far perdere tempo.

Uno dei grimaldelli utilizzati per convincere molte organizzazioni ad adottare Linux è sempre stata la bassa richiesta di hardware da parte di questo sistema operativo quando vengono paragonate a quelle di Windows Server. È una strategia che ha pagato moltissimo perché è tutt’ora possibile dimostrare che un qualsiasi PC desktop può essere utilizzato per ricoprire il ruolo di un server.

Se ciò aveva un significato quando i costi di un server erano cospicui, credo che ora il gioco al ribasso per i server Linux inizi ad essere un boomerang assai pericoloso.

I sostenitori di Linux sono spesso determinati a dimostrare la bontà del sistema e accettano troppe volte offerte al ribasso sull’hardware fino a raggiungere livelli ridicoli. Non dobbiamo più accettare che l’hardware di scarto di un’organizzazione diventi la base su cui viene costruito un sistema mission critical quale il NAS per i backup, il mail server, il web server della intranet, il fax server…

Se facciamo due conti, i compromessi e il tempo necessario per allestire un sistema funzionante, ma con performance imbarazzanti, costa molto di più di un server base con tre anni di assistenza on site. Per chiarire il concetto, il Dell PowerEdge T105 dell’ultimo server Linux che ho installato (mail server, pop e imap server, antispam, antivirus, firewall, due webmail, fax server) è costato meno di una licenza Windows Server ed ha un processore dual core a 64 bit, due dischi da 250 Gb con controller RAID e 4 Gb di RAM.

A parte la velocità con cui il sistema è andato online, gli utenti si sono accorti immediatamente della differenza rispetto all’hardware precedente (sempre un server Dell, ma un po’ anzianotto) e la soddisfazione dell’utente è uno degli scopi del SysAdmin.

I SysAdmin Linux più oltranzisti mi accuseranno di aver sovrastimato l’hardware e diranno che con meno della metà delle risorse avrei poruto mettere online il medesimo server. A queste persone rispondo che quel server è all’inizio dei suoi (almeno) tre anni di vita e partire con un sistema al limite del carico non è una scelta oculata perché con il tempo il carico può solamente aumentare. Inoltre, in caso di picchi di lavoro, un server non oberato di lavoro ha spazio di manovra per reagire nel migliore dei modi e per fare in modo che gli utenti non si accorgano nemmeno del picco di carico.

L’autunno è tempo di budget e questo non è certo un periodo di vacche grasse. Se è vero che, a parità di performance, molte implementazioni su Linux hanno richieste hardware inferiori, ciò non significa che un’organizzazione debba destinare gli scarti per i server Linux perché non si sta realizzando un risparmio, bensì la procrastinazione e la moltiplicazione di una spesa.