BETA 2099.3 - Una rete eterogenea ma gestibile

BETA 2099.3 - Networking: Una rete eterogenea ma gestibile - Indici | Guida

Una rete eterogenea ma gestibile

Parte I: interazioni interpiattaforma

Andrea Ghirardini
Articolista, BETA
Nessun ramo della conoscenza umana è esente da luoghi comuni e leggende metropolitane. Alcuni di questi si diffondono tramite i comuni meccanismi del passaparola, altri vengono inventati ad hoc tramite pubblicità e marketing al fine di indirizzare il cliente opportunamente.
Uno dei luoghi comuni più in voga al momento è quello che pone la semplicità e gli automatismi di un sistema operativo come il requisito più richiesto dal mercato. Unix, con le sue molteplici varianti viene considerato come un vecchio pachiderma: difficile, spartano e assolutamente ingestibile. Ma è davvero questa la situazione?
Un caso reale
Sodalia spa, una "software factory" di proprietà di Telecom Italia certificata ISO 9001 e SEI CMM Level 3, ha una complessa rete al proprio interno. In linea con lo "standard de facto" della piattaforma HP-UX nel campo del software per telecomunicazioni, la rete di Sodalia è composta principalmente di workstation PA-RISC HP a disposizione degli sviluppatori, di alcune workstation SUN e Digital Alpha e, ultimamente, qualche PC Intel. In tutto parliamo di circa 400 macchine Unix, fra macchine di test server e di produzione/sviluppo. Visto comunque il dilagare della piattaforma Microsoft anche Sodalia si è adattata ed ora sono presenti anche circa 200 PC, suddivisi tra piattaforme di sviluppo con Windows NT, alcuni server Windows NT per test e per il reparto di amministrazione, ed una serie di client desktop e notebook con Windows 95.è
Questa notevole quantità di computer viene controllata da un pool di system administrator. Sono 10 persone in totale. Di questi due si occupano attivamente dell'assistenza agli utenti Unix, quattro dei server Unix, Netware e Ntrigue e di progetti futuri, e due dei vari Pc a disposizione e praticamente una persona è riservata ai guasti hardware e alla manutenzione delle periferiche (stampanti per esempio) sparse per il palazzo.
Queste sole cifre sono sufficienti per cominciare a trarre alcune interessanti considerazioni. I due sys-admin Unix tengono a bada circa 200 workstation a TESTA, contro i 100 PC a testa di coloro che si occupano di tale piattaforma. Ciò non è dovuto ad una minore competenza di questi ultimi. Quindi qual è la ragione di questa differenza?
"Gestibilità" di una piattaforma
Sono convinto che questo sia un campo minato ma vorrei portare alla vostra attenzione alcuni problemi, comuni o meno noti, che un sys-admin si trova ad affrontare nella vita quotidiana.
Partiamo dalla security. In un ambiente come quello di Sodalia si deve tenere sotto controllo, per quanto possibile, la security. Questo può essere un compito particolarmente arduo visto il livello di medio degli utilizzatori che è tendenzialmente elevato. Preso per inciso che la password di root delle workstation personali non viene mai data all' utente, a meno che non venga richiesta esplicitamente tramite una domanda scritta e motivata (e anche in tal caso viene resettata dopo una settimana), rimane il problema che un utente particolarmente "smanettone" (il sottoscritto ne è un esempio) non cerchi di appropriarsene sfruttando i bug di HP-UX. Il problema, pur non impattando con gli standard qualitativi dell'azienda, è stato circoscritto tramite una serie di script che si incaricano di controllare, in modo automatico, che non ci siano programmi non autorizzati settati a SUID root (come le shell), facendo un parsing dei file .rhosts e resettando spesso la password di root delle varie workstation con una generata casualmente. I sys-admin possono in ogni momento entrare su una workstation tramite altri meccanismi. Il NIS (comunemente noto come yellow pages) si occupa di gestire in maniera centralizzata i login e la distribuzione dei file hosts, grous e passwd.
Per i PC si usano i Netware Directory Service per avere un sistema di logon centralizzato. Ovviamente è possibile lanciare una serie di programmi e azioni tramite i login script di Novell ma, date le limitazioni intrinseche dei sistemi Microsoft e la mancanza di un serio linguaggio di batch, le azioni possibili sono limitate. Inoltre Windows 95 manca di una seria gestione delle permission. Non è possibile quindi evitare che l'utente pasticci con il desktop, il registry e le altre componenti di sistema causando danni. Il policy editor di Windows 95 non è affidabile a sufficienza per poter essere usato estesamente ed inoltre non è compatibile con quello di Windows NT 4.0. Diverso il discorso per Unix: se si setta la directory /etc come read-only per chiunque tranne i sys-admin non è possibile giocare con le configurazioni. Inoltre le impostazioni del CDE possono essere reinizializzate facilmente ricopiando file della /etc/skel nella home-directory dell'utente.
Passiamo ad un altro fatto problematico. Se si entra nell'ufficio dei due sys-admin Unix è facilissimo trovarli seduti alle loro scrivanie intenti a digitare sulle loro tastiere. Unix, in tutte le sue varianti, è e rimane un sistema multiutente. Quindi loro possono lavorare tranquillamente in remoto tramite rlogin o telnet come se fossero seduti alla console. I sys-admin PC invece sono costretti a spostarsi continuamente per i 5 piani del palazzo di Sodalia. I sistemi Microsoft sono monoutente nel senso stretto del termine (specialmente Windows 9x) e quindi la presenza FISICA dell'amministratore davanti al PC è assolutamente TASSATIVA. Già questo contribuirebbe ad accumulare perdite di tempo notevoli.
Il campo del software applicativo è un'altra nota dolente. Per la piattaforma Unix la cosa è semplicissima. Il software viene installato una volta sola sul file server e da qui esportato tramite NFS e montato sulle workstation mediante il daemon Berkeley Automounter. Il vantaggio del file system standardizzato di Unix è notevole, visto che gli applicativi non vanno a copiare file in giro per il sistema in maniera pseudo casuale.
Con i PC il discorso è diverso. Si può sempre fare un'installazione tipo server (per i programmi, come Office, che lo prevedono) o copiare la directory di installazione sul server ma questo non esime dal fatto che poi l'installazione va ripetuta su ogni client dato che ogni volta una notevole quantità di DLL devono essere copiate nella System(32). Non dimentichiamoci delle chiavi del registry che devono essere variate/aggiunte dal programma di installazione. Moltiplichiamo per 200 client e vediamo come le giornate di un sys-admin possano essere buttate alle ortiche.
Anche l'aggiunta di una nuova workstation ha un diverso iter. I system admin Unix, assegnano l'IP number alla stazione, la sballano, la installano fisicamente, effettuano il boot attraverso la rete (qui grosso merito del firmware presente sulle macchine RISC) e quindi effettuano l'installazione tramite file server dove si trova un sistema HP-UX 10.20 tipo con già tutte le patch applicate e configurato secondo i dettami delle Guidelines della società.
Diverso il discorso per i PC. Purtroppo non esiste un sistema valido per fare un'installazione affidabile attraverso la rete, a meno di non crearsi un set di dischetti specifico per ogni diverso PC (diverso a livello di hardware) effettuare il boot con quello e poi prelevare il resto dal file-server. Obbiettivamente si fa molto più in fretta a fare il boot da CD-ROM e ad installare da questo supporto. Unica seccatura bisogna OGNI VOLTA installarsi a mano software e patch.
Per ovviare in parte a questo inconveniente in Sodalia si è cominciato ad utilizzare Drive Image della PowerQuest. Dato che i PC acquistati sono tutti HP, solamente il primo PC di ogni nuovo modello viene installato manualmente. Terminata l'operazione si effettua un'immagine del disco fisso e la si trasferisce su un CD-ROM. Tutte le altre macchine vengono quindi installate dall'immagine salvata e cambiando il nome macchina, l'ip-number, il SID (nel caso di Windows NT) e le altre informazioni specifiche. Questo metodo è anche utile nel caso si rompa il disco fisso di una macchina già installata. Gli utenti salvano infatti sempre nelle loro home directory in rete e quindi i PC possono essere reinstallati senza perdere informazioni.
Ultimo esempio è la configurazione di una stampante. Tutte le stampanti Unix vengono gestite da un unico server con il solito meccanismo di lpr/lpd. Quindi sulle singole workstation basta fare, tramite script o a mano, una modifica al file printcap per configurare velocemente il tutto. Con i PC è necessario installare i driver sul computer. Chi di voi abbia avuto a che fare con i nuovi ENORMI driver per le stampanti HP per i vari Windows (stanno su più floppy) sa benissimo che automatizzarne l'installazione è praticamente impossibile dato che usano un installer proprietario.
A tutto questo aggiungiamo una nota di colore. NFS è un sistema standard per tutti gli Unix ed è assolutamente interoperabile; idem per per gli script di configurazione del Berkeley Automounter e di controllo della security citati sopra che vanno solamente adattati per supportare una nuova piattaforma. Quindi per i sys-admin supportare una SUN o una stazione Alpha non richiede ulteriore sforzo che adattare gli script sul server nel momento in cui viene richiesto, per la prima volta, di supportare una nuova piattaforma.
Dalla parte dell'utente
Esaminiamo ora il punto di vista dell'utente per osservare alcune peculiarità e sfatare alcuni luoghi comuni.
L'interfaccia utente. Tutte le diverse macchine Unix di Sodalia, ma il discorso si può estendere anche ad altre realtà, montano di default il CDE (Common Desktop Environment). Per quanto questo ambiente non sia certo il massimo in nessun senso (estetico, funzionale, ergonomico...), è uno standard de facto tra gli Unix commerciali. Dato che i file di configurazione del CDE risiedono nella home-directory dell'utente, sono compatibili tra i diversi Unix, e i login vengono autenticati centralmente tramite il NIS, ognuno può loggarsi a qualunque workstation (sia essa SUN, Alpha o HP) sicuro di ritrovare il proprio desktop inalterato.
Sfatiamo inoltre un luogo comune. E' vero che che i diversi Unix sono sostanzialmente dei dialetti e quindi leggermente diversi gli uni dagli altri ma la base è assolutamente comune. Teniamo quindi presente che l'interfaccia POSIX per i comandi è la stessa e che i maggiori Unix presenti sul mercato (Sun Solaris 2.x e 7, HP 10.x e 11, IBM AIX, DEC OSF, SCO Unixware ma anche Linux) sono tutti derivati dalla grande famiglia System V e quindi hanno in comune anche la maggior parte della struttura del file system e degli switch dei vari comandi. Quindi saltare dall'uno altro, almeno dal punto di vista dell'utente finale non è assolutamente traumatico.
X-Windows inoltre è un ottimo strumento, spesso sottovalutato. La presenza di un protocollo di visualizzazione compatibile tra i diversi Unix è un toccasana in molte occasioni. Spesso infatti le macchine HP di Sodalia sono utilizzate pesantemente per compilare. Per evitare di appesantire ulteriormente la propria Workstation si lanciano quindi i programmi più voluminosi (come Framemaker o Netscape Communicator) su altre macchine. Uno dei PC con Linux presenti nel laboratorio di Reuse & Technology è usato dai membri del gruppo per lanciare Communicator in remoto, dato che la versione per Linux è infinitamente più stabile di quella per HP-UX. La cosa è assolutamente indolore per gli utenti che, dopo aver effettuato un rlogin sul PC, si limitano ad esportare il display sulla propria workstation ed a lanciare Communicator.
Conclusioni
Il mondo Unix è frammentato in molti dialetti ma questo è ben lungi dall'essere un problema, semmai è stato un modo per poter avere questo sistema operativo sul maggior numero possibile di piattaforme. Ciò che si evince, lavorando professionalmente con il mondo Unix è che quello che davvero fondamentale sono i protocolli e le standardizzazioni di base. Avere su diversi ambienti, le stesse shell, gi stessi linguaggi di scripting, le stesse librerie e protocolli di comunicazione rendono le differenze tra gli Unix assolutamente trascurabili. Questo si traduce in una maggiore gestibiità nel caso si abbia a che fare con una rete eterogenea. In effetti integrare una workstation HP con una workstation Digital è molto più semplice, a dispetto delle diversità architetturali, dell'integrare due PC Intel con Windows NT ed una versione di Unix. Nonstante il mondo Microsft si sia dotato di meccanismi come il plug'n'play, wizard ed altro pecca ancora di giovinezza e spesso tende a rendere pesante e ripetitiva la vita ai sys-admin che devono gestire una rete composta da un certo numero di client. Inoltre, la scelta della casa di Redmond di basarsi su standard proprietari piuttosto che aperti limita molto l'interoperabilità con altre piattaforme esistenti sul mercato.
Stiamo quindi attenti ai luoghi comuni ed alla pubblicità che ci bombarda attraverso le riviste specializzate. Spesso, nel mondo reale, le cose possono apparire diversamente.

Andrea Ghirardini è Collaboratore di BETA dal 1998; lavora come tester di nuove tecnologie e di sistemi di network e system management in Sodalia spa ed è raggiungibile su Internet tramite la redazione oppure all'indirizzo andrea@sodalia.it.
Copyright © 1998 Andrea Ghirardini, tutti i diritti sono riservati. Questo Articolo di BETA, insieme alla Rivista, è distribuibile secondo i termini e le condizioni della Licenza Pubblica Beta, come specificato nel file LPB.