https://www.amazon.it/dp/B0CT9YL557
SITEMAP
Make a donation: IBAN: IT36M0708677020000000008016 - BIC/SWIFT: ICRAITRRU60 - VALERIO DI STEFANO or
Privacy Policy Cookie Policy Terms and Conditions
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [violazione licenza] [translators] [docinfo] [indice analitico] [volume]
Capitolo 568. nanoLinux: la rete in dettaglio
Questo capitolo mostra varie situazioni per cui nanoLinux è predisposto, per quanto riguarda l'accesso a una rete (privata o pubblica).
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.
568.1 Connessione a un ISP
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 568.6. 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 o da DVD, tenendo conto che poi conviene salvare la configurazione in un disco o in una partizione.
568.2 Connessione in una rete locale
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 o da DVD).
|
Figura 568.7. 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.
568.3 Router per una 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 568.12. 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.
568.4 Router per una rete locale, attraverso un proxy
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 568.23. 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.
568.5 Condivisione delle utenze attraverso NIS e NFS
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 568.35. 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.
568.5.1 Gestione delle utenze
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:
nanorc user add|del |
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/2006 si crea l'utenza pippo e non si altera quanto viene proposto automaticamente, si ottiene la directory personale /home/20061231/pippo/.
L'utilizzo del comando nanorc user add ha anche il vantaggio di facilitare l'inserimento di più utenze, dal momento che alla fine di ogni inserimento ne viene proposto subito un altro (che comunque può essere annullato); inoltre, al termine degli inserimenti viene riallineato il NIS.
568.6 Servente DHCP
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 568.39. 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.
568.7 Sincronizzazione
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 568.42. 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 si 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 è innestata 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 innestata 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 568.46. 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 personali, 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/.
568.7.1 Sincronizzazione in pratica
Per comprendere meglio il meccanismo della sincronizzazione, si precisa meglio lo schema mostrato in precedenza, per descrivere come si può procedere.
|
Figura 568.47. 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 innestare, 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]
...
568.7.2 Controllo dell'utilizzo di unità di memorizzazione esterne
Il sistema di sincronizzazione di un gruppo di elaboratori si presta in modo particolare alla realizzazione di un laboratorio didattico. Un laboratorio didattico serve sia per le esercitazioni, sia per le verifiche (i compiti), durante le quali potrebbe essere necessario impedire l'uso di dischetti o di altre unità di memorizzazione agli utenti.
Se è stato organizzato il sistema di sincronizzazione, da uno qualsiasi degli elaboratori è possibile accedere in qualità di utente root e da lì, con il protocollo SECSH (ssh), senza altre autenticazioni, è possibile accedere agli altri elaboratori del gruppo. In base a questa possibilità è possibile predisporre degli script allo scopo di eseguire delle operazioni sistematiche, per modificare i permessi di accesso ad alcuni file di dispositivo (come /dev/fd0) e alla directory /mnt/. Lo script nanorc è già organizzato allo scopo.
Inizialmente è necessario stabilire il gruppo di elaboratori in cui si deve intervenire, specificando anche, per ogni elaboratore, su quali file di dispositivo occorre intervenire per bloccare gli accessi. Ovviamente, queste operazioni vanno svolte nell'elaboratore da cui si gestisce il sistema di sincronizzazione:
# nanorc storage clients[Invio]
Questo comando può essere usato solo dopo che è stata configurata la sincronizzazione degli elaboratori, come descritto in questo gruppo di sezioni. La prima volta che si esegue, si ottiene un elenco predefinito degli elaboratori già dichiarati per la sincronizzazione, con l'indicazione dei file di dispositivo secondo il modello /dev/fd0*:
|
Supponendo di voler controllare anche l'accesso a una memoria esterna USB, corrispondente ai file di dispositivo /dev/sd*, si potrebbe modificare l'elenco in modo appropriato:
|
Nell'esempio vengono riprodotti gli stessi modelli di file di dispositivo per ogni elaboratore, ma non è detto che debba sempre essere così; quello che conta è usare la barra verticale (|) per separare le componenti dell'elenco.
Una volta utilizzato la prima volta il comando nanorc storage clients, se si cambia l'elenco degli elaboratori da sincronizzare, la modifica non si trasmette a questa configurazione; se si desidera ricominciare con i valori predefiniti, occorre cancellare il file /etc/nanoLinux/STORAGE_CLIENTS_LIST.
Quando l'elenco è pronto, ammesso che il sistema di sincronizzazione funzioni già in modo corretto (tale da consentire l'avvio di comandi remoti senza bisogno di autenticazione), si può usare il comando seguente per passare al controllo dell'accesso alle unità di memorizzazione esterne. Si osservi che gli elaboratori coinvolti devono essere accesi e collegati, per poter recepire i comandi:
# nanorc storage access[Invio]
|
Le prime due voci sono costanti, le altre dipendono dall'elenco inserito in precedenza. Selezionando la voce ALLOW_ALL si ottiene di attivare tutte le voci previste, mentre DENY_ALL le disattiva tutte. Queste due voci iniziali servono solo per azzerare velocemente l'elenco e la loro selezione, fa sì che confermando la richiesta si ripresenti l'elenco, senza eseguire subito l'azione richiesta; pertanto, solo quando le prime due voci dell'elenco sono deselezionate si prende in considerazione la scelta di quelle sottostanti e viene aggiornata la configurazione.
Una volta Selezionati i nodi, a quei nodi vengono inviati i comandi per consentire l'accesso ai file di dispositivo elencati e alla directory /mnt/, mentre agli altri nodi, vengono inviati i comandi per togliere gli accessi agli utenti comuni. Nell'esempio seguente di selezione, si fa in modo che solo i nodi 172.21.1.1 e 172.21.3.1 possano accedere alle unità di memorizzazione esterne:
|
568.8 Accesso limitato ai servizi
L'accesso ad alcuni servizi può essere limitato, attraverso il menù di nanorc.
La configurazione di una stampante comporta inizialmente che questa venga resa accessibile a chiunque, senza limitazioni, mentre la configurazione di una stampante remota coincide con la chiusura dell'accesso a chiunque, salvo ai programmi locali. Per modificare questo sistema di massima, occorre procedere con due comandi di nanorc:
# nanorc printer clients[Invio]
Per prima cosa occorre dichiarare quali sono i nodi da cui è prevista la possibilità di accedere al proprio servizio di stampa (locale o remoto che sia). In pratica, in questo elenco vanno inseriti gli indirizzi IPv4 di chi, per qualche ragione, deve avere la possibilità di stampare. Un elenco del genere potrebbe avere significato:
|
Come si vede, si possono indicare anche gruppi di nodi, specificando una maschera di rete; tuttavia, è bene che non si creino sovrapposizioni, altrimenti diventa poi difficile gestire il controllo dei permessi di accesso.
Supponendo di avere inserito esattamente l'elenco che si vede nell'esempio, dopo, con un altro comando di nanorc, è possibili stabilire chi può accedere tra questi:
# nanorc printer access[Invio]
|
Le prime due voci sono costanti, le altre dipendono dall'elenco inserito in precedenza. Selezionando la voce ALLOW_ALL si ottiene di attivare tutte le voci previste, mentre DENY_ALL le disattiva tutte. Queste due voci iniziali servono solo per azzerare velocemente l'elenco e la loro selezione, fa sì che confermando la richiesta si ripresenti l'elenco, senza eseguire subito l'azione richiesta; pertanto, solo quando le prime due voci dell'elenco sono deselezionate si prende in considerazione la scelta di quelle sottostanti e viene aggiornata la configurazione.
Supponendo di abilitare l'accesso al gruppo costituito dagli indirizzi 172.21.2.*, si può osservare cosa succede se si riavvia il comando la volta successiva:
|
Al riavvio del comando, le voci che in precedenza erano state selezionate, appaiono all'inizio dell'elenco, così da non doverle cercare.
|
Dal punto di vista del risultato, quello che conta è l'elenco dei punti a cui è concesso accedere. Se nell'elenco sono state fatte delle duplicazioni, per esempio se appare il nodo 172.21.2.33 e anche 172.21.2.0/255.255.255.0, bloccando l'accesso solo al gruppo 172.21.2.*, attraverso la voce 172.21.2.0/255.255.255.0, non serve a bloccare anche 172.21.2.33. Naturalmente può darsi che questo sia ciò che si vuole; quello che conta è capire la logica. |
Così come per l'accesso alla stampante, è possibile limitare l'accesso al proxy HTTP. Naturalmente, ciò ha senso soltanto se tale configurazione avviene in un elaboratore che svolge il ruolo di router per l'accesso all'esterno, ponendosi come un passaggio obbligato. Questo sistema serve in pratica per poter controllare chi, nella propria rete locale, può accedere ai servizi HTTP esterni, dato che di norma si fa intervenire il proxy HTTP in modo trasparente (senza bisogno che i programmi di navigazione debbano essere configurati per il suo utilizzo).
# nanorc proxy clients[Invio]
Come già visto in precedenza, si inizia stabilendo l'elenco di nodi che si possono avvalere potenzialmente del proxy HTTP. Si usa la stessa notazione valida per il controllo del servizio di stampa; eventualmente la maschera di rete può essere annotata in modo abbreviato:
|
Valgono le stesse raccomandazioni di non creare sovrapposizioni, a meno di sapere quel che si sta facendo, considerato che ciò che conta, poi, sono le voci che risultano abilitate. Successivamente, si può passare al controllo effettivo:
# nanorc proxy access[Invio]
|
Il meccanismo è lo stesso già descritto per il controllo dell'accesso alla stampante, ma si attua attraverso Iptables, pertanto il kernel deve disporre delle funzionalità necessarie (come di solito ha se si usa quello della distribuzione normale).
568.9 Amministrazione a responsabilità limitata
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. Eventualmente l'utenza admin può essere usata anche negli elaboratori che non hanno funzioni particolari, ma in tal caso sono disponibili funzionalità più limitate.
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.
568.10 Indirizzi di rete da evitare assolutamente
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 2006.01.01 --- Copyright © 2000-2006 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_in_dettaglio.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [violazione licenza] [translators] [docinfo] [indice analitico]
aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -
Static Wikipedia 2007 (no images)
aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -
Static Wikipedia 2006 (no images)
aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -
Sub-domains
CDRoms - Magnatune - Librivox - Liber Liber - Encyclopaedia Britannica - Project Gutenberg - Wikipedia 2008 - Wikipedia 2007 - Wikipedia 2006 -
Other Domains
https://www.classicistranieri.it - https://www.ebooksgratis.com - https://www.gutenbergaustralia.com - https://www.englishwikipedia.com - https://www.wikipediazim.com - https://www.wikisourcezim.com - https://www.projectgutenberg.net - https://www.projectgutenberg.es - https://www.radioascolto.com - https://www.debitoformtivo.it - https://www.wikipediaforschools.org - https://www.projectgutenbergzim.com