Sostituire un Server
Windows NT con Linux


di
Quinn P. Coldiron
traduzione di
Antonio Cartelli,
Officine Informatiche Srl

L'articolo è in realtà ben più che un semplice proclama a favore di Linux e a svantaggio del s.o. di Microsoft. E' un concentrato di informazioni, confronti sul campo e configurazioni da implementare per passare in maniera indolore da NT a Linux.



Copyright (c) 1997 Quinn P. Coldiron
qcoldiro@unlinfo.unl.edu


Indice

Introduzione

Sezione 1-- Analisi della situazione di partenza

Sezione 2-- Perché la scelta di Linux RedHat

Sezione 3 -- Più in dettaglio Appendice A -- Guida all'installazione della RedHat 5.0

Appendice B -- Samba

Appendice C -- Il manuale di DOSEMU
 



Introduzione

I Sistemi Operativi di Rete (NOS) hanno una notevole quantità di funzioni e strumenti che consentono ai Sistemi Informativi delle svariate organizzazioni di servire al meglio le strutture di loro pertinenza e facilitano lo scorrimento del flusso di lavoro. Ogni NOS ha caratteristiche diverse ed eccelle in aree particolari e così il Netware della Novell è stato sempre considerato come il miglior server nella gestione di file e stampanti, Unix è stato visto come il server principe di applicazioni e data base e, recentemente, Windows NT si è affacciato sulla scena come la scelta migliore, nell'ambito di piccole reti, quale server di file/stampanti e/o applicazioni. Il mercato, dal canto suo, è diventato molto aggressivo e ciascuna di queste piattaforme cerca di espandersi invadendo le nicchie di mercato delle altre. La Microsoft ha portato NT nel mercato dei server di media taglia, una volta dominio indiscusso di Novell, e sta cercando di entrare nel mercato di fascia alta una volta appannaggio esclusivo dei venditori di S.O. Unix quali Sun, Hewlett Packard e Silicon Graphics.

Per quanto mi riguarda ho ereditato un server Novell Netware 3.11 perfettamente funzionante allorché ho iniziato la mia carriera presso l'agenzia stampa dell'Università del Nebraska, questa macchina poggiava su un Pentium 90 sottoalimentato e su vecchi dischi che erano sul punto di collassare. Siccome volevo anche allargare i miei interessi ad altre aree mi sono subito reso conto che l'aggiornamento della rete sarebbe stato il primo vero progetto con cui misurarmi. Quando ho iniziato ad analizzare le varie possibilità che avevo a disposizione per rimpiazzare il server Novell Netware mi sono ritrovato immediatamente per le mani il Server Windows NT 4.0 allora appena uscito; le brochures aziendali, le riviste e la televisione, tutte insieme, non facevano altro che dirmi che questa era la scelta che avrebbe risolto tutti i miei problemi. Il sistema operativo sembrava essere in grado di mantenere la promessa di consentire un'installazione ed una gestione più agevoli rispetto a quelle del prodotto Netware che andava a rimpiazzare oltre a gestire in maniera agevole i 55 utenti della rete. A quattordici mesi di distanza, però, stiamo utilizzando un server Linux per la nostra rete.

Linux è una implementazione delle specifiche POSIX completamente aperta, con estensioni SYSV e BSD (il che significa che si presenta come Unix ma che non proviene dalla stessa radice di codice sorgente), disponibile sia sotto forma di codice binario che sorgente. Linus Torvalds <torvalds@transmeta.com> detiene insieme ad altri collaboratori il copyright del software che è ridistribuibile liberamente alle condizioni della Licenza Generale Pubblica (GPL) GNU. Una copia della licenza software è sempre compresa con i sorgenti di Linux ma si può averne una copia dal sito ftp://prep.ai.mit.edu/pub/gnu/COPYING.

Linux non è un software di pubblico dominio, né è shareware, è un software 'libero', comunemente detto freeware, e chiunque ne può regalare o rivendere copie, anche se deve includere nel pacchetto il codice sorgente o renderlo disponibile alla stessa maniera di ogni eseguibile che si va a dare o vendere. Se si distribuisce una qualche modifica si è legalmente vincolati a distribuire i sorgenti di quella modificazione. Per ulteriori informazioni si veda la Licenza Generale Pubblica GNU.

Linux pur essendo arrivato alla versione 2.0 è ancora "libero" e continuerà ad esserlo. Proprio a causa della natura della licenza GPL alla quale Linux è assoggettato, ogni tentativo di trasformarlo in qualcosa di non più libero sarebbe illegale. Si badi che l'appellativo 'libero' si riferisce all'accesso al codice sorgente e non ad un eventuale prezzo da pagare; è infatti perfettamente legale dare un costo alla redistribuzione di Linux, così come è legale distribuire il codice sorgente. Quanto riportato è, però, soltanto una breve sintesi, per approfondimenti e informazioni più dettagliate occorre leggersi la GPL.

Linux gira alla perfezione su macchine 386/486/Pentium con bus ISA, EISA, PCI e VLB. Il bus MCA (di cui è proprietaria IBM) non è ben supportato nella versione 2.0.x del S. O. e nelle sue versioni precedenti, anche se nell'ultima versione in corso di sviluppo, la 2.1.x, è stato aggiunto il supporto per questo tipo di bus. Chi fosse interessato può dare un'occhiata al sito http://glycerine.itsmm.uni.edu/mca

Esistono anche versioni di Linux per piattaforme multiprocessore Motorola 680x0 (attualmente funzionanti su alcune macchine Amiga, Atari e VME) che funzionano egregiamente. In questi casi è richiesta la presenza di un 68020 con MMU, o di un 68030, un 68040 o, infine, di un 68060, con accanto una FPU. Altrettanto egregiamente funzionano anche la gestione di rete e l'ambiente X. Si vedano le news: comp.os.linux.m68k

Linux funziona bene anche sulle CPU Alpha DEC, e supporta attualmente anche molte altre piattaforme tra le quali si segnalano "Jensen", "NoName", "Cabriolet" e "Universal Desktop Box" (meglio nota come Multia). Per ulteriori informazioni si veda il sito http://www.azstarnet.com/~axplinux/FAQ.html

Linux funziona poi altrettanto bene su macchine SPARC Sun e addirittura la maggioranza delle macchine sun4c e sun4m attualmente supporta Linux senza problemi, nel contempo si sta lavorando attivamente allo sviluppo del supporto per sun4 e sun4u. Allo stato dei fatti Linux Red Hat è il solo (almeno finora) pacchetto Linux in distribuzione che sia disponibile per SPARC; si veda il sito http://www.redhat.com/support/docs/rhl-sparc/

Linux sta per essere reso disponibile anche nell'ambiente ad architettura PowerPC, inclusi PowerMac (Nubus e PCI), Motorola, IBM e macchine Be. Si vedano i siti http://www.cs.nmt.edu/~linuxppc/ e http://www.linuxppc.org/

L'implementazione di Linux su altre macchine, comprese MIPS e ARM, è in dirittura d'arrivo e, a seconda del tipo di macchina, più o meno vicino all'essere definito. Non c'è da trattenere il respiro, anche se va notato che qualora vi fosse qualcuno particolarmente interessato ed in grado di dare un contributo si troverebbero sicuramente una serie di sviluppatori che sarebbero ben lieti di collaborare con lui.

Ormai nessuno ritiene più che Linux sia in versione test, almeno da quando è stata rilasciata la versione 1.0, il 14 marzo del 1994. Sicuramente ci sono ancora degli errori nel sistema e nuovi ne verranno e saranno individuati e corretti col passare del tempo. Poiché Linux è conforme al "modello di sviluppo aperto" ogni nuova versione del S. O. viene rilasciata al pubblico, si tratti o no di "produzione di qualità". In ogni caso, per aiutare gli utenti a vedere se la loro versione è stabile o meno è stato messo a punto il seguente criterio: le versioni 1.x.y, per le quali x è un numero pari vengono considerate stabili, e al crescere di y corrisponde la risoluzione di un numero crescente di problemi connessi con quella versione del sistema. In tal modo, ad esempio, nel passaggio dalla versione 1.2.2 alla 1.2.3 non sono stati introdotti altro che accorgimenti per la risoluzione di problemi e nessuna nuova caratteristica specifica. Le versioni 1.x.y, con x dispari, sono versioni di prova dedicate esclusivamente agli sviluppatori, all'interno delle quali sono state implementate nuove caratteristiche che verranno man mano incluse nella versione definitiva. Di tanto in tanto, allorché il kernel in via di sviluppo si stabilizza, viene categorizzato un nuovo nucleo "stabile", e la fase di sviluppo si sposta su una nuova versione del kernel in via di definizione.

L'attuale versione stabile è la 2.0.31 (che continuerà ad essere modificata man mano che nuovi driver verranno ad aggiungersi o verranno fissati degli errori), mentre è stato avviato lo sviluppo di kernel sperimentali individuati dalla sigla 2.1.x. Se la versione 2.0.x può sembrare troppo giovane si può sempre ripiegare sulla versione 1.2.13 finché non ci si sente più sicuri. Ad ogni modo l'ultima versione della 2.0 si è dimostrata abbastanza stabile. Va notato che per effettuare l'aggiornamento dalla versione 1.2 alla 2.0 occorre aggiornare tutta una serie di programmi indispensabili ad essa collegati, per cui può essere utile effettuare l'aggiornamento ricorrendo all'ultima versione della distribuzione Linux di cui si dispone. I sorgenti del nucleo Linux contengono anche un file di Documentazione/Variazioni, che spiega tutti i cambiamenti sopravvenuti e tante altre cose.

La maggior parte delle versioni di Linux, di prova o no che siano, sono tutte pittosto stabili e le si può continuare ad utilizzare senza alcun timore se fanno con onore il proprio lavoro e se non si desidera essere sempre sulla cresta dell'onda. Al riguardo un caso emblematico è il seguente: un sito ha utilizzato la versione 0.97p1 (databile all'estate del 1992) per oltre 136 giorni senza che si verificassero errori o cadute del sistema (e probabilmente avrebbe continuato a funzionare senza problemi se un operatore sprovveduto non avesse scambiato un trasformatore di potenza con uno stabilizzatore ...). Altri ancora hanno inviato messaggi di aggiornamento con un anno di ritardo. Un sito, ad esempio, aveva un computer su cui girava linux 0.99p15s dopo oltre 600 giorni dall'ultimo rapporto.

Una cosa che occorre sempre tener presente è che Linux viene sviluppato utilizzando un modello aperto e distribuito, in luogo di un modello chiuso e centralizzato come accade per la maggior parte del software. Ciò significa che la versione attualmente in fase di sviluppo è sempre pubblica (con al più una o due settimane di ritardo) in modo tale che chiunque può utilizzarla. Ne consegue che quando viene rilasciata una versione con nuove funzionalità, quasi sempre contiene qualche errore, ma viene anche sottoposta ad una continua revisione per cui gli errori vengono trovati e corretti molto rapidamente, spesso in qualche ora, in quanto ci sono molte persone che lavorano contemporaneamente alle correzioni.

Per contro, nel modello chiuso e centralizzato c'è soltanto una persona o un gruppo di persone che lavora al progetto e che rilascia il software quando ritiene che tutto funzioni. Normalmente in questo caso si hanno lunghi tempi di attesa tra una versione e la successiva, c'è da aspettare un bel po' per vedere corretti gli errori e lo sviluppo del software procede molto lentamente. L'ultima versione di un tale tipo di software, quello accessibile al pubblico, è in generale di altissima qualità ma la velocità di sviluppo è spesso piuttosto bassa.

Alla data del 24 ottobre 1997 la versione considerata stabile del S. O. Linux è la 2.0.31, mentre l'ultima release della versione in via di sviluppo è la 2.1.59.

Questo articolo inizia con l'analisi delle tematiche che si sono dovute affrontare e con le motivazioni che hanno condotto a delle scelte ben precise nelle quali si è stati coinvolti. Nella prima parte non mi addentrerò molto negli aspetti tecnici anche se mi occuperò in dettaglio del come si sia implementata ogni parte del sistema, nella seconda parte riporterò alcuni esempi dei file di configurazione adottati.


Sezione 1
Analisi della situazione di partenza
La situazione trovata
Quando sono diventato responsabile del Dipartimento del Sistema Informativo dell'agenzia stampa dell'Università del Nebraska ho ereditato un vecchio e stanco server Novell Netware 3.1 destinato a gestire, anche se in maniera piuttosto affannosa, tutti i servizi di rete necessari a circa 50 utenti. Non si trattava certo di una grande rete e le esigenze da fronteggiare non andavano oltre l'ordinario, ma la macchina andava sostituita: Novell era arrivato alla versione 4.x, Windows NT era giunto alla 4.0 ed era appena uscito, mentre la macchina disponeva sostanzialmente di un Pentium 90 con dei dischi più rumorosi del grande stadio del Nebraska.

In definitiva era giunto il momento di cominciare a cercare qualcosa con cui rimpiazzare l'esistente e per farlo disponevo degli stessi elementi conoscitivi del mio predecessore oltre a qualcosa di nuovo. L'obiettivo principale era mantenere la compatibilità con il sistema di gestione ordini ed inventario denominato Cat Pajamas (i pigiami del gatto) originariamente sviluppato su minicomputer e mainframe della Data General mediante l'uso del loro linguaggio interprete proprietario. Il sistema era stato poi trasferito su PC server di rete (per lo più Novell Netware) da una società denominata Subject Wills, che si era occupata del trasferimento dell'interprete su PC. Questo sistema ha la caratteristica di avere un'interfaccia utente a caratteri, di memorizzare tutti i dati in file di testo indicizzati linearmente e di essere abbastanza veloce ed affidabile, almeno in ambiente Novell. Requisiti che si sono andati ad aggiungere ai precedenti erano: riuscire ad avere un accesso remoto per il nostro magazzino e, se possibile, mettere in rete anche cinque Mac di cui si disponeva, spendendo però il meno possibile.

Per quanto mi riguardava non ero molto interessato ad aggiornare la licenza Netware di cui già disponevamo, poiché all'epoca la Novell si era fatta coinvolgere nel gioco del CEO del mese, il che mi aveva fatto perdere molta della mia fiducia nella società. L'altra scelta logica era Microsoft Windows NT per cui ho deciso di chiamare la Cat e di chiedere loro se l'applicazione che avevamo avrebbe girato su NT; la risposta è stata che sebbene avessero poche installazioni sembrava che tutto filasse liscio, ma mi hanno anche detto che avrei avuto bisogno di una versione differente dell'interprete DBC, che loro avrebbero potuto procurarmi. Con queste premesse ho proceduto a copiarmi l'intero sistema e la base dati sul server NT e mi sono collegato dal mio PC Windows 95. Ovviamente ho dovuto riscrivermi il file di batch utilizzato da Cat per l'avviamento in quanto esso conteneva inizialmente comandi di rete Netware, ma alla fine sono riuscito a far partire una sessione di collegamento.

A questo punto ho pensato che fosse tutto a posto per cui ho provveduto ad ordinare il server da mettere al lavoro. Avevo individuato come server una macchina con due Pentium 150 come CPU, un controller SCSI 2940UW e 256 MB di RAM, in quanto mi era sembrato che questa scelta consentisse di avere quanto di meglio presente sul mercato per realizzare un server Cat, un file server ed un print server per 50 persone, soprattutto perché il server Netware faceva le stesse cose su un Pentium 90 con 64 MB di RAM. La macchina è arrivata dopo qualche settimana ed ho provveduto ad installarvi NT 4.0 e Cat. Al termine dell'installazione il dipartimento amministrativo ed il dipartimento servizio clienti hanno provato a mandare in esecuzione sul server alcuni rapporti molto estesi e che richiedevano un intenso lavoro di CPU e tutto è sembrato andare alla perfezione, si è deciso così di portare la macchina a regime. Nel contempo stavo installando Linux RedHat 4.1 su un Pentium 100 con 32 MB di RAM in quanto avevo utilizzato con molta soddisfazione Linux RedHat nella mia precedente occupazione in qualità di server Web e server audio/video StreamWork e volevo vedere se c'era la possibilità di ripetere l'esperienza anche se non ero ancora consapevole del come e del dove realizzarla.

Dopo aver trasferito Cat su NT la vita è diventata un incubo. Il sistema collassava due o tre volte al giorno senza alcun motivo apparente o senza che potessi darmene una spiegazione. Ho trascorso intere giornate al telefono con Microsoft e Cat ma nessuno è riuscito a fornirmi delle indicazioni utili a risolvere il problema. Microsoft mi ha dato da applicare, ad uno ad uno, tre Service Pack ed alcuni HotFix, che hanno sortito qualche effetto positivo ma non risolto il problema, visto che la macchina collassava almeno due volte la settimana mostrando l'infame "Schermata blue della morte". Dopo diverse settimane e circa $1500.00 di supporto telefonico da parte di Microsoft, il responsabile del supporto tecnico mi ha fatto sapere che avrei potuto trovare un pacchetto software sicuramente migliore del Cat Pajamas. Ma questa non poteva essere la soluzione che andavo cercando, visto che questo pacchetto viene utilizzato da una percentuale consistente di agenzie di stampa della nostra grandezza su tutto il territorio nazionale, sono stato pertanto costretto a rimettere in piedi il server Novell ed a rimetterlo in linea almeno fino a quando non fossi riuscito a trovare una soluzione migliore.

Nel contempo avevo aggiornato la macchina con il Linux RedHat alla versione 4.2, anche se ancora non impiegavo quella macchina per fare un gran che, per cui ho aggiunto due hard disk IDE da 1.6 GB, ho installato SAMBA ed ho copiato CAT su questa macchina con l'obiettivo di giocarci un po'. Sono stato in grado di collegarmi al sistema dalla mia macchina Windows 95 ed a lanciare Cat senza dover apportare alcuna modifica al file batch che avevo realizzato per NT. Ho ripetuto allora l'esperienza già fatta ed ho fatto collegare il direttore del Commerciale e quello del Servizio Clienti per far provare loro i rapporti già testati su NT e tutto è filato liscio. Vista l'esperienza già fatta, avevo però ancora dei dubbi, ed ho deciso di tenere in piedi questo sistema esclusivamente per me e per il dipartimento IS per fare qualche ulteriore test in momenti successivi.

Il server Netware era ancora in piedi e faceva il suo lavoro quando un giovedì notte alle 9:00 ho ricevuto una telefonata dal responsabile del servizio clienti, il quale aveva lanciato il programma di reindicizzazione per prepararsi alla chiusura di fine mese che doveva partire il venerdì, ma aveva avuto la sgradita sorpresa di vedere collassare il server. Ho lavorato a rimetterlo in piedi fino alle 12:30 della notte e finalmente sono riuscito a riavviarlo anche se l'allegria è durata poco visto che il sistema ha cessato di funzionare prima alle 6:30 del mattino del venerdì e poi nuovamente alle 7:00. Mi sono reso conto allora che la situazione era critica e che l'unica possibilità che mi rimaneva era sostituire subito il server con l'unica cosa che avevo per le mani: la macchina Linux. Dopo aver fatto copie di backup del sistema Cat dalla macchina NT, mediante l'unità a nastro, ho ripristinato il tutto sul server Linux ed ho modificato gli script di login per consentire a tutti gli utenti di collegarsi utilizzando i drive Cat. Nell'arco di un'ora il sistema era di nuovo operativo.

Al termine degli impegni antimeridiani, in generale, si è sempre effettuato un backup completo del software Cat prima di continuare con la normale chiusura ed il tutto ha richiesto normalmente, sul server Netware, per arrivare a completamento, almeno due ore. La macchina Linux è stata in grado di fare l'intero backup in 45 minuti, consentendoci di risparmiare più di un'ora sui nostri tempi di chiusura ordinaria. A questo incremento in velocità ha corrisposto un decremento nell'hardware utilizzato visto che il server Linux era dotato soltanto di 32 MB di RAM e di hard disk IDE, mentre il server Netware aveva 64 MB di RAM e drive SCSI. Il sensibile incremento in velocità è stato rilevato anche nel corso del normale lavoro quotidiano (più di qualcuno mi ha fatto notare che il sistema è sembrato andare più veloce ed essere più affidabile).

Recentemente abbiamo aggiornato la CPU con un Pentium da 200 MHz ed abbiamo portato la memoria a 64 MB nell'ambito di un piano di aggiornamento della rete con il quale abbiamo rimpiazzato con il nuovo server il file/printer server NT, che ancora collassa quasi due volte al mese senza alcun apparente motivo, perfino dopo un ulteriore spesa di $1.500 per supporto tecnico dalla Microsoft. Il nuovo computer con Linux RedHat è andato a rimpiazzare sia il server Netware 3.11 che il server Windows NT 4.0, richiedendo, contestualmente, un decremento di risorse hardware. Con i recenti annunci del team Samba relativamente al supporto della struttura dei domini NT e con la versione 5.0 della RedHat di dicembre 1997, mi aspetto di ottenere un server molto efficiente ed economico per tutti i nostri client Windows 95, Windows NT e Macintosh.


Sezione 2
Perché la scelta di Linux RedHat
Le caratteristiche di Linux
Linux è un sistema operativo ricchissimo di doti positive. Molte delle sue caratteristiche non si ritrovano nel suo concorrente commerciale Windows NT, forse in virtù del fatto che Unix è stato in costante crescita fin da quando è stato "inventato" nei lontani primi anni '70. Sebbene Linux sia venuto fuori soltanto nei primi anni '90 ha tratto notevole beneficio dalla ricchissima biblioteca di applicazioni e programmi di utilità Unix oltre che dalla sua conformità allo standard POSIX. L'unicità di Linux risiede nel fatto che il suo nucleo non utilizza neanche una riga del codice delle precedenti implementazioni di Unix, anche se può "alimentarsi" delle librerie delle distribuzioni BSD e System V. Ritengo che la forza di Linux sia nella rete Internet e nella miriade di utenti che sono contemporaneamente anche tecnici, responsabili dello sviluppo dei molti drive e del trasporto del software ad altre piattaforme hardware. La risoluzione di molti problemi nell'ambito della piattaforma Intel è avvenuta, per Linux, prima che gli stessi problemi fossero individuati in altri sistemi operativi "mainstream", soprattutto grazie al fatto che gli utenti sono anche gli sviluppatori.

L'affidabilità
Il sistema deve funzionare 365 giorni all'anno.
Il server Linux si è dimostrato affidabile alla stessa stregua di ogni altro sistema operativo abbia mai utilizzato come server, anzi forse anche più affidabile di tanti altri. Le mia passate esperienze comprendono la gestione di server Netware della Novell, Windows NT 3.51 e 4.0 ed Irix (Silicon Graphics). Devo dire che il server Novell ha fornito prestazioni regolari in ogni circostanza, anche se ho sempre ritenuto che fosse più complesso del necessario. Anche le macchine Silicon Graphics si sono dimostrate solide come rocce ma non penso che potesse accadere diversamente visto che un solo server può arrivare a costare più di $20,000.

Inizialmente il server Linux è stato avviato, nel gennaio del 1997, a mò di prova, al solo scopo di vedere se riusciva a reggere il ritmo di un server di produzione. All'epoca vi avevo installato una copia di Cat Pajamas, il server Apache, StreamWorks (server audio/video) e Samba. Mediante Samba ho potuto collegare il dipartimento del Sistema Informativo a questo server e sono riuscito a mandare in esecuzione Cat ed a provare il server audio/video. Una tipica giornata di prova del sistema ha compreso la reindicizzazione e la riformattazione di Cat mentre venivano gestiti più di 100 mega byte di file video e, contestualmente, la macchina operava come file server. Ebbene la macchina Linux è riuscita a fare tutto ciò utilizzando soltanto 32 MB di RAM ed una CPU Pentium 100.

Da gennaio 1997 a luglio 1997 abbiamo sperimentato soltanto tre cadute del server, due delle quali causate da mancanza di corrente nell'edificio e la terza dalla stupidità del settore amministrazione. Questa affidabilità è stata il fattore chiave che ci ha convinto ad utilizzare Linux come piattaforma per il server.

L'installazione di NT è stata semplice, come semplice si è rivelato il collegamento del sistema a tutte le stampanti, ma il server si è dimostrato inaffidabile. Si avevano cadute quotidiane anche dopo l'installazione dei pacchetti di servizio 1 e 2. Ho provveduto anche ad installare del software con le correzioni al pacchetto di servizio due al fine di correggere errori nella gestione dei servizi Macintosh ed ho avuto qualche beneficio; il sistema ha però continuato a collassare una o due volte al mese. Ho provato infine a mandare in esecuzione Cat al di fuori di questo sistema, ma la prova si è rivelata un fallimento totale in quanto non si riusciva ad avere più di cinque utenti collegati contemporaneamente all'interno di Cat mentre i rapporti giravano all'infinito.

Piattaforme diverse con cui misurarsi
Il nuovo server deve essere in grado di servire gli utenti Mac così come i clienti Windows.
Il server deve consentire ad utenti Windows e Macintosh di collegarsi. Tutti i principali sistemi operativi di rete lo consentono, Linux compreso. Per fornire servizi ad utenti Windows Linux utilizza un pacchetto denominato Samba: esso consta di software per server Unix o che utilizzano un sistema operativo simile a Unix e prevede sia disponibile il protocollo standard TCP/IP. Samba, così come si presenta ora, dipende dalla struttura dei file, dai permessi, dalle chiamate di sistema e dai servizi Unix e fornisce servizi di gestione file e stampanti a clienti che utilizzano il protocollo SMB (Server Message Block). Il protocollo SMB è un protocollo di rete "nativo" utilizzato da client MS-DOS (in un senso molto generale comprende anche i suoi derivati). Tra questi troviamo anche quelli di IBM, ICL, Microsoft e di un particolare prodotto Novell e, più in particolare, ritroviamo questi client con "Windows per WorkGroup", "Windows 95", "Windows NT", "OS/2 Warp" ed altri.

Alcuni dei "cugini" del server Samba comprendono i Pathworks DEC, i LAN Manager/X di Microsoft, i Lan Manager di OS/2, i Server Lan di IBM, i server Syntax ed i server Windows NT. Alcuni client come Windows 95/Workgroup o anche Warp Connect possono comportarsi poi come dei piccoli server con limitate capacità di gestione.

SMB sta diventando molto popolare principalmente a causa dei seguenti fattori:

 
      Per quanto riguarda Macintosh, Netatalk fornisce i servizi di connettività. Si tratta di un'implementazione Unix del pacchetto di protocolli AppleTalk, originariamente messo a punto per sistemi derivati da BSD. Esso comprende le funzioni di supporto al routing Appletalk, il servizio di sistemi con filesystem Unix ed AFS mediante AFP (AppleShare), il servizio di stampanti in Unix e l'accesso a stampanti AppleTalk mediante PAP. Incluso nel pacchetto è poi un insieme non rilevante di programmi di utilità dedicati alla stampa ed al debug.
 
Compatibilità con applicazioni preesistenti
Il server adottato deve essere compatibile con il software "The Cat's Pajamas"
Quando abbiamo cercato di passare a Windows NT ci siamo preoccupati di farci dare dai produttori del software Cat delle linee guida da utilizzare per la migrazione. Le istruzioni si sono rivelate molto semplici e l'intera migrazione ha richiesto pochissimo tempo, anche se le prestazioni si sono rivelate pessime. Si aveva esigenza di una macchina che potesse gestire la rete e contemporaneamente garantire l'integrità dei file di dati di Cat. Mi era stato detto che Unix fa un uso molto intenso della cache nella gestione dell'I/O dei file (molto più di quanto non facciano Windows NT e Netware della Novell), per cui ho pensato che Linux si sarebbe rivelato una piattaforma per il server Cat molto robusta, visto che quest'ultimo è un'applicazione che gestisce pesantemente l'I/O.

Le mie aspettative sono risultate verificate quando si è sostituito il server Novell con quello Linux. Cat è stato lanciato in maniera semplice e lineare e portato al normale livello di utilizzo quotidiano senza che si rivelassero cadute di prestazioni o particolari situazioni di stallo. Con il server Novell, invece, si sono sperimentati periodi nei quali il sistema sembrava avere dei veri e propri momenti di arresto, seguiti da un ritorno ai normali livelli di velocità dopo 5 o 10 minuti. Durante queste cadute il software Cat diveniva praticamente inutilizzabile ed in qualche caso gli utenti venivano brutalmente cacciati fuori dal software stesso.

Un altro campo chiave nei confronti del quale avevo l'esigenza della compatibilità era il web (World Wide Web) in quanto avevo bisogno di utilizzare degli script CGI che fossero già testati e funzionanti senza dover essere costretto a realizzarli tutti in prima persona. Avevo anche bisogno di poter avere facilmente aiuto (oltre che a basso costo) sul settaggio del server e sulle correzioni di eventuali errori, o sul come far fronte ad eventuali problemi nel caso in cui il server fosse caduto. Linux utilizza Apache che si è rivelato essere il server Web più utilizzato al mondo per il quale si può ottenere facilmente il supporto voluto mediante mail list, news group e BBS Internet.
(http://www.netcraft.com/survey/)

La velocità
Dopo aver installato il server NT molti utenti hanno lamentato la lentezza dell'accesso alla rete.
I miei utenti tendono a mettere sullo stesso piano, in termini di confronto, la velocità di accesso alla rete con la qualità della rete stessa. Si sono dimostrati molto soddisfatti della velocità di apertura e chiusura file sul server Netware Novell ed hanno manifestato non poco disappunto quando si è passati al server Windows NT per realizzare le medesime operazioni. Una cosa che ho misurato in maniera poco scientifica è stata la velocità del server Linux allorché si è utilizzata la macchina Windows NT 4.0 per salvare i file Cat prelevati dal server Linux. Questa operazione ha richiesto complessivamente 45 minuti, mentre la stessa operazione sul server Novell è durata esattamente un'ora di più. Attualmente effettuo un salvataggio di Cat creando un file tar g-zippato direttamente sulla macchina Linux e l'operazione mi richiede, nel complesso, un po' meno di 45 minuti. Di seguito riporto parte dell'output del comando df con il quale viene evidenziata l'occupazione del disco sul quale ho Cat; in pratica ciò dà un'idea dell'occupazione del sistema Cat ed una misura della quantità di informazioni che vengono salvate in circa 45 minuti.

Filesystem1024-blocksUsed AvailableCapacityMounted on
/dev/hdc1   2417493   1584580   707923 69%   /usr/local/samba-sys

L'economicità
Non potevo permettermi di restare invischiato in un'altra installazione costosa.
Durante i dodici mesi di attività del server NT 4.0 ho speso più di $3,000 in supporto tecnico da parte della Microsoft per porre rimedio a vari problemi, compresi i frequenti collassi del sistema ed i problemi connessi all'esecuzione di Cat. Nel caso delle cadute del server ho ottenuto costantemente il seguente suggerimento: "installi l'ultimo pacchetto di servizio o hot fix e ci richiami domani", mentre per Cat mi è stato detto: "si disfi del software Cat e trovi un software maggiormente compatibile con Windows che lo rimpiazzi". Avrei dovuto documentare quanto riportato anche per poter fornire i nominativi delle persone del supporto tecnico Microsoft, ma tant'è.. .

In effetti, però, il supporto tecnico non è stato il solo motivo di spesa con Windows NT. La tabella sottostante evidenzia, voce per voce, i costi delle varie applicazioni nelle due piattaforme.
 

Servizio Microsoft Costo Linux Costo
Sistema Operativo Server Windows NT 4.0 $2,950.00 Linux RedHat 5.0 (CD) $49.00
Server Web Server per Information su Internet
$0.00
Apache
$0.00
E-Mail Exchange 5.0 Enterprise
$6,400.00
Sendmail, UW IMAP, POP-3
$0.00
Server Telnet SLNet (licenza per 4 utenti)
$300.00
Licenza illimitata aperta compresa
$0.00
Server FTP Compresa con IIS
$0.00
Compresa
$0.00
Database Relazionale Server SQL 6.5
$10,650.00
SQL Just Logic
$219.00
Server Proxy Server proxy Microsoft
$995.00
Squid Object Cache
$0.00
Software di Backup Compreso
$0.00
BRU, compreso
$0.00
Costo Totale
$20,995.00
$268.00
Numero di utenti 100 100
Costo per posto di lavoro
$212.95
$2.68
 
I requisiti hardware minimi
Sicuramente non intendevo costruire il futuro Cray per servire 55 utenti.
Come per la maggior parte delle agenzie stampa universitarie il nostro budget operativo è relativamente modesto, soprattutto se lo si confronta con i budget di attività commerciali o di altri dipartimenti della stessa università. Tali restrizioni finanziarie non mi hanno permesso di provvedere all'acquisto della piattaforma hardware che avrei voluto per il server NT anche se il sistema acquistato non era comunque da considerare di basso livello o da buttare.

Il nostro server Windows NT 4.0:
S. O. Server Windows NT 4.0 (SP3)
CPU 2 x Pentium 150
RAM 256 mega byte
SCSI Adaptec 2940
- tutti i drive dei dati sono SCSI
- il drive di avvio è IDE
Ethernet compatibile NE2000
Il nostro server Linux RedHat 4.2:
S. O. Linux RedHat 4.2
CPU Un Pentium 200
RAM 64 mega byte
SCSI DPT SmartCache IV
- RAID Station 3 (RAID 5)
- il drive di avvio è IDE
Ethernet compatibile NE2000

Il RAID riportato a seguito del server Linux non è stato acquistato specificatamente per il server Linux stesso, quanto piuttosto per essere utilizzato con il server che avremmo messo in linea.

La facilità di amministrazione
Per me e per tutto lo staff.
 
Secondo la migliore tradizione delle leggende metropolitane, Unix è difficile da gestire e richiede conoscenze ben al di sopra della media. Se è vero, però, che molti dei pacchetti che vengono utilizzati per gestire il sistema sono a riga di comando, un numero sempre crescente degli stessi programmi si presenta con una veste grafica confrontabile con quella di Windows, anche per facilità di utilizzo. Ciò è particolarmente vero con la distribuzione RedHat, che comprende un pannello di controllo grafico che consente all'amministratore di modificare i parametri di sistema senza dover mettere mano ai molti file di testo all'interno dei quali si trovano le informazioni da modificare. I pannelli di controllo che utilizzo maggiormente sono quelli relativi alla predisposizione delle stampanti, del filesystem, degli utenti e dei pacchetti applicativi. Se si utilizza il pacchetto di gestione compreso in RedHat per installare nuove applicazioni le si ritrova listate nel gestore che consente di vedere graficamente quali applicazioni sono installate nel sistema e di rimuoverle qualora lo si desideri, in maniera molto simile a quanto accade con l'opzione di disinstallazione di MS Windows.

La facilità di aggiornamento
Non è mia abitudine rifare tutto daccapo ogni qual volta esce una nuova versione del software.
Linux RedHat fornisce un sistema di aggiornamento molto semplice all'interno del suo kit di installazione. Tale sistema è molto migliore di quello che si ritrova in Windows NT in quanto non si deve provvedere a disinstallare la versione precedente del software.

Sebbene non sia richiesta la disinstallazione della versione precedente di Windows NT prima di procedere all'installazione della versione attuale (4.0), viene fortemente raccomandata. Si può andare incontro allora ad un'installazione defatigante visto che, tra l'altro, si deve provvedere a ripristinare gli account di tutti gli utenti e a reinstallare tutto il software, anche quello automatico di sistema e tutti gli script.

Quando ho effettuato l'aggiornamento dalla RedHat 4.1 alla 4.2 l'installazione è andata liscia e senza alcun tipo di problema. Sebbene non si sia trattato del passaggio ad una versione particolare, ho avuto assicurazioni dalla RedHat che la versione 5.0, che avrebbe dovuto essere rilasciata di lì a poco, avrebbe offerto una transizione ancora più soft delle precedenti.

Dal manuale di Linux RedHat:
 

1.5 Aggiornamento di una versione preesistente 

Il processo di installazione per Linux Red Hat 4.2 prevede la possibilità di aggiornamento a partire da una versione preesistente di Linux RedHat (2.0, 2.1, 3.0.3, 4.0 e 4.1) che utilizzi comunque la tecnologia RPM. L'aggiornamento del sistema installa il modulo di kernel 2.0.x così come i moduli aggiornati dei pacchetti installati nella macchina. Il processo di aggiornamento preserva i file di configurazione esistenti mediante l'utilizzo di un'estensione .rpmsave (ad es. sendmail.cf.rpmsave) e scrive in un file di log, i.e. /tmp/upgradelog, il tipo di azioni che va ad intraprendere. All'evolvere del software i formati dei file di configurazione possono modificarsi ed in tal modo si possono confrontare con attenzione i file di configurazione originari con i nuovi file prima di apportare i dovuti cambiamenti.

Per aggiornare un sistema Linux RedHat si deve utilizzare un dischetto di boot (e possibilmente un dischetto supplementare), come se si stesse effettuando un'installazione completa. Dopo aver selezionato il mezzo da cui procedere all'installazione (ed aver fornito eventuali informazioni di rete se richieste), la procedura d'installazione chiede se si deve procedere ad un'installazione o ad un aggiornamento (UPGRADE); si seleziona, a questo punto, Upgrade. L'attuale procedura di aggiornamento equivale da un punto di vista funzionale all'esecuzione dello script di aggiornamento in precedenti versioni di Linux Redhat.

Si noti che l'aggiornamento di alcuni pacchetti può "dipendere" da altri pacchetti che possono non essere stati installati sul sistema. La procedura di aggiornamento si fa carico di queste "dipendenze funzionali" anche se può "decidere" di dover installare pacchetti aggiuntivi per soddisfarle in pieno.

 
 
Il controllo remoto e l'amministrazione
Una delle caratteristiche più attraenti di Linux (e di Unix più in generale) è la possibilità di realizzare un vero e proprio controllo remoto del server. Poiché Linux viene fornito con al suo interno un server telnet, si può utilizzare virtualmente ogni computer, indipendentemente dal tipo di sistema operativo adoperato, per effettuare telnet sulla macchina nella quale si devono effettuare le operazioni di amministrazione di sistema. Per amministrare in remoto un server Windows NT si deve acquistare separatamente un'applicazione con la quale effettuare il controllo remoto: il più popolare programma destinato a questo scopo è PCAnywhere della Symantec. Questo tipo di approccio può diventare molto costoso in quanto si deve procedere ad acquistare una copia del software per il server host ed una copia per ogni computer dal quale si intende effettuare il controllo remoto del server. Quanti computer remoti devono poter controllare il server? Dipende da ogni installazione. Per quanto mi riguarda ho trovato molto utile, al fine di evitare di dover correre di qua e di là, poter controllare il server da ogni PC della rete oltre che da casa.

Telnet è un'applicazione esclusivamente di tipo testo, il che può essere un handicap per molti, ma, fortunatamente per tutti, Linux supporta X Windows il quale può essere utilizzato localmente sulla console del server, come con Windows NT, ma può essere lanciato anche in remoto da ogni computer che possa eseguire un client X. Questi terminali remoti possono essere lanciati da altri computer sui quali funziona Linux, o ogni altro clone di Unix e molti client X possono essere facilmente reperiti o acquistati per computer Windows, Windows NT e Macintosh. Ovviamente tali terminali X richiedono molta banda per cui io personalmente preferisco di gran lunga effettuare un semplice telnet sul server.

Altra caratteristica interessante è la possibilità di visualizzare i risultati di svariate applicazioni di sistema in una pagina web. Ad esempio una delle cose che il nostro responsabile del servizio clienti vuole conoscere istante per istante è l'utente che ha aperto e bloccato dei file (e quali sono), mentre è all'interno di una sessione Cat. Al riguardo ho scritto un semplice programma Perl per mandare in esecuzione il programma smbstatus e visualizzare la risposta come pagina web.

Ecco un esempio di pagina web del tipo descritto:

 
Schermata degli utenti del: Fri Dec 5   

11:41:18 CST 1997   

Questa pagina mostra gli utenti attualmente collegati al server UNPLINUX ed i file che all'interno del server sono bloccati.  

Right-click this page and select REFRESH or RELOAD to force an update  

Samba version 1.9.17p1  
Service uid gid pid machine  
----------------------------------------------  
cdrom root root 11697 enterprise (129.93.31.35) Thu Dec 4 16:35:23 1997  
quinn root root 11697 enterprise (129.93.31.35) Thu Dec 4 16:35:23 1997  
M-DATA cbrumm cbrumm 11435 ds9 (129.93.31.14) Thu Dec 4 16:08:16 1997  
programs root root 11697 enterprise (129.93.31.35) Thu Dec 4 16:35:23 1997  
L-NE cbrumm cbrumm 11435 ds9 (129.93.31.14) Thu Dec 4 16:08:29 1997  
N-DBC cbrumm cbrumm 11435 ds9 (129.93.31.14) Thu Dec 4 16:08:29 1997  
O-WORK cbrumm cbrumm 11435 ds9 (129.93.31.14) Thu Dec 4 16:08:29 1997  
P-HIST cbrumm cbrumm 11435 ds9 (129.93.31.14) Thu Dec 4 16:08:29 1997  

<snip>  

Locked files:  
Pid DenyMode R/W Name  
------------------------------  
19818 DENY_NONE RDWR fileauth.txt Fri Dec 5 11:41:14 1997  
21212 DENY_NONE RDWR fileauth.txt Fri Dec 5 11:40:28 1997  
20590 DENY_NONE RDWR fileauth.txt Fri Dec 5 11:38:56 1997  
21384 DENY_NONE RDWR fileauth.txt Fri Dec 5 11:06:15 1997  

<snip>  

19818 DENY_NONE RDWR filebac2.isi Fri Dec 5 11:02:36 1997  
20590 DENY_NONE RDWR filebac2.isi Fri Dec 5 10:14:44 1997  
19818 DENY_NONE RDWR fileauth.isi Fri Dec 5 11:41:14 1997  
21212 DENY_NONE RDWR fileauth.isi Fri Dec 5 11:40:28 1997  

Share mode memory usage (bytes):  
92584(90%) free + 7728(7%) used + 2088(2%) overhead = 102400(100%) total 

 
 

Ed ecco lo script che ha generato la pagina precedente:

 
#!/usr/bin/perl 
# ****************************************************** 
# * * 
# * Author: Quinn P. Coldiron * 
# * Date: 12-1-97 * 
# * Program: This program shows current users of the * 
# * Samba server. * 
# * * 
# ****************************************************** 
# Use cgi-lib CGI library for PERL. 

require "/home/httpd/cgi-bin/cgi-lib.pl"; 
$date = `date`; 
$users = `./smbstatus`; 
#Get the data from the form. 

&ReadParse; 
print &PrintHeader; 
print "<HTML>\n"; 
print "<HEAD>\n"; 
print "<TITLE>Logged In Samba Users</TITLE>\n"; 
print "</HEAD>\n"; 
print "<BODY BGCOLOR= #D4D4D4>\n"; 
print "<H1>Snapshot of users for: $date</H1>\n"; 
print "This page shows currently logged on users and locked files for the UNPLINUX server.<br>\n"; 
print "Right-click this page and select REFRESH or RELOAD to force an update<br>\n"; 
print "<PRE>$users</PRE>\n"; 
print "</BODY>\n"; 
print "</HTML>\n"; 

 

Windows NT dispone di un programma grafico mediante il quale mostrare le prestazioni del sistema, anche se si raccomanda di non mandarlo in esecuzione sul server da monitorare in quanto questo programma assorbe una porzione rilevante delle risorse della macchina falsando la rappresentazione dei dati. Linux, per converso, dispone di un pacchetto di monitoraggio del sistema denominato TOP che ha un'interfaccia a caratteri e può essere mandato in esecuzione sul server. Essendo un'applicazione a caratteri la si può mandare in esecuzione da ogni dove mediante una sessione telnet ottenendone una rappresentazione accurata della modalità di funzionamento del server.

Di seguito è riportato un esempio di output di TOP:
 
11:55am up 1 day, 15:02, 3 users, load average: 0.08, 0.04, 0.00 
83 processes: 82 sleeping, 1 running, 0 zombie, 0 stopped 
CPU states: 2.7% user, 4.2% system, 5.9% nice, 93.7% idle 
Mem: 63204K av, 62336K used, 868K free, 38384K shrd, 5536K buff 
Swap: 114908K av, 368K used, 114540K free 29496K cached 

PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 
22390 root 10 0 540 540 400 R 0 2.8 0.8 0:00 top 
22388 cats 3 0 848 848 516 S 0 1.5 1.3 0:00 login 
22391 cats 10 0 660 660 524 S 0 0.7 1.0 0:00 bash 
6058 root 1 0 3568 3568 1396 S 0 0.5 5.6 1:25 tkdesksh 
22283 root 0 0 552 552 424 S 0 0.3 0.8 0:00 in.telnetd 
22387 root 1 0 552 552 424 S 0 0.3 0.8 0:00 in.telnetd 
21212 quinn 0 0 1084 1084 660 S 0 0.1 1.7 0:02 smbd 
20921 root 1 0 588 536 356 S 0 0.1 0.8 0:08 SWserver 
1 root 0 0 312 312 244 S 0 0.0 0.4 0:02 init 
2 root 0 0 0 0 0 SW 0 0.0 0.0 0:01 kflushd 
3 root -12 -12 0 0 0 SW< 0 0.0 0.0 0:00 kswapd 
19509 root 0 0 1092 1092 652 S 0 0.0 1.7 0:18 smbd 
331 root 0 0 812 812 480 S 0 0.0 1.2 0:00 login 
21 root 0 0 280 280 216 S 0 0.0 0.4 0:00 kerneld 
240 root 0 0 336 316 280 S 0 0.0 0.4 0:00 gpm 
128 root 0 0 368 360 276 S 0 0.0 0.5 0:00 syslogd 
137 root 0 0 496 488 268 S 0 0.0 0.7 0:00 klogd 

 
 


Sezione 3
Più in dettaglio
Predisposizione e avviamento del server
L'installazione di Linux
Oggi come oggi la procedura di installazione di un sistema operativo viene spesso utilizzata per valutare la bontà del sistema operativo stesso. Si tratta di una sorta di imprinting, un po' come avviene quando si conoscono persone nuove e la prima impressione ne condiziona in maniera indelebile ogni rapporto futuro. Personalmente ho trovato l'installazione del server Linux RedHat dello stesso livello di difficoltà di quella del server Windows NT se non più facile. La predisposizione del server prevede la preparazione di due dischetti mediante i quali dare al sistema tutte le informazioni che servono per arrivare a riconoscere il mezzo (CDROM, sito FTP, altri server, ecc.) sul quale sono dislocati i file di installazione. Windows NT necessita per funzionalità analoghe di tre dischetti anche se poi è in grado di supportare la sola installazione da CDROM. Ho addirittura sperimentato che l'installazione di Linux RedHat su un laptop può essere più semplice, in quanto il sistema è in grado di rilevare lo slot PCMCIA durante la fase di installazione, cosa che Windows NT non è in grado di fare. In ogni caso è importante conoscere il tipo di hardware che è installato sulla propria macchina, compreso: L'installazione o l'aggiornamento di Linux RedHat/Intel può avvenire mediante uno dei metodi riportati di seguito. A seconda del metodo utilizzato si può aver bisogno di uno o due dischetti da 3.5" alta densità (1.44 MB) formattati.

L'Installazione effettuata da CD-ROM o via NFS richiede un solo dischetto di boot, mentre se viene effettuata da hard disk, via FTP, da un volume SMB, o da un'unità PCMCIA (compresi CD-ROM che utilizzino PCMCIA) richiede due dischetti: uno di boot ed un dischetto supplementare. La sezione 2.3.1 seguente spiega come creare il dischetto di boot e quello supplementare.

CD-ROM

Se si dispone di un CD Linux RedHat e di un dischetto di boot ci si deve garantire che il drive CD-ROM sia tra quelli supportati e che ci sia un drive per floppy da 3.5" o un'area su disco fisso nella quale risieda un sistema MS-DOS operativo, al fine di poter mandare in esecuzione il programma di installazione. Se nel kit con il CD non è presente un dischetto di boot allora si deve disporre dell'accesso ad un computer sul quale siano presenti Linux o MS-DOS per poter creare il dischetto di boot da CD.

NFS

Se si vuole effettuare l'installazione utilizzando una rete occorre montare il CD-ROM Linux RedHat su una macchina che supporti i file system ISO-9660 con le estensioni Rock Ridge. La macchina deve fornire, ovviamente, anche il servizio NFS e consentire l'esportazione del filesystem presente sul CD-ROM via NFS. Ci si deve anche assicurare che sia configurato ed in funzione il servizio DNS, oppure si deve conoscere l'indirizzo IP del server NFS ed il percorso del CD-ROM da esportare.

FTP

Nel caso di un'installazione effettuata via FTP occorre disporre di due dischetti uno di boot ed uno supplementare. Si deve avere anche un name server configurato e funzionante ovvero l'indirizzo IP del server FTP che si vuole utilizzare. Si deve disporre anche del percorso dell'area radice del sito FTP Linux RedHat.

Dischi condivisi SMB

Se si vuole effettuare l'installazione a partire da un volume condiviso SMB si deve montare il CD-ROM Linux RedHat su una macchina Windows NT o Windows 95 che supporti i volumi condivisi. Si deve disporre anche del servizio di DNS attivo e funzionante ovvero conoscere l'indirizzo IP del server; si devono conoscere anche il nome del volume condiviso contenente il CD-ROM Linux RedHat e l'account e la password da utilizzare per accedere al volume.

Hard Disk

Per effettuare l'installazione di Linux Red Hat da un hard disk si devono utilizzare gli stessi dischetti di boot e supplementare da utilizzarsi nel caso dell'installazione via FTP. Si deve innanzitutto creare un'area RedHat al livello più alto (immediatamente al di sotto dell'area radice) ed ogni cosa che si vuole installare deve essere messa in quell'area. Va prima copiata la sottoarea di base quindi vanno copiati, in un'altra area denominata RPMS, tutti i pacchetti che si vogliono installare. Allo scopo si può utilizzare lo spazio esistente o in una partizione DOS o in una partizione Linux che non sia richiesta dalla procedura d'installazione (ad esempio una partizione che debba essere utilizzata per la memorizzazione dei dati una volta installato il sistema).

Se si opta per un filesystem DOS non si potranno utilizzare completamente, per i pacchetti RPM, i nomi dei file secondo lo standard Linux. Il processo di installazione, di per sé, non si preoccupa del come si presentano dei nomi dei file per cui può essere una buona idea tenere traccia di tali nomi in modo da sapere che cosa si è installato.

PCMCIA

Se il CD-ROM, la scheda ethernet, o l'hard disk sono connessi ad un adattatore PCMCIA l'installazione può essere effettuata mediante il supporto PCMCIA. Ci si deve assicurare in tal caso che siano supportati il controller PCMCIA, l'adattatore PCMCIA SCSI o la scheda ethernet. Anche in questo caso l'installazione richiede l'uso di un dischetto supplementare.

Si veda l'appendice A per la guida all'installazione RedHat ufficiale.

L'installazione e l'avvio di Samba
L'installazione del pacchetto Samba RPM è la maniera più semplice di procedere all'installazione visto che l'unica cosa che si deve fare è scaricare il file e battere rpm -I nomefile. La predisposizione del programma è abbastanza facile in quanto si deve soltanto editare un file di testo per far conoscere al programma stesso quali aree devono essere condivise tra i client Windows. Il nome del file di testo è smb.conf ed è dislocato nell'area /etc (sempre che si sia proceduto all'installazione utilizzando RPM). Se si è scaricato l'archivio .tar e si è effettuata l'installazione standard di Samba, molto probabilmente il file smb.conf si viene a trovare in /usr/local/samba/lib/.

Il vantaggio dell'installazione di Samba mediante l'utilizzo di RPM risiede nella sua facilità di realizzazione, uno svantaggio è che le versioni di cui si viene a disporre non sono le più aggiornate, anche se sono normalmente più stabili ed affidabili. Per quanto mi riguarda preferisco andare direttamente alle pagine web di Samba e scaricarmi la versione più recente che non sia di prova.

La figura sulla sinistra mostra la finestra dei dintorni di rete (Network Neighborhood) sulla macchina NT ed illustra le aree alle quali ho accesso sul mio server Linux.

Se si effettua l'installazione di Samba con il pacchetto RPM originale il programma viene lanciato automaticamente all'avvio del sistema. Siccome io non ho utilizzato RPM ho dovuto aggiungere manualmente una riga al file rc.local per farlo partire all'avvio della macchina. La mia scelta di procedere all'installazione partendo da quanto disponibile sul sito ufficiale Samba discende dal desiderio di poter disporre sempre di una versione aggiornata del software. Per far partire il software manualmente ho utilizzato i seguenti comandi:

/usr/local/samba/bin/smbd -D

/usr/local/samba/bin/nmbd -D

È stato ampiamente riconosciuto che Samba si comporta pressoché allo stesso modo di un server NT, comprendendo nel tutto anche il fatto che il server Linux va trasformato in un Controllore di Dominio Primario (Primary Domain Controller -> PDC) e che vengono aggiunte al sistema molte ulteriori caratteristiche. Di seguito riporto l'elenco dei passi che ho dovuto fare per trasformare il mio server Linux in un PDC della rete.

1. Far partire il server.
       a. Creare il file smb.conf.
       b. Creare l'area netlogon. (Ho messo la mia in /home).
       c. Far ripartire Samba.

2. Far partire i client Windows 95. (Quanto riportato è un esempio tipo)
Non riavviare finché non si raggiunge il passo 3!
       a. Pannello di Controllo
               1. Si clicchi su Password, quindi su Profile e si scelgano le opzioni seguenti:
                       a. Gli Utenti possono personalizzare i loro dati.
                       b. Includere desktop item.
                       c. Includere menu di avvio.
               2. Nel Pannello di Controllo si selezioni Rete.
                       a. Alla voce Identificazione, si dia il proprio nome di GRUPPO DI LAVORO.
                       b. Controllo di accesso = USER-LEVEL.
                       c. Si ottenga la lista dal PROPRIO NOME DI SERVER.
                       d. In Configurazione del Client
                               1. Si selezioni CLIENTE DI RETI MICROSOFT.
                               2. Per le proprietà del client.
                                       a. Log in un dominio Windows NT.
                                       b. Si dia il proprio nome di GRUPPO DI LAVORO.
                                       c. Si selezioni LOGON E RESTORE CONNESSIONI.
                       e. Si predisponga il logon su rete primaria come CLIENTE DI RETI MICROSOFT.
       b. Si predisponga il profilo d'utente.
               1. Si installi la Policy Editor dal CD Windows 95.
               2. Si crei un nuovo profilo denominato config.pol e si salvi nell'area condivisa NETLOGON sul server Linux. Ci si assicuri di aver creato tutti gli utenti sul server! Questo passo deve essere
                   effettuato una sola volta e non per ogni client.
               3. Mediante la Policy Editor, si selezioni Open registry dal menu dei File e si scelga l'opzione che si desidera.
               4. Si salvi il tutto come config.pol e lo si copi nell'area condivisa sul server Linux. Si predispongano i permessi sul valore 755.

3. Si riavvii il/i computer(s) Windows 95 e ci si colleghi.

4. Possibili problemi.
       1. Sembra che l'OSR2 di Windows 95 invii le password in caratteri maiuscoli, si provi pertanto a modificare le password sul server Linux predisponendole in maiuscolo.
       2. Personalmente ho avuto dei problemi nel far sì che il server Linux venisse visto come server WINS. Per risolvere questo problema si possono seguire due strade:
               a. Se si dispone di un altro server NT lo si fa diventare server WINS e si fanno quindi puntare tutti i client a lui.
               b. Si disabiliti WINS su ogni client e si editi il file c:\windows\Lmhosts.sam aggiungendo il server e le workstation a questo file.
               Si salvi quindi il file come Lmhosts, NON Lmhosts.sam.
               Questo file può essere aggiunto da un server, anche se
                   non ho mai provato a farlo mediante Linux/Samba. Le varie righe dovrebbero somigliare alla seguente:
                   xxx.xxx.xxx.xxx nomecomputer
               c. Si disabiliti WINS. Attualmente tutti i nostri client Win95 sono in esecuzione con WINS disabilitato, ma è in funzione un server DNS.

Il file di configurazione di Samba (smb.conf) realizzato per la mia rete si presenta come segue:

 
; ******************************************************************* 
; * 
; * Samba config file for UNPLINUX 
; * Quinn P. Coldiron 
; * 
; ******************************************************************* 
[global] 
workgroup = UNP 
comment = Unplinux Server 
volume = RedHat5 
lock directory = /var/lock/samba 
locking = yes 
strict locking = no 
share modes = yes 
security = user 
os level = 65 
domain master = yes 
local master = yes 
prefered master = yes 
domain logons = yes 
wins support = yes 
;logon script = %m.bat ; per workstation (machine) 
;logon script = logon.bat 
logon script = %U.bat 
preserve case = yes 
short case preserve = yes 
case sensitive = no 
; printing = BSD or SYSV or AIX, etc.. 
printing = bsd 
printcap name = /etc/printcap 
load printers = yes 
print command = /usr/bin/lpr -r -P %p %s 
[netlogon] 
comment = Samba Network Logon Service 
path = /home/netlogon 
case sensitive = no 
guest ok = yes 
locking = no 
read only = yes 
browseable = yes ; say NO if you want to hide the NETLOGON share 
;admin users = @wheel 
create mode = 0755 

; ############################################################################### 
; # # 
; # Printers # 
; # # 
; ############################################################################### 
; I couldn't get the generic printers section to work, so I commented it out 
; and explicitly declared the printers. 
;[printers] 
; comment = All Printers 
; path = /var/spool/samba-print 
; browseable = yes 
; printable = yes 
; Set public = yes to allow user 'guest account' to print 
; public = no 
; writable = no 
; create mode = 0700 

[Technology] 
comment = Technology Printer 
path = /var/spool/samba-print 
print = Technology 
browseable = yes 
printable = yes 
public = yes 
writeable = yes 
create mode = 0777 

[Marketing2] 
comment = Technology Printer 
path = /var/spool/samba-print 
print = Marketing2 
browseable = yes 
printable = yes 
public = yes 
writeable = yes 
create mode = 0777 

[Marketing1] 
comment = Technology Printer 
path = /var/spool/samba-print 
print = Marketing1 
browseable = yes 
printable = yes 
public = yes 
writeable = yes 
create mode = 0777 

[CustServ] 
comment = Technology Printer 
path = /var/spool/samba-print 
print = CustServ 
browseable = yes 
printable = yes 
public = yes 
writeable = yes 
create mode = 0777 

[CanonColor] 
comment = Color Laser Printer 
path = /var/spool/samba-print 
print = CanonColor 
browseable = yes 
printable = yes 
public = yes 
writeable = yes 
create mode = 0777 

; ############################################################################### 
; # # 
; # Shared Volumes # 
; # # 
; ############################################################################### 

[homes] 
comment = Home Directories 
browseable = no 
writable = yes 
read only = no 
preserve case = yes 
short preserve case = yes 
;create mode = 0777 

[userdata] 
comment = All userdata that you are allowed to see. 
path = /home 
writeable = yes 
;Full control for your stuff, full in you group, nothing for other 
;people's stuff. 
create mode = 0770 

[sys] 
comment = System drive. Various Press utilities. 
path = /usr/local/samba-sys/ 
writeable = yes 
create mode = 0777 

[programs] 
comment = Program drive. Installation sets and programs. 
path = /usr/local/samba-programs 
writeable = yes 
create mode = 0777 

[ulrich] 
comment = Ulrich's PLUS. 
path = /usr/local/samba-programs/ulrich 
create mode = 555 

[cdrom] 
comment = Internal IDE cdrom. For temporary usage. 
path = /mnt/cdrom 

[dictionary] 
comment = Random House Dictionary. 
path = /mnt/scd1 

[bip] 
comment = Bowker Books In Print CDROM 
path = /mnt/scd0 

[msoffice] 
comment = Microsoft Office Bookshelf Reference. 
path = /mnt/scd3 

[encarta] 
comment = Microsoft Encarta 
path = /mnt/scd2 

[press] 
comment = Press share. Marketing maps this to U: 
path = /home/press 
writeable = yes 
create mode = 0777 

[CATS-VOL] 
comment = Entire Cats volume for backup 
path = /usr/local/samba-cats/ 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[L-NE] 
comment = Cat's root. Map as L. 
path = /usr/local/samba-cats/ne 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[M-DATA] 
comment = Cat's data drive. Map as M. 
path = /usr/local/samba-cats/ne/data 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[N-DBC] 
comment = Cat's program drive. Map as N. 
path = /usr/local/samba-cats/ne/dbc 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[O-WORK] 
comment = Cat's work drive. Map as O. 
path = /usr/local/samba-cats/ne/work 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[P-HIST] 
comment = Cat's history drive. Map as P. 
path = /usr/local/samba-cats/ne/hist 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 
 

Il file batch che utilizzo attualmente: logon.bat, è riportato di seguito
 
REM ******************************************************* 
REM * * 
REM * University of Nebraska Press network logon script. * 
REM * * 
REM * Last modified : 10-16-97 * 
REM * By: Quinn * 
REM * * 
REM * The drive letter scheme is leftover from the past * 
REM * network administrator and the Novell Netware 3.1 * 
REM * server he had. * 
REM ******************************************************* 
REM User's home drives 
net use e: \\unplinux\homes 
REM General network drives 
net use f: \\intrepid\sys 
net use g: \\intrepid\userdata 
net use h: \\intrepid\dictionary 
net use i: \\intrepid\bip 
net use j: \\intrepid\programs 
net use s: \\unplinux\ulrich 
REM CATS drives 
net use l: \\unplinux\l-ne 
net use m: \\unplinux\m-data 
net use n: \\unplinux\n-dbc 
net use o: \\unplinux\o-work 
net use p: \\unplinux\p-hist 
REM Temp entry for Robotronics 
REM The old system had robo on the T:\ drive but 
REM all new installations will run robo from the j:\ drive. 
net use t: \\unplinux\programs 
 
 

L'installazione e l'avvio di Netatalk
Netatalk presenta le stesse opzioni di installazione di Samba per cui si può scegliere tra gli archivi RPM e quelli .tar. In questo caso ho scelto RPM in quanto la versione ivi presente del pacchetto era identica a quella del file .tar ed ho voluto evitare di complicarmi la vita nella fase di installazione. A riguardo del processo d'installazione non ho molto da dire in quanto è stato semplicissimo e velocissimo. Dopo aver installato il pacchetto ho dovuto soltanto editare il file AppleVolumes.system e lanciare il demone del processo. Di seguito è riportato un esempio di file AppleVolumes.system che consente agli utenti Mac di accedere alla loro area di lavoro e ad alcuni volumi che potrebbero essergli utili.
 
 
# 
# This file is read before (after if -u is specified) the user's 
# AppleVolume file. Add extension mappings and volumes here. 
# 
/usr/local/samba-sys Sys (F drive) 
/home Userdata (G drive) 
/usr/local/samba-programs Programs (J drive) 
# default translation -- note that CR <-> LF translation is done on all 
# files of type TEXT. The first line turns off translation for files of 
# unknown type, the second turns this translation on. 
. BINA UNIX 
# . TEXT UNIX 
# sounds 
.mod STrk STrk 
.mid Midi ttxt 
.aiff AIFF SNdm 
.wav WAVE SNdm 
.au ULAW SNdm 
# video 
.moov MooV mMPG 
.mov MooV mMPG 
.mpg MPEG mMPG 
.mpeg MPEG mMPG 
# formatted text 
.html TEXT MOS! 
.rtf TEXT MSWD 
.doc WDBN MSWD 
# compressed archives 
.bin BINA MB2P 
.zip ZIP ZIP 
.tar TARF TAR! 
.gz Gzip Gzip 
.Z ZIVM LZIV 
.sea ???? SITx 
.cpt PACT CPCT 
.sit SIT! SIT! 
.hqx TEXT SITx 
# graphics 
.tiff TIFF JVWR 
.tif TIFF JVWR 
.bmp BMPp JVWR 
.pct PICT ttxt 
.pict PICT ttxt 
.jpeg JPEG JVWR 
.jpg JPEG JVWR 
.gif GIFf JVWR 

Un altro file che va editato è papd.conf, al suo interno sono contenute le informazioni relative alle stampanti.
 
# Attributes are: 
# 
# Name Type Default Description 
# pd str ".ppd" Pathname to ppd file. 
# pr str "lp" LPD printer name. 
# op str "operator" Operator name, for LPD spooling. 
# 
# Some examples: 
# 
# On many systems (notably not Solaris), no papd.conf is required, 
# since papd shares the same defaults as lpd. 
# 
# A simple example: 
# 
# terminator:\ 
# :pr=lp:op=wes:\ 
# :pd=/usr/share/lib/ppd/HPLJ_4M.PPD: 
# 
# Note also that papd.conf can list several printers. 
 
 

L'installazione del pacchetto "The Cat's Pajamas"
L'installazione di Cat sul server
L'installazione di Cat sul server Linux corrisponde quasi esattamente alla copia di tutti i file e delle aree dal vecchio server nel volume condiviso predisposto per Cat sul server Linux. Personalmente, per installare Cat, ho provveduto ad inserire nel server linux un altro disco, la scelta dell'IDE è dipesa soprattutto dal fatto che sul server non avevo un controller SCSI, né avevo un'ulteriore scheda di questo tipo per le mani, mentre avevo una fretta del diavolo di rimettere in linea Cat. Era nelle mie intenzioni, eventualmente, procedere alla sostituzione del disco IDE con uno SCSI, durante le feste natalizie, ma le prestazioni sono state più che soddisfacenti per cui ho deciso di lasciare tutto com'era. Ho montato questo disco come /usr/local/samba-cats ed ho dato a tutti il permesso di accedervi mediante il comando chmod 777 /usr/local/samba-cats -R. Mi rendo perfettamente conto di aver creato un problema di sicurezza non indifferente, ma dalla società produttrice del software mi è stato detto che i file devono essere riscrivibili da parte di tutti e leggibili da parte di Cat perché il sistema funzioni in maniera appropriata. Ho anche predisposto i file di configurazione di Samba con la maschera 0777 per essere sicuro che tutti i file scritti avrebbero potuto essere letti da tutti gli utenti.

La porzione del file smb.conf specifica per Cat è riportata appresso:
 
[CATS-VOL] 
comment = Entire Cats volume for backup 
path = /usr/local/samba-cats/ 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[L-NE] 
comment = Cat's root. Map as L. 
path = /usr/local/samba-cats/ne 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[M-DATA] 
comment = Cat's data drive. Map as M. 
path = /usr/local/samba-cats/ne/data 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[N-DBC] 
comment = Cat's program drive. Map as N. 
path = /usr/local/samba-cats/ne/dbc 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[O-WORK] 
comment = Cat's work drive. Map as O. 
path = /usr/local/samba-cats/ne/work 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

[P-HIST] 
comment = Cat's history drive. Map as P. 
path = /usr/local/samba-cats/ne/hist 
writeable = yes 
printable = no 
guest ok = yes 
public = yes 
create mask = 0777 

Mentre scrivo queste pagine stiamo ancora utilizzando Cat 2.3 per cui le aree principali sono le seguenti:
 
ne----+  
     |---> data  
     |---> dbc  
     |---> work  
     |---> hist

 Se allo stato attuale siamo ancora in grado di far girare tutto il sistema sul nostro hard disk da 2.5 mega byte, prevedo già che un giorno avremo una quantità tale di dati storici che avremo l'esigenza di utilizzare uno spazio maggiore. Per quella data potremmo o decidere semplicemente di acquistare un hard disk più capiente, o adottare una soluzione che ritengo più semplice: aggiungere un altro disco al sistema e montarlo nell'albero delle directory. Per ora possiamo contare su quattro dischi per Cat, montando un disco diverso su ogni directory tra quelle elencate prima. In questo modo avremmo che data girerebbe su un disco, dbc su un altro, e dbc e hist su altri ancora. In teoria le prestazioni dovrebbero migliorare in quanto l'accesso all'area data non dovrebbe risentire dei rallentamenti dipendenti dalle ricerche all'interno di history, o delle letture/scritture effettuate in work.

Ho anche realizzato uno script CGI in Perl per rendere più agevole al dipartimento Commerciale ed a quello Clienti di bloccare Cat durante le chiusure di fine mese e le reindicizzazioni. Lo script chiede una password dopo di che rimpiazza il file batch standard che serve a far partire Cat con un altro file batch che dice che Cat è bloccato per operazioni di chiusura e manutenzione. Non appena terminato si può procedere a sbloccare Cat mandando in esecuzione lo script di sblocco.
Di seguito vengono riportati i due script:

Script per il Lock di Cat:
 
#!/usr/bin/perl 
# ****************************************************** 
# * * 
# * Author: Quinn P. Coldiron * 
# * Date: 11-24-97 * 
# * Program: This locks Cats * 
# * * 
# ****************************************************** 
# Use cgi-lib CGI library for PERL. 
require "/home/httpd/cgi-bin/cgi-lib.pl"; 
#Get the data from the form. 
&ReadParse; 
print &PrintHeader; 
print "<HTML>\n"; 
print "<HEAD>\n"; 
print "<TITLE>Finished</TITLE>\n"; 
print "</HEAD>\n"; 
print "<BODY BGCOLOR= #b7b7b7>\n"; 
if ( $in{password} =~ "PASSWORD") { 
print "<P><B>Finished.</B></P>\n"; 
print "<P>Batch files written and CATS is <B>locked</B>.</P>\n"; 
print "<BR>You may access CATS by going to the M: drive and typing secret.bat\n"; 
print "This should only be used for Month-end closing, reindexing and system repairs.\n"; 
print "<BR><BR>Quinn.\n"; 
system ("cp /home/httpd/cgi-bin/cats/lock/*.bat /usr/local/samba-cats/ne/data/"); 
system ("chmod 777 /usr/local/samba-cats/ne/data/*"); 
} else { 
print "Wrong password\n"; 

print "</BODY>\n"; 
print "</HTML>\n"; 

Script per l'Unlock di Cat:
 
#!/usr/bin/perl 
# ****************************************************** 
# * * 
# * Author: Quinn P. Coldiron * 
# * Date: 11-24-97 * 
# * Program: This program copies that cats#.bat files * 
# * to the correct location. * 
# ****************************************************** 
# Use cgi-lib CGI library for PERL. 
require "/home/httpd/cgi-bin/cgi-lib.pl"; 
#Get the data from the form. 
&ReadParse; 
print &PrintHeader; 
print "<HTML>\n"; 
print "<HEAD>\n"; 
print "<TITLE>Finished</TITLE>\n"; 
print "</HEAD>\n"; 
print "<BODY BGCOLOR= #b7b7b7>\n"; 
if ( $in{password} =~ "PASSWORD") { 
print "<P><B>Finished.</B></P>\n"; 
print "<P>Batch files written and CATS is unlocked.</P>\n"; 
print "<BR><BR>Quinn.\n"; 
system ("cp /home/httpd/cgi-bin/cats/unlock/*.bat /usr/local/samba-cats/ne/data/"); 
system ("chmod 777 /usr/local/samba-cats/ne/data/*"); 
} else { 
print "Wrong password!\n"; 

print "</BODY>\n"; 
print "</HTML>\n"; 
 
 

La Configurazione dei client Windows
Ho effettuato l'installazione di Cat in modo tale che ogni area di lavoro del software fosse condivisa e vista come un'unità disco DOS, individuata da una lettera dell'alfabeto. La parte del file di login che si riferisce a quanto appena detto è riportata di seguito:
 
REM CATS drives 
net use l: \\unplinux\l-ne 
net use m: \\unplinux\m-data 
net use n: \\unplinux\n-dbc 
net use o: \\unplinux\o-work 
net use p: \\unplinux\p-hist 

Il file batch relativo a cat è il seguente:
 
PATH=C:\;C:\WINNT;C:\WINDOWS;L:\;M:\;N:\;O:\;P:\ 
SET DBC_FILEPATH=L:\;M:\;N:\;O:\;P:\ 
Set DBC_PREP=M: 
Set DBC_FILES=140 
Set DBC_PGMSIZE=65024 
Set DBC_CMDLINE=OLD 
SET DBC_XKEYS=ON 
Set DBC_COMPAT=DOS 
Set DBC_PORT=24 
SET DBC_DBCPATH=N:\ 
M: 
DBC.EXE 

Nel realizzare quanto riportato ho seguito i suggerimenti riportati nel sito web di Cat, all'indirizzo http://www.tcpj.com, specifici per la predisposizione dei parametri relativi a Windows 95, ed ho trovato che grazie a loro funziona meglio anche Cat.

La Configurazione dell'emulatore DOS per mandare in esecuzione Cat
Linux dispone di un programma molto interessante denominato DOSEMU che serve a creare una "macchina DOS" in grado di mandare in esecuzione una miriade di applicazioni DOS, tra le quali MS-DOS, PC-DOS, DR-DOS, Open DOS, Windows per Workgroup 3.11, un client Netware Novell e molte altre ancora. Inizialmente ho avuto problemi a far sì che DOSEMU lanciasse programmi sui drive ridiretti a meno che non chiamassi questi file con l'intero nome (ad es. go.bat in luogo di go), ho poi scoperto però che tutto ciò dipendeva dalla versione di DOS che stavo utilizzando: in effetti avevo installato il DOS Novell 7.0, ma non appena sono passato all'MS-DOS 6.22, seguendo le avvertenze di Hans Lermen (uno degli sviluppatori di DOSEMU), tutto è andato a posto. Secondo le avvertenze appena citate sembra che questo problema sia stato segnalato diverse volte e che sia da attribuire ad un errore del command.com utilizzato da molte versioni non Microsoft di DOS.

DOSEMU utilizza un file (immagine di un hard disk) per emulare un hard disk DOS, per cui non si ha bisogno di alcuna partizione DOS. Utilizzando il comando /var/lib/dosemu/setup-hdimage si viene guidati alla creazione di un file hdimage di base. L'unica cosa richiesta è un dischetto di avvio DOS 6.22 con ogni tipo di applicativo DOS di cui si pensi di aver bisogno. Personalmente vi ho inserito EDIT.COM e QBASIC.EXE. Dopo aver lanciato il programma setup-hdimage basta lanciare xdos o dos a seconda se ci trova in X Windows oppure no. All'avvio, normalmente, il disco Linux viene visto come disco DOS D:\. Per copiare i programmi che volevo trasferire dal dischetto sul disco hdimage ho aperto un'altra finestra xterm ed ho montato il floppy su /mnt/floppy, sono quindi tornato su DOSEMU, ho effettuato un cambiamento di directory su D:\mnt\floppy ed ho copiato EDIT.COM e QBASIC.COM su C:\. In questo modo posso lanciare l'editor MS-DOS per modificare i file config.sys ed autoexec.bat e, se voglio, posso anche relizzare qualche programmino QBASIC veloce veloce.

Con DOSEMU viene fornito anche un programma denominato LREDIR che ridireziona le aree Linux su lettere di drive DOS. Di seguito è riportato il file AUTOEXEC.BAT che utilizzo con DOSEMU per ottenere lettere di drive per le aree Cat e Robotronics.
 
@echo off 
path=c:\;l:\;m:\;n:\;o:\;p:\ 
prompt $p$g 
rem set temp=c:\temp 
lredir l: linux\fs\usr\local\samba-cats\ne 
lredir m: linux\fs\usr\local\samba-cats\ne\data 
lredir n: linux\fs\usr\local\samba-cats\ne\dbc 
lredir o: linux\fs\usr\local\samba-cats\ne\work 
lredir p: linux\fs\usr\local\samba-cats\ne\hist 
lredir t: linux\fs\usr\local\samba-sys\programs\nesb 
c: 
menu.bat 

Questo file autoexec.bat carica i drive ridiretti e visualizza un menu che consente all'utente di selezionare l'applicazione DOS che vuole mandare in esecuzione (Cat o Robotronics). Ho predisposto l'emulatore dos come shell di ingresso in modo tale che non appena un utente Mac o un utente remoto effettuano telnet sul server Linux viene avviato l'emulatore DOS e parte il menu principale. Allorché si esce dall'emulatore dos si viene disconnessi dal server.

L'installazione di RAID
Il RAID che abbiamo deciso di acquistare è un kit che prevede un controller SCSI RAID ed un sottosistema di memorizzazione della Distributed Processing Technology.

La scheda SCSI è di tipo PCI e porta con sé un modulo di cache che ha al suo interno quattro SLOT SIMM nei quali possono trovare posto le usuali SIMM a 32 pin (per un massimo di 16 MB di memoria ciascuna) fino ad un totale di 64 MB di cache. La scheda viene fornita con un modulo da 4 MB preinstallato che è quanto stiamo utilizzando attualmente.

Il sottosistema di memorizzazione prevede che ci si debba dotare di dischi propri e viene fornito in modo da poter funzionare in due modalità diverse: la prima prevede l'utilizzo di dischi SCSI piuttosto limitati, la seconda l'utilizzo di dischi di grandi capacità. Attualmente il sistema viene utilizzato nella prima configurazione soprattutto perché ci sono già tre dischi da utilizzare. Per quanto riguarda l'installazione, invece, si possono incontrare diversi problemi uno dei quali, ad esempio, è la mancanza di un riferimento nei cavi di connessione, per cui non si è in grado di riconoscere il pin uno. La prima volta che ho provato ad installare i dischi li ho messi alla rovescia, ma grazie al cielo non è successo nulla. Una chiamata al servizio tecnico di supporto è stata di grande aiuto in quanto mi ha consentito di superare l'impasse.

Dopo aver installato la scheda nel server si deve provvedere ad installare il RAID con il livello di scelta RAD. Personalmente ho ritenuto di dover far funzionare RAID a livello 5. Nel contempo mentre Linux ha dei drive interni per la scheda controller DPT, la scheda DPT stessa non fornisce programmi di utilità in ambiente Linux per poter configurare il sistema, per cui sono stato costretto ad adottare un piccolo stratagemma. Ho provvisoriamente inserito nel server un disco IDE da 200 MB con il quale effettuare la procedura di avvio del DOS e lanciare il software di configurazione (sempre DOS) che si presenta con un'interfaccia grafica molto facile da utilizzare. Ho così provveduto a selezionare i tre dischi che volevo includere nel RAID ed ho selezionato il livello di RAID che desideravo, ho poi salvato la configurazione e spento il computer. A questo punto ho sfilato l'hard disk DOS e reinserito il disco IDE con Linux.

Quando ho installato il drive per la scheda SCSI rilanciando il programma di installazione di Linux mi sono sentito quasi un ladro. In effetti avevo altre cose da sistemare per cui ho pensato che questa sarebbe stata la soluzione migliore. Molto più semplicemente mi sarebbe bastato lanciare il demone corrispondente utilizzando uno dei pacchetti del pannello di controllo, ovvero avrei potuto scrivere insmod eata-dma al prompt di sistema ed il drive sarebbe stato caricato mentre nel contempo mi veniva inviato un rapporto con il quale mi si diceva che il sistema vedeva la scheda SCSI ed il RAID. Qualora si scelga di ripetere la fase di installazione si deve selezionare SI (YES) quando viene chiesto se sul sistema è presente una scheda SCSI e va poi selezionato il drive per la scheda di cui si dispone (EATA-DMA). Non appena finito si rilancia il sistema e non appena il nucleo arriva a riconoscere la scheda, si vede il messaggio di inizializzazione del RAID accompagnato dai dati relativi al settaggio effettuato sotto DOS.

A questo punto si ha soltanto l'esigenza di creare partizioni e formattare il disco. Nel primo caso basta lanciare fdisk e seguire le istruzioni necessarie a creare una partizione Linux primaria; formattare il RAID è facile come formattare un qualunque altro disco. Si ricordi che il sistema vede il RAID come un unico grande disco e che per formattarlo in Linux basta lanciare il comando mkefs2 /dev/sda1 (ovvero il nome di qualunque altro disco SCSI). Per utilizzare il disco occorre quindi procedere a montarlo su una qualche area. Per quanto mi riguarda ho deciso di utilizzare questo disco per le aree di accesso degli utenti per cui l'ho montato su /home/raid. Mi è capitato però che nel momento in cui aggiungevo un utente questo mi veniva inserito ancora in /home piuttosto che nell'area RAID per cui ho dovuto editare lo script /usr/bin/adduser (che è uno script perl) e cambiare l'allocazione dell'area di partenza in /home/raid. Attualmente tutto funziona alla perfezione e l'area di ogni nuovo utente viene aggiunta in RAID.

L'amministrazione quotidiana
I backup di sistema
Per i lavori di backup sul server Linux sto predisponendo un drive SCSI HP SureStore 6000 da 4mm anche se a tutt'oggi il backup di tutti i dati avviene utilizzando Samba sul server Windows NT mediante

un altro drive a nastro SureStore 6000 ed il software Arcserve Cheyenne. Mi è stato anche chiesto di fare un backup veloce sul RAID mediante tar, un programmino semplice ma efficace che va in giro più o meno da quando esiste Unix.

Per fare un backup con tar basta dare il seguente comando:

tar cvf nomearchivio.tar /directory-da-archiviare

Si viene così a creare un file tar di nome archivio.tar all'interno del quale trova posto il contenuto dell'area directory-da-archiviare. Se questo comando funziona alla perfezione accade però che il file risultante dall'operazione può essere di dimensioni rilevanti non venendo applicata alcuna compressione. Conviene pertanto

modificare il comando come segue:

tar cvzf nomearchivio.tar.gz /directory-da-archiviare

in tal modo, infatti, il file tar appena creato viene compresso mediante gzip. Se in un secondo momento si vorrà vedere il contenuto di questo file si potrà sempre utilizzare il comando tar tvf nomearchivio.tar.gz ed avere un elenco dei file in esso contenuti.

Se effettuare un backup su disco può andare bene per salvataggi temporanei nel caso di salvataggio di dati critici si deve comunque far ricorso ad unità a nastro. In ambiente Linux si ha la possibilità di utilizzare due tipi di unità: il primo corrisponde ad un collegamento al controller dell'unità floppy, come accade per le unità Colorado e Iomega Ditto.

Il secondo corrisponde ad un collegamento ad un'unità SCSI. Unità a nastro di tipo floppy hanno i nomi seguenti: /dev/ft0, /dev/ft1, ecc., mentre unità SCSI vengono individuate da: /dev/st0, /dev/st1, ecc. Tutte queste unità sono di tipo "riavvolgimento" (rewinding) nel senso che quando l'operazione di accesso all'unità è terminata il nastro viene riavvolto. Se si devono effettuare più sessioni di archiviazione su nastro vanno utilizzate le unità non-rewinding /dev/nft0, /dev/nrft1, /dev/nst0, /dev/nst1 e così via.

Dopo aver scritto l'archivio su nastro si può utilizzare il comando mt (magnetic tape = nastro magnetico) per riavvolgere il nastro, fissare la sua tensione e trovare le varie sessioni di archiviazione. Di seguito vengono riportati i comandi corrispondenti:

mt /dev/nft0 rewind

mt /dev/nft0 retention

mt /dev/nft0 fsf 1 (salta la sessione corrente per spostarsi sulla sessione di archiviazione successiva)

Per poter utilizzare il comando mt occorre ricordarsi di utilizzare i nomi delle unità non rewinding.

L'utilizzo di tar per la creazione di backup ha vantaggi e svantaggi. Tra gli svantaggi va annoverato il fatto che né tar né gzip sono insensibili agli errori (fault-tolerant). In pratica se si comprimono file tar con gzip si riduce enormemente lo spazio occupato sull'unità di salvataggio,

ma basta che anche un solo blocco dell'archivio sia corrotto (per qualche verso non più recuperabile), il che sui nastri può accadere con relativa facilità, perché l'intero file venga reso inutilizzabile. È pur vero che, in generale, si riesce a recuperare tutti i dati fin al punto in cui compare l'errore, ma è altrettanto vero che una soluzione migliore consiste nell'utilizzo di un vero e proprio sistema di backup qual'è BRU (Backup e Restore Utility) che viene fornito con Linux RedHat 5.0. I sistemi di backup, normalmente, comprimono i file individualmente per cui qualora il nastro fosse danneggiato non si andrebbe a perdere l'intero archivio.

BRU, compreso nella RedHat 5.0, ha sia un'interfaccia a prompt di sistema che un'interfaccia grafica di tipo X-Windows e consente una completa automatizzazione dei backup, ne consegue che è abbastanza semplice riuscire a mettere in piedi un efficace quanto affidabile sistema di backup. Per quanto mi riguarda ho trovato questo sistema altrettanto semplice da gestire quanto l'ArcServe su Windows NT.

La schedulazione degli eventi
Linux utilizza un programma per la schedulazione degli eventi facilissimo da utilizzare, si tratta di cron che è in grado di eseguire comandi, script o programmi ai tempi prefissati. Per gestire l'elenco degli eventi si utilizza il comando crontab -e, il quale manda in esecuzione un normale editor (normalmente vi anche se è possibile utilizzarne un altro - io utilizzo joe); all'uscita dell'editor cron provvede ad installare il file di configurazione appena redatto ed a scandire l'esecuzione di tutti i lavori previsti. Per visualizzare l'elenco dei lavori da gestire basta dare il comando crontab -l:
 
SHELL=/bin/bash 
PATH=/sbin:/bin:/usr/sbin:/usr/bin 
MAILTO=root 
# Run any at jobs every minute 
# * * * * * root [ -x /usr/sbin/atrun ] && /usr/sbin/atrun 
# run-parts 
# 01 * * * * root run-parts /etc/cron.hourly 
# 02 1 * * * root run-parts /etc/cron.daily 
# 02 2 * * 0 root run-parts /etc/cron.weekly 
# 02 3 1 * * root run-parts /etc/cron.monthly 
# Remove /tmp, /var/tmp files not accessed in 10 days (240 hours) 
# 41 02 * * * root /usr/sbin/tmpwatch 240 /tmp /var/tmp 
# Remove formatted man pages not accessed in 10 days 
# 39 02 * * * root /usr/sbin/tmpwatch 240 /var/catman/cat? 
############################################################# 
# WWW logs. I run 2 so I can compare results. 
############################################################# 
# Run web one web log utility 0 0-23 * * * /usr/bin/log 
02 1 * * * /usr/bin/log 
# Run the other web log utility 0 0-23 * * * /usr/local/mkstats/mkstats.pl -c mkstats.config 
02 1 * * * /usr/local/mkstats/mkstats.pl -c mkstats.config 
############################################################# 
############################################################# 
# Live stream management 
############################################################# 
# Create xdm file for live stream for Sports Nightly (5:45 pm) 
45 17 * * 1,2,3,4,5 livestream-on 
# Kill xdm file for live stream for Sports Nightly (8:10 pm) 
10 20 * * 1,2,3,4,5 livestream-off 
# Create xdm file for live stream for Saturday games (7:00 am) 
0 7 * * 6 livestream-on 
# Kill xdm file for live stream for Saturday games (10:00 pm) 
0 22 * * 6 livestream-off 
# Check the 3.0 server to see if it is running and not dead! (every minute) 
1-59 * * * * /usr/local/streamworks-3.0/checkSWserver 
############################################################## 
# Check to see if network volumes are mounted (at 10:00 p.m.). 
# These need to be mounted since this machine performs the 
# backup at 11:55. 
0 22 * * 1,2,3,4,5 checkmounts 
# copy BIP from Intrepid to exeter (WWW) 
0 23 * * 1,2,3,4,5 /usr/local/bin/mvbip 
# backup userdata from intrepid 
55 23 * * 1,2,3,4,5 bu-userdata 
# backup CATS 
55 23 * * 1,2,3,4,5 bu-cats 
# backup Marketing 
0 3 * * 1,2,3,4,5 bu-marketing 
# mail orders to quinn 
0 8 * * 1,2,3,4,5 /usr/local/bin/mailunporders.pl 

Ogni riga di questo file ha una connotazione ben precisa; se ad esempio si vuole eseguire un certo comando ogni giorno all'una 1:00 AM, si deve specificare 0 per i minuti e 1 per l'ora. Tutti gli altri campi devono essere costituiti da asterischi con il che si dice al sistema "ogni giorno, di ogni mese, all'orario assegnato".

A titolo esemplificativo si vedano le righe seguenti

# Check to see if network volumes are mounted (at 10:00 p.m.).
# These need to be mounted since this machine performs the
# backup at 11:55.
0 22 * * 1,2,3,4,5 checkmounts

Con quanto realizzato si manda in esecuzione uno script che va a verificare se il server NT è montato, in modo che si possa andare a salvare i dati su di lui. In questo caso specifico ho montato il server utilizzando il comando smbmount che consente ad una macchina Linux di montare aree condivise di macchine Windows. Lo script, in effetti, va soltanto a verificare che un certo file o una certa directory siano nel punto di mount; allo scopo utilizzo dei file "di riferimento" a solo scopo di verifica, predisposti in sola-lettura in modo che non possano essere inavvertitamente cancellati da qualche utente. Il listato dello script è riportato di seguito:
 
#!/bin/sh 
# Cronjob to remount network drives if they are not mounted. 
# Author: Quinn P. Coldiron 
if [ -z "`ls /mnt/exeter | grep InetPub | grep -v grep`" ] 
then 
umount /mnt/exeter 
/mnt/mountexeter 
echo "Exeter remounted `date`" 
fi 
if [ -z "`ls /mnt/intrepid-f | grep BLINE | grep -v grep`" ] 
then 
umount /mnt/intrepid-f 
/mnt/mountintrepid-f 
echo "Intrepid F remounted `date`" 
fi 
if [ -z "`ls /mnt/intrepid-g | grep QC | grep -v grep`" ] 
then 
umount /mnt/intrepid-g 
/mnt/mountintrepid-g 
echo "Intrepid G remounted `date`" 
fi 
if [ -z "`ls /mnt/intrepid-mrktdept | grep KK | grep -v grep`" ] 
then 
umount /mnt/mountintrepid-mrkt 
/mnt/mountintrepid-mrktdept 
echo "Marketing remounted `date`" 
fi 
echo "All network volumes mounted." 
 

 

Perché rimpiazzare il S. O. sul proprio desktop con Linux
Siti da visitare: Da molto tempo desideravo poter utilizzare Linux come sistema operativo per il mio desktop ma ho sempre dovuto rimandare avendo l'esigenza di dover utilizzare le seguenti applicazioni: Microsoft Word, WordPerfect, Microsoft Excel, Microsoft Access, il nostro sistema di posta elettronica interno (Pegasus), Microsoft Access e Microsoft Visual Basic. Recentemente nel riesaminare la lista delle applicazioni particolarmente utili che non hanno corrispondenza in Linux mi sono soffermato esclusivamente su Access e Visual Basic.

Ho trovato infatti che, per lo più, posso rimpiazzare Microsoft Office con Applixware, un pacchetto di applicazioni per ufficio in ambiente Linux (e quindi per molte altre piattaforme Unix), in grado di leggere e scrivere file Word ed Excel, che mi consente di condividere documenti con il resto del personale dell'ufficio. Resta il fatto che non posso ancora leggere database Access, ma per questo sto studiando una soluzione che analizzeremo più in là

Applix Word (Elaboratore testi)

Applix Spreadsheet (Foglio elettronico) Applix Presentation Graphics (Software per gestione presentazioni) Applix Mail (Posta elettronica) Applix HTML editor (creazione di pagine Web) L'Extension Language Facility (ELF) e le Macro Variazioni rispetto alla versione precedente

Questa nuova versione presenta caratteristiche HTML avanzate per la creazione semplice ed immediata di pagine web. Al suo interno è stato poi enormemente potenziato l'utilizzo della tecnologia dei filtri che consente, ad esempio, di importare ed elaborare file prodotti da Word o Wordperfect, oltre che di esportare file in questi stessi formati. Se poi si desidera avere le cose in tempo reale basta aver presente che Corel ha la versione 7.0 di Word Perfect disponibile per Linux.

L'interfaccia grafica d'utente per Linux (ed Unix in generale) è X Windows. Un esempio tipico di avvio di X Windows è mostrato di seguito. Il sistema sta eseguendo il gestore di finestre CDE (Common Desktop Environment) ed X Windows si presenta suddiviso in due sottosistemi consistenti rispettivamente di un server ed un client tra i quali l'utente può liberamente muoversi a suo piacimento. La motivazione principale che può indurre a cambiare un X server risiede nel cercare di acquisire tutti i vantaggi legati all'uso della scheda video e del monitor di cui si dispone. La scelta di un diverso gestore di finestre (window manager) dipende, invece, essenzialmente dall'aspetto di ciò che si vuole vedere. Si tenga presente che in MS Windows, in nessun caso si può modificare il server o il gestore di finestre, in quanto Microsoft ha già deciso quello che sarà l'aspetto delle finestre. Il meglio che si può ottenere proviene dalla scelta di un tema all'interno del pacchetto Plus!

Altra possibilità che consente di risparmiare denaro e ridare vita ad un vecchio 486, consiste nell'installare Linux su quest'ultima macchina ed utilizzarla come una macchina di rete (NC = Network Computer). L'interfaccia grafica di Linux (GUI) è X per cui la macchina funzionerà alla perfezione come terminale X (con un'altra macchina Linux o qualunque altro sistema Unix) e se ci si doterà del pacchetto client Keoke in ambiente Java, della Insignia Solutions Inc., si potrà trasformare la stazione di lavoro Linux in un bel client in grado di gestire applicazioni Windows (NT virtuale).

In generale Linux si comporta molto meglio di Windows 3.1 su una macchina con la stessa quantità di memoria; addirittura, se si ha un po' di pazienza, lo si può vedere in funzione completo dell'ambiente grafico anche su un 386 con 4 MB di RAM. Se si va ad aggiungere Netscape Navigator può bastare un 486 con 8 MB di RAM, mentre se si vogliono migliori prestazioni, e ad esempio si utilizza Communicator, occorre dotarsi di 16 MB di RAM. Va notato infine che Linux non prescrive limiti allo spazio disco necessario al suo utilizzo anche se poi lo spazio disponibile condiziona l'installazione del software; a titolo di esempio si tenga presente che il client grafico della Caldera, ridotto all'osso, occupa all'incirca 68 Mb di spazio disco. Se ci si limita ad installare l'essenziale (Netscape, Java e forse un gestore di finestre più amichevole di Fvwm) si potrà aver bisogno al massimo di 32 MB di area di swap e, tutto considerato, molto probabilmente un disco da 200 MB andrà più che bene per la maggioranza dei desktop.

Appendice A
Guida all'installazione di RedHat 5.0
Appendice B
Samba
Appendice C
Manuale di DOSEMU

Per l'articolo originale: © 1998 Quinn P. Coldiron
Pubblicato sul n. 29- Giugno 1998 di Linux Gazette
Per l'edizione italiana: © 1998 LGEI