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.
