Figura 18.5. Situazione prevista nel collegamento attraverso la linea commutata.
|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione licenza] [translators] [docinfo] [indice analitico] [volume] [parte]
Nel capitolo sull'utilizzo generale di nanoLinux e in quello che descrive con maggiore dettaglio le particolarità di questo, mancano alcuni dettagli importanti sull'utilizzo in una rete. Questo capitolo mostra le varie situazioni per cui nanoLinux è predisposto.
Si osservi che nanoLinux è organizzato per funzionare correttamente in reti IPv4, anche senza la risoluzione dei nomi locali; la gestione di IPv6 è prevista in alcune situazioni, ma il funzionamento di questo protocollo non è garantito.
La lettura di questo capitolo e l'utilizzo relativo di nanoLinux presuppongono una conoscenza adeguata delle reti IPv4 e dei servizi principali che si possono gestire attraverso i protocolli TCP/IP (volume II).
La connessione di nanoLinux attraverso un modem con una linea telefonica commutata (PSTN) si ottiene attraverso il comando nanorc ppp on e segue la procedura seguente:
# nanorc ppp on[Invio]
|
Come si vede dalla figura, viene richiesto di inserire il file di dispositivo corrispondente alla porta seriale cui è connesso il modem (deve trattarsi di un modem esterno).
/dev/ttyS0<OK>
Quindi viene richiesto di inserire il nominativo utente per accedere; si osservi che alcuni fornitori richiedono di indicare l'indirizzo di posta elettronica completo in questa situazione:
|
tizio<OK>
Viene richiesto di inserire la parola d'ordine per accedere al servizio; questa non appare visualizzata mentre viene inserita:
|
digitazione_all'oscuro<OK>
A questo punto viene richiesto l'inserimento del numero di telefono del fornitore:
|
0987654321<OK>
A questo punto inizia la procedura di collegamento:
Trying to connect to 0987654321 as tizio. |
Se tutto va bene, si attiva il collegamento.
|
Figura 18.5. Situazione prevista nel collegamento attraverso la linea commutata.
|
Come si può intendere dalla figura, quando il collegamento attraverso il protocollo PPP viene attivato, l'elaboratore si trasforma in un router NAT, che consente l'accesso all'esterno anche ad altri elaboratori che potrebbero essere collegati in una rete locale con indirizzi privati. Teoricamente, dovrebbe anche attivarsi un tunnel IPv6 e di conseguenza il demone radvd per assegnare dinamicamente degli indirizzi IPv6 validi per tutta la rete locale.
Eventualmente si può intervenire negli script contenuti nelle directory /etc/ppp/ip-up.d/ e /etc/ppp/ip-down.d/, soprattutto per ciò che riguarda la configurazione del firewall; ciò può essere fatto anche durante il funzionamento da CD-ROM o da DVD-ROM, tenendo conto che poi conviene salvare la configurazione in un disco o in una partizione.
L'utilizzo di nanoLinux in una rete locale, che può disporre eventualmente di un router, si configura normalmente attraverso i comandi consueti come ifconfig e route, ma può essere definita una configurazione duratura (eventualmente salvandola in un disco se si utilizza nanoLinux da CD-ROM o da DVD-ROM).
|
Figura 18.6. Utilizzo di nanoLinux in una rete locale tipica.
|
La figura mostra una situazione pratica: l'elaboratore in cui è in funzione nanoLinux deve utilizzare l'indirizzo IPv4 192.168.1.7 (in quanto si trova nella rete 192.168.1.0/255.255.255.0) e può accedere all'esterno della rete locale attraverso un router NAT raggiungibile all'indirizzo 192.168.1.254. Per configurare nanoLinux attraverso nanorc si procede nel modo seguente:
# nanorc network config[Invio]
|
eth0<OK>
|
192.168.1.7<OK>
|
Volendo dichiarare esplicitamente di voler utilizzare il protocollo DHCP, al posto dell'indirizzo IPv4 si deve inserire la parola chiave AUTO. In tal caso, le richieste successive non vengono fatte all'utente. |
|
255.255.255.0<OK>
|
192.168.1.254<OK>
Si osservi che se la rete locale dovesse essere sprovvista di un router (una rete locale isolata), è importante evitare di indicare come indirizzo del router lo stesso indirizzo dell'interfaccia di rete locale, perché la concomitanza degli indirizzi fa presumere alla procedura prevista per nanoLinux che il nodo locale sia precisamente un router nei confronti della rete locale.
nanoLinux può essere usato anche per intervenire in qualità di router al servizio di una rete locale, per la connessione con una rete esterna. Si immagina una situazione simile a quella della figura successiva.
|
Figura 18.11. nanoLinux utilizzato come router.
|
Nella figura, il router si colloca tra due reti: 172.21.*.* e 192.168.1.*. Per la precisione, la rete 172.21.*.* accede all'esterno attraverso la trasformazione degli indirizzi (NAT), perché si presume che gli instradamenti nella rete 192.168.1.* consentano di raggiungere l'esterno (Internet), ma non di accedere alla rete 172.21.*.*.
# nanorc network config[Invio]
|
eth0<OK>
|
172.21.254.254<OK>
|
255.255.0.0<OK>
|
172.21.254.254<OK>
Dal momento che l'indirizzo del router per la rete interna coincide con l'indirizzo dell'interfaccia, la procedura intende che si debba specificare anche il collegamento con l'esterno:
|
eth1<OK>
|
192.168.1.253<OK>
|
255.255.255.0<OK>
|
192.168.1.254<OK>
|
Potrebbe essere conveniente sfruttare il proxy imponendo il suo utilizzo da parte della rete locale:
<Yes>
Il router che si ottiene si comporta anche come firewall, secondo una configurazione di massima che dovrebbe impedire alcuni tipi di accesso dall'esterno. Tuttavia, se esistono effettivamente dei problemi di sicurezza, la configurazione del firewall deve essere valutata personalmente da chi si incarica di realizzare una rete locale del genere; eventualmente è possibile modificare lo script /etc/init.d/network. Le istruzioni che riguardano la configurazione in qualità di router iniziano a partire dalla porzione di codice evidenziata dal confronto tra l'indirizzo locale e l'indirizzo del router interno:
|
L'esempio mostrato fa riferimento a indirizzi IPv4 privati sia dal lato interno, sia dal lato esterno del router. Con questo esempio si vuole individuare una situazione che potrebbe essere abbastanza comune: una rete locale gestita attraverso un router la cui configurazione non può essere cambiata, senza la disponibilità di indirizzi privati a sufficienza per le esigenze di tutte le reti. Con la soluzione proposta dall'esempio, si va a utilizzare un solo indirizzo nell'ambito della rete precedente, aggiungendo un altro router per un'altra rete locale che comunque sarebbe irraggiungibile nell'ambito di quella preesistente (per mancanza di instradamenti), pertanto si rende necessario il NAT nel nuovo router inserito.
Se non esiste altra possibilità di accedere alla rete esterna se non attraverso un proxy HTTP, è possibile tentare di organizzare la configurazione del router nanoLinux in modo che il proprio proxy faccia riferimento a quello disponibile. Questo è comunque condizionato alla disponibilità di un servizio di risoluzione dei nomi di dominio (DNS) accessibile. Si immagina una situazione simile a quella della figura successiva.
|
Figura 18.21. nanoLinux utilizzato come router che deve avvalersi di un proxy.
|
Come già visto in un esempio di un'altra sezione, nella figura, il router si colloca tra due reti: 172.21.*.* e 192.168.1.*.
# nanorc network config[Invio]
|
eth0<OK>
|
172.21.254.254<OK>
|
255.255.0.0<OK>
|
172.21.254.254<OK>
Dal momento che l'indirizzo del router per la rete interna coincide con l'indirizzo dell'interfaccia, la procedura intende che si debba specificare anche il collegamento con l'esterno:
|
eth1<OK>
|
192.168.1.253<OK>
|
255.255.255.0<OK>
|
In questo caso, non c'è alcun router esterno da poter raggiungere, pertanto si lascia il campo vuoto:
<OK>
|
In questo caso, è necessario attivare la funzione di proxy imponendo il suo utilizzo da parte della rete locale:
<Yes>
A questo punto, però, occorre fare due modifiche manuali; la prima riguarda la configurazione del proxy della propria rete, per rinviare le richieste al proxy esterno. Si deve intervenire nel file /etc/oops/oops.cfg dell'elaboratore che offre questo servizio per la rete locale, aggiungendo le direttive seguenti:
|
Per maggiori dettagli sulla configurazione di questa funzionalità di OOPS conviene consultare la sua documentazione originale.
La seconda modifica da apportare riguarda il servizio DNS: non potendo contare su un accesso alla rete esterna, il servente DNS di nanoLinux non serve a nulla ed è necessario modificare il file /etc/resolv.conf di tutti gli elaboratori della rete locale:
|
Questa situazione potrebbe essere complicata ulteriormente se per l'accesso al proxy esterno o al servente DNS è necessario utilizzare un router. In tal caso si comprende che è sufficiente specificare l'indirizzo di tale router esterno, senza lasciare il campo in bianco come è stato fatto negli esempi mostrati in questa sezione.
Quando si installa nanoLinux può essere conveniente predisporre un servizio di condivisione delle utenze e delle directory personali. Per questo sono disponibili i protocolli NIS e NFS.
La procedura predisposta da nanoLinux prevede la pubblicazione del contenuto dei file /etc/passwd, /etc/shadow e /etc/group, ignorando ogni altro file che il NIS potrebbe fornire.
|
Figura 18.31. NIS e NFS offerti da un elaboratore in cui è installato nanoLinux.
|
Per attivare il NIS in modo da offrire alla rete locale la condivisione dei file /etc/passwd, /etc/shadow e /etc/group, si procede come segue:
# nanorc nis-server config[Invio]
|
Il dominio NIS viene deciso liberamente, in questo caso scegliendo il nome nano-domain:
nano-domain<OK>
|
Si presume che la rete interna sia già stata configurata, pertanto l'indirizzo viene proposto in modo automatico:
172.21.254.254<OK>
Naturalmente, la condivisione delle informazioni contenute nei file delle utenze non è sufficiente: occorre condividere anche le directory personali degli utenti. Se la configurazione di nanoLinux non è stata modificata, la directory /home/ risulta accessibile a qualunque nodo di rete con indirizzi IPv4 privati.
Prima di questo capitolo è spiegato in che modo configurare un nodo cliente per servirsi di un servizio NIS e NFS. In quel caso, è possibile distinguere i due serventi, mentre se si offre il servizio con nanoLinux, la procedura richiede che entrambi i servizi risiedano assieme nello stesso elaboratore (presso lo stesso indirizzo IPv4).
Il file di configurazione /etc/default/nis viene modificato automaticamente dallo script nanorc; tuttavia, se si vuole evitare che il servente NIS metta in funzione il demone ypbind (che procura una serie di inconvenienti), è bene aggiungere la riga seguente in quel file:
|
Se questa riga è presente, viene gestita correttamente da nanorc, anche quando si configura il funzionamento come cliente NIS.
Quando si attiva un servente NIS-NFS, è necessario gestire le utenze esclusivamente nell'elaboratore che offre questo servizio. In generale, una volta installato nanoLinux si possono utilizzare gli strumenti consueti, oppure lo script nanorc:
|
|
La sintassi dovrebbe essere già comprensibile così: add aggiunge un utente; del lo elimina, assieme alla sua directory personale.
Per motivi pratici, la directory personale dell'utente che viene creato contiene nel percorso un'informazione aggiuntiva, che in caso non sia specificata è costituita dalla data di creazione, per individuare in modo molto semplice le utenze più vecchie, senza bisogno di interrogare il file /etc/shadow. Per esempio, se il giorno 31/12/2004 si crea l'utenza pippo e non si altera quanto viene proposto automaticamente, si ottiene la directory personale /home/20041231/pippo/.
L'utilizzo del comando nanorc user add ha anche il vantaggio di facilitare l'inserimento di più utenze, dal momento che all fine di ogni inserimento ne viene proposto subito un altro (che comunque può essere annullato); inoltre, al termine degli inserimenti viene riallineato il NIS.
In condizioni normali, prima di inserire una propria configurazione per l'utilizzo della rete, nanoLinux utilizza il protocollo DHCP per tentare di configurarsi in modo automatico. Tale configurazione automatica, se le informazioni sono disponibili, si spinge anche all'uso del NIS, della condivisione delle directory personali, della stampa condivisa in rete, della gestione di un registro complessivo.
In generale, l'uso predefinito del protocollo DHCP serve soprattutto per facilitare l'uso da CD o da DVD quando è già disponibile tale servizio e non si deve fare un lavoro specifico. Quando invece si vuole usare il DHCP anche per la condivisione delle utenze e gli altri servizi, diventa indispensabile attivare il proprio servente DHCP.
|
Figura 18.34. La situazione prevista, con esempi di indirizzi, per l'utilizzo di un servente DHCP con nanoLinux.
|
In base all'esempio mostrato nella figura, si può procedere alla configurazione del servente DHCP nel modo seguente:
# nanorc dhcp-server config[Invio]
|
Dal momento che è stato stabilito di usare un intervallo di indirizzi differente per il DHCP, il valore viene cambiato:
[Canc][Canc]...
172.21.1.100 172.21.1.199<OK>
|
Se la configurazione proposta è quella che si desidera, si può confermare:
<Yes>
Altrimenti si annulla, salvando ugualmente al configurazione, ma senza attivare immediatamente il servizio:
<No>
Se la configurazione ottenuta non è quella desiderata (per esempio il dominio NIS non è quello desiderato oppure alcuni servizi sono riferiti a indirizzi errati), conviene modificarla attraverso il comando seguente:
# nanorc dhcp-server edit[Invio]
Con questo si passa alla modifica diretta del file /etc/dhcp3/dhcpd.conf. Quando si salva, si riavvia il servizio DHCP.
nanoLinux è organizzato, in modo particolare, per essere installato in una serie di elaboratori di una rete locale, dove tutti i nodi sono uguali, accentrando nel router tutte le funzionalità necessarie, compreso il NIS e la condivisione delle directory personali. Se si accettano le convenzioni previste, è possibile gestire dal nodo utilizzato come router la sincronizzazione di tutti gli altri. Ciò consente di avere copie identiche, eventualmente anche dei dati personali, allo scopo di ridurre il tempo necessario a ripristinare un elaboratore che si guasta.
|
L'organizzazione di un sistema di sincronizzazione degli elaboratori sconsiglia l'uso del servizio DHCP per la configurazione dinamica degli elaboratori. |
|
Figura 18.37. Organizzazione prevista per la rete locale di nanoLinux, quando si vuole gestire la sincronizzazione degli elaboratori.
|
Si osservi la figura: nella rete locale appare un router che incorpora tutti i servizi necessari e una serie di elaboratori che li utilizzano. Questi elaboratori sono divisi in tre gruppi: «tipo uno», «tipo due» e «tipo tre». La differenza sta nella capacità del disco fisso: il tipo uno ha un disco fisso di piccole dimensioni, che ospita il sistema operativo essenziale, senza la directory /usr/, che viene innestata da un elaboratore di tipo due o di tipo tre; il tipo due ha un disco fisso abbastanza grande da ospitare tutto il file system. Tutti i tipi di elaboratori ottengono la directory /home/ dal nodo che offre i servizi, ma il tipo tre conserva una copia di questa nella directory /home-backup/.
Una volta organizzata questa cosa, nell'elaboratore che contiene i servizi si configurano gli elenchi degli elaboratori, divisi per tipo, con i comandi seguenti:
# nanorc mirror edit1[Invio]
# nanorc mirror edit2[Invio]
# nanorc mirror edit3[Invio]
Ognuno di questi comandi permette di modificare un elenco di indirizzi IPv4, corrispondenti agli elaboratori di un certo gruppo. Seguendo l'esempio della figura, il primo gruppo contiene l'indirizzo 172.21.1.1, il secondo gruppo contiene 172.21.2.1 e il terzo contiene 172.21.3.1. L'indirizzo dell'elaboratore che offre i servizi e che rappresenta il modello usato per la sincronizzazione è escluso da questi elenchi.
|
Questi elenchi possono essere realizzati in modo molto semplice, indicando gli indirizzi IPv4, ognuno in una riga separata. Volendo di possono inserire anche dei commenti, preceduti dal simbolo #, come si farebbe con altri file di configurazione comuni. |
Per la sincronizzazione dei nodi si utilizza OpenSSH (assieme a Rsync), pertanto occorre disporre di una coppia di chiavi, che ogni tanto può essere utile cambiare. Si creano queste chiavi con il comando seguente:
# nanorc mirror newkey[Invio]
In questo modo, oltre che aggiornare le chiavi, si ottiene la copia di queste negli elaboratori della rete, previsti nei tre elenchi già descritti. In questo caso, viene richiesto ogni volta di inserire la parola d'ordine per accedere, ma una volta aggiornate le chiavi in tutti gli elaboratori, la sincronizzazione dovrebbe avvenire senza tale richiesta.
È possibile creare al volo una copia dell'elaboratore usato come riferimento, avviandone un altro attraverso un CD-ROM o un DVD-ROM di nanoLinux. Supponendo di avere creato le partizioni nel disco fisso di questo nuovo elaboratore e di dover installare la copia nella partizione che temporaneamente è montata nella directory /mnt/hda3/, si può procedere con il comando seguente, supponendo di voler realizzare una stazione di tipo due:
# nanorc mirror sync2s[Invio]
|
In questo caso, avendo richiesto precisamente una sincronizzazione singola, gli elenchi non vengono presi in considerazione e si deve rispondere alla richiesta di indicare espressamente l'indirizzo IPv4 della destinazione da sincronizzare:
172.21.3.1<OK>
|
Viene richiesto di specificare la directory di origine; in condizioni normali è la radice, come si vede nell'esempio. Se si indica una directory diversa si intende copiare solo una porzione del file system.
/<OK>
|
Il valore predefinito viene cambiato, dal momento che la partizione è stata montata nella directory /mnt/hda3/:
/mnt/hda3<OK>
Al termine inizia la sincronizzazione. Naturalmente, alla fine della copia, occorre provvedere ad assestare l'avvio del sistema, così come si farebbe quando si installa nanoLinux da un CD-ROM o da DVD-ROM.
|
Dalla sincronizzazione sono esclusi alcuni file, per impedire che la sovrascrittura possa generare degli inconvenienti, anche soltanto a causa del mancato completamento della sincronizzazione stessa. Per esempio, non vengono trasferiti i file |
Per la sincronizzazione di elaboratori già predisposti e previsti negli elenchi relativi, non viene fatta alcuna richiesta, perché le directory di origine e di destinazione devono essere necessariamente la radice.
Naturalmente, la sincronizzazione tra macchine differenti richiede l'adattamento di alcuni file di configurazione. Il sistema di sincronizzazione tiene conto di questo fatto attraverso una gerarchia che si articola a partire da /etc/nanoLinux/sync/indirizzo_ipv4/. In pratica, se si sta sincronizzando l'elaboratore 192.168.3.1, alla fine della copia dei dati, tutto il contenuto di /etc/nanoLinux/sync/192.168.3.1/ viene copiato a partire dalla directory radice (/) dello stesso elaboratore.
|
È bene considerare anche un particolare importante: il file |
Tabella 18.1. Alcuni file di configurazione che conviene ricordare di predisporre quando si vuole organizzare una rete locale con elaboratori sincronizzati tra di loro.
Prima di concludere, vale la pena di considerare anche una situazione meno comune, in cui si vuole che gli elaboratori abbiano semplicemente una copia identica di tutto, anche delle directory personale, considerato che la sovrascrittura di queste non pone problemi. In tal caso, una volta realizzata la copia per la prima volta, è sufficiente sostituire la directory /home/ con un collegamento simbolico che punta alla directory /home-backup/.
Per comprendere meglio il meccanismo della sincronizzazione, si precisa meglio lo schema mostrato in precedenza, per descrivere come si può procedere.
|
Figura 18.41. Situazione pratica con un elaboratore che funge da router e offre i servizi alla rete.
|
Si procede configurando l'elaboratore che deve offrire i servizi e che svolge anche il ruolo di router NAT:
# nanorc network config[Invio]
|
eth0<OK>
|
172.21.254.254<OK>
|
255.255.0.0<OK>
|
172.21.254.254<OK>
|
eth1<OK>
|
192.168.1.253<OK>
|
255.255.255.0<OK>
|
192.168.1.254<OK>
|
<Yes>
Dal momento che l'elaboratore principale dispone di una stampante si configura anche quella:
# nanorc printer config[Invio]
|
Si suppone che si tratti di una stampante che riconosce il linguaggio PCL5:
laserjet<OK>
|
127.0.0.1<OK>
|
/dev/lp0<OK>
Dopo aver predisposto queste e anche altre cose su cui qui si sorvola, si predispone la gerarchia /etc/nanoLinux/sync/, in modo da inserire le varianti degli altri elaboratori della rete. Per cominciare, i file /etc/nanoLinux/sync/*/etc/default/nis possono essere tutti uguali, in modo da dichiarare il proprio come un elaboratore che utilizza il servizio e non lo offre:
|
Dal momento che i vari elaboratori della rete si avvalgono del NIS per ottenere le informazioni sulle utenze, si devono preparare i file /etc/nanoLinux/sync/*/etc/passwd, /etc/nanoLinux/sync/*/etc/shadow e /etc/nanoLinux/sync/*/etc/group, in modo da non avere utenti comuni, dove questi, rispettivamente, devono terminare per:
|
|
|
Se si usa anche il file /etc/gshadow, occorre predisporre anche una copia per questo, che termini così:
|
Dal momento che i vari elaboratori della rete sono sempre soltanto la copia dell'elaboratore che offre i servizi, anche i file per le registrazioni del sistema vengono sovrascritti, pertanto diventa necessario fare in modo che questi dati vengano inviati tutti all'elaboratore principale. Per questo occorre predisporre dei file /etc/nanoLinux/sync/*/etc/syslog.conf diversi da quello di partenza; quello che conta nell'esempio seguente è l'ultima riga:
|
In generale è necessario creare dei file /etc/nanoLinux/sync/*/etc/fstab alternativi a quello dell'elaboratore principale, con l'indicazione delle partizioni da montare, oltre al problema delle directory /home/ e /usr/. Per esempio, il file /etc/nanoLinux/sync/172.21.1.1/etc/fstab potrebbe assomigliare, nella sua parte iniziale, all'estratto seguente:
|
Dal momento che nella rete locale che si predispone non ci sono altre stampanti oltre a quella collegata all'elaboratore principale, si predispongono i file /etc/nanoLinux/sync/*/etc/printcap in modo da inviare lì le richieste di stampa. Il file in questione deve iniziare così:
|
Naturalmente ci sono anche altre cose da sistemare, per esempio la configurazione di GPM attraverso i file /etc/nanoLinux/sync/*/etc/gpm.conf, la configurazione di XFree86 attraverso i file /etc/nanoLinux/sync/*/etc/X11/XF86Config, la configurazione di GRUB attraverso i file /etc/nanoLinux/sync/*/boot/grub/menu.lst.
Al termine, si procede a predisporre le partizioni previste negli elaboratori della rete locale, iniziando con una sincronizzazione individuale con l'aiuto di un CD-ROM o di un DVD-ROM di nanoLinux:
# nanorc mirror sync1s[Invio]
...
# nanorc mirror sync2s[Invio]
...
# nanorc mirror sync3s[Invio]
...
Una volta sistemati i vari elaboratori, si possono predisporre gli elenchi all'interno di quello principale e al termine tutto dovrebbe essere pronto.
# nanorc mirror edit1[Invio]
...
# nanorc mirror edit2[Invio]
...
# nanorc mirror edit3[Invio]
...
Sono previste due utenze particolari, denominate rispettivamente shutdown e admin, che inizialmente sono disabilitate (richiedono l'attribuzione di una parola d'ordine). Queste utenze sono associate al numero UID zero, pertanto hanno privilegi di funzionamento equivalenti all'utente root
Le utenze shutdown e admin non hanno una shell normale, ma avviano direttamente uno script: rispettivamente si tratta di /etc/script/SHUTDOWN e di /etc/script/ADMIN.
L'utenza shutdown, attraverso lo script /etc/script/SHUTDOWN, serve precisamente ad avviare il comando nanorc mirror shutdown, per spegnere gli elaboratori che sono previsti negli elenchi di quelli da sincronizzare; L'utenza admin, attraverso lo script /etc/script/ADMIN, serve a consentire a una persona diversa dall'amministratore vero e proprio di eseguire alcune operazioni utili, senza dare tutti i privilegi dell'utenza root.
Entrambe queste utenze possono funzionare solo se usate dalla console dell'elaboratore che svolge il compito di servente NIS, o almeno di router per la rete locale, pertanto il rischio di abusi e di errori dovrebbe essere limitato.
Molto probabilmente, soprattutto se si tratta di un laboratorio didattico, si può rendere pubblica la parola d'ordine da usare per l'utenza shutdown, in modo che chiunque possa spegnere le macchine della rete prevista, quando è il momento; per quanto riguarda invece l'utenza admin, questa è un po' più delicata e richiede un minimo di controllo (eventualmente si possono realizzare più utenze simili, che fanno capo sempre allo script /etc/script/ADMIN, in modo da poter attribuire a persone diverse una parola d'ordine distinta).
L'utenza admin, attraverso lo script /etc/script/ADMIN, porta automaticamente a un menù come quello che appare qui sotto:
|
Il significato delle voci del menù dovrebbe essere evidente. Si osservi in particolare la necessità di poter cambiare la parola d'ordine degli utenti che chiedono di farlo e di riallineare il NIS. In pratica, così come è organizzato, la gestione del NIS di nanoLinux non consente agli utenti di modificare la propria parola d'ordine autonomamente; pertanto, per questo occorre intervenire presso l'elaboratore in cui il servizio NIS viene gestito, attraverso i metodi tradizionali. Tuttavia, ciò richiede poi di aggiornare le tabelle del NIS di conseguenza. È per questo che si è resa necessaria la creazione di un'utenza riferita a una figura di amministratore con responsabilità limitata, perché altrimenti l'utilizzo della rete locale richiederebbe troppo spesso la presenza e l'intervento dell'amministratore vero e proprio.
Onde evitare inutili perdite di tempo, è bene rammentare che nelle reti con indirizzi privati è necessario evitare alcuni indirizzi di rete, che apparentemente sono innocui. La tabella seguente riepiloga le situazioni più comuni, tenendo conto delle maschere di rete predefinite.
Appunti di informatica libera 2004.10.10 --- Copyright © 2000-2004 Daniele Giacomini -- <daniele (ad) swlibero·org>, <daniele·giacomini (ad) poste·it>
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome nanolinux_la_rete.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione licenza] [translators] [docinfo] [indice analitico]
