[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
Il NIS, (1) (2) (3) o Network information service, è un sistema di gestione di dati amministrativi concentrati in una sola fonte, rendendoli disponibili a tutta una rete in modo uniforme.
Questo tipo di servizio è stato ideato e sviluppato originariamente dalla Sun Microsystems denominandolo Yellow pages (YP), ma successivamente il nome è stato cambiato perché questo era già un marchio registrato in Gran Bretagna della società telefonica British Telecom. Questa storia di NIS serve a spiegare il motivo per il quale molti programmi di servizio che riguardano questa gestione hanno il prefisso yp, oltre al fatto che spesso si parli di «servizi YP» invece che di «servizi NIS».
Il NIS è un meccanismo che si sovrappone alla gestione amministrativa di un sistema Unix tipico, ma questo avviene in un modo non perfettamente integrato. Quando si introduce il NIS, si inserisce un livello di intermediazione tra l'utente e il sistema di amministratore preesistente.
Lo scopo del NIS è quello di concentrare in un solo elaboratore la gestione di una serie di file amministrativi. La tabella 138.1 elenca alcuni file di configurazione, tipici di un sistema Unix, che possono essere gestiti in questo modo.
Tabella 138.1. Elenco di alcuni dei file amministrativi gestibili comunemente attraverso il NIS.
La concentrazione amministrativa si attua facendo in modo che le informazioni dei file che interessano siano gestite a partire da un solo nodo. Generalmente, l'utilità del NIS sta nella possibilità di amministrare gli utenti da un'unica origine, facendo in modo che questi vengano riconosciuti in tutti gli elaboratori di un certo «dominio», senza dover essere inseriti effettivamente in ognuno di questi.
Gli esempi che si faranno in questo capitolo sono volti principalmente al raggiungimento di questo risultato, concentrando così l'amministrazione dei file /etc/passwd, /etc/group e /etc/shadow.
Il NIS non utilizza i file amministrativi così come sono, ne crea una copia; queste copie sono denominate «mappe». I file di mappa sono in formato DBM, dove si memorizzano solo coppie di dati: chiave-valore. Per questo motivo, a seconda della struttura dei file amministrativi originali, si possono generare più mappe differenti.
Quando si attiva il NIS, non si possono più utilizzare i vecchi comandi amministrativi (come passwd, chsh, ecc.), o quantomeno non conviene, perché il NIS non si accorge (autonomamente) dei cambiamenti apportati ai file amministrativi tradizionali. Bisogna utilizzare i comandi specifici del NIS, in modo che i cambiamenti siano annotati immediatamente nelle mappe e poi siano propagati nei file amministrativi normali del servente NIS.
La tabella 138.2 riporta l'elenco di alcune delle mappe tipiche della gestione NIS. La collocazione di questi file dipende dal dominio NIS, descritto nella sezione seguente, e corrisponde in pratica a /var/yp/dominio_nis/.
Tabella 138.2. Elenco di alcune mappe NIS.
Quando si attiva un servizio NIS in un nodo, in modo che questo renda disponibili le informazioni relative a un gruppo di elaboratori, si deve definire un dominio NIS corrispondente. Questo non ha niente a che fare con i domini utilizzati dal servizio DNS, ma generalmente, anche se potrebbe sovrapporsi perfettamente a un dominio di questo tipo, conviene utilizzare nomi distinti, che non abbiano un nesso logico o intuitivo.
Più precisamente, è meglio dire che si stabilisce prima l'estensione del dominio NIS che si vuole creare, quindi si deve «eleggere» il nodo più adatto a fungere da servente NIS. Infatti, questo elaboratore deve trovarsi in una posizione adatta nella rete, in modo che sia accessibile facilmente da tutti gli elaboratori del dominio NIS. Oltre a questo è bene che si tratti di una macchina adeguata all'estensione del dominio: maggiore è il numero di clienti, maggiore sarà la frequenza con cui dovrà rispondere a richieste del protocollo NIS.
I file di mappa di un servente NIS sono raggruppati distintamente per dominio, nella directory /var/yp/dominio_nis/.
Finora si è fatto riferimento a un servente NIS unico per tutto il suo dominio di competenza. Quando si attiva un servizio di questo tipo, tutti gli elaboratori clienti di questo dominio dipendono completamente dal servente per tutte quelle informazioni che sono state concentrate sotto la sua amministrazione. Se l'elaboratore che offre questo servizio dovesse venire a mancare per qualsiasi motivo, come un guasto, tutti i suoi clienti sarebbero in grave difficoltà.
Per risolvere il problema, si possono predisporre dei serventi NIS secondari, o slave, che riproducono le informazioni del servente principale, o master.
La presenza di serventi secondari impone la creazione di meccanismi automatici per il loro allineamento, generalmente attraverso il sistema Cron.
Finora è stato preso in considerazione il compito del servente NIS, senza valutare i clienti, ma all'inizio la distinzione dei compiti può sembrare confusa.
Il cliente NIS è un programma demone che si occupa di fornire al sistema in cui è in funzione le informazioni che altrimenti verrebbero ottenute dai soliti file di configurazione. La situazione tipica è quella della procedura di accesso: se il nome dell'utente non viene trovato nel file /etc/passwd locale, il cliente NIS cerca di ottenerlo dal servente NIS.
In pratica, le funzionalità di servente e cliente sono indipendenti: ci possono essere elaboratori che fungono da serventi, altri che utilizzano il programma cliente per accedere alle informazioni e altri ancora che fanno entrambe le cose.
Se si pensa che il servente NIS principale deve contenere tutte le informazioni che vengono condivise dai programmi clienti presso gli altri elaboratori, potrebbe sembrare inutile l'attivazione del programma cliente nello stesso servente. Tuttavia, le cose cambiano quando si considerano i serventi secondari. Questi non dispongono delle informazioni che ha l'elaboratore corrispondente al servente principale; per ottenerle occorre attivare il cliente NIS in modo che si possa mettere in comunicazione con il servente principale.
Nel sistema NIS così strutturato, i clienti cercano le informazioni, riferite al loro dominio, dal servente che risponde più rapidamente. Ciò viene determinato generalmente attraverso una richiesta circolare (broadcast). Questo, tra le altre cose, è uno dei punti deboli del NIS: dal momento che qualunque elaboratore può rispondere a una chiamata circolare, chiunque è in grado di intromettersi per cercare di catturare delle informazioni.
Quando si deve intervenire per modificare qualche informazione di quelle che sono condivise attraverso il NIS, si presentano situazioni differenti a seconda delle circostanze. Queste si traducono in modalità diverse di propagazione di queste modifiche nell'intero sistema NIS. Si distinguono due situazioni fondamentali:
la modifica di un'informazione nell'elaboratore di origine (il servente principale) sui dati di partenza;
la modifica di un'informazione attraverso gli strumenti offerti dal sistema NIS.
Nel primo caso le azioni da compiere sono:
Nel secondo caso le azioni da compiere sono:
Quando si interviene manualmente sui file di configurazione di partenza del servente principale, per esempio quando si vuole aggiungere o eliminare un utente, si deve poi comandare manualmente l'aggiornamento delle mappe NIS; eventualmente si può pilotare anche l'aggiornamento dei serventi secondari, attraverso un cosiddetto push.
Quando si utilizzano gli strumenti offerti da NIS per modificare la configurazione dei dati condivisi, ciò può avvenire solo attraverso un cliente, il quale si occupa di contattare il servente principale che poi deve provvedere ad aggiornare i file normali e le mappe.
La propagazione delle mappe modificate ai serventi secondari potrebbe essere un problema. Per questo si utilizza generalmente il sistema Cron in ogni servente secondario, in modo da avviare periodicamente il comando necessario a metterli in comunicazione con il servente principale e verificare così la presenza di aggiornamenti eventuali.
Dalla precisione del funzionamento di questo sistema di propagazione derivano delle conseguenze pratiche che, a prima vista, possono sembrare assurde. Si può immaginare cosa può accadere quando un utente cambia la propria parola d'ordine da un cliente NIS. Questo contatta il servente principale che provvede ad aggiornare le mappe e il file /etc/passwd. Ma fino a che i serventi secondari non ricevono l'aggiornamento, i clienti che li utilizzano continuano a permettere l'accesso con la parola d'ordine vecchia. Questo può capitare allo stesso elaboratore dal quale è stata compiuta l'operazione di modifica, se questo utilizza il servizio di un servente secondario non aggiornato. In queste condizioni, l'utente che ha appena cambiato parola d'ordine e tenta un altro accesso sulla stessa macchina, potrebbe trovarsi spaesato di fronte al rifiuto che gli si presenta.
Il NIS permette di distribuire le informazioni contenute nei file /etc/hosts e /etc/networks. Questi sono i file di configurazione che permettono di risolvere i nomi dei nodi della rete locale, quando non si vuole fare uso di un DNS.
Attraverso questa possibilità è poi possibile configurare il file /etc/host.conf dei vari clienti NIS, in modo che venga utilizzata questa informazione. Di solito si tratta di indicare una riga come quella seguente:
order hosts,nis |
Tuttavia, nel momento stesso in cui si pensa di volere utilizzare il NIS, si decide che l'organizzazione della rete locale è un problema serio, pertanto, anche la risoluzione dei nomi della rete deve essere considerato un problema ugualmente serio. In questo senso, diventa un controsenso la pretesa di gestire la risoluzione dei nomi attraverso NIS, quando con poco impegno si può attivare un servente DNS; al limite si possono unire le due cose:
order hosts,bind,nis |
Il NIS utilizza le chiamate RPC per comunicare. Questo significa che è necessaria la presenza del Portmapper in funzione sia nei nodi serventi che nei nodi clienti (si veda eventualmente il capitolo 136).
È anche importante verificare che i servizi di sincronizzazione, time service, siano previsti nel controllo del supervisore dei servizi di rete. Il file /etc/inetd.conf potrebbe contenere le righe seguenti:
# # Time service is used for clock syncronization. # time stream tcp nowait root internal time dgram udp wait root internal |
In alternativa, il file /etc/xinetd.conf potrebbe contenere invece le righe seguenti:
service time
{
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = time-stream
}
service time
{
socket_type = dgram
protocol = udp
wait = yes
user = root
type = INTERNAL
id = time-dgram
}
|
Se si devono apportare delle modifiche al file di configurazione del supervisore dei servizi di rete, bisogna poi ricordarsi di riavviarlo (capitolo 135).
Gli elementi indispensabili di un servente NIS sono i programmi ypserv e makedbm. Il primo svolge il ruolo di demone in ascolto delle richieste NIS per il dominio di competenza, il secondo è necessario per convertire i file di configurazione normali in file DBM, cioè nelle mappe NIS.
Nel caso di un servente principale è anche opportuna la presenza di altri due demoni: rpc.yppasswdd e rpc.ypxfrd. Il primo serve a permettere la modifica delle parole d'ordine degli utenti attraverso il sistema NIS, il secondo serve a facilitare l'aggiornamento ai serventi secondari.
La configurazione di ypserv e rpc.ypxfrd può dipendere dal modo in cui sono stati compilati i sorgenti rispettivi. In generale si utilizza il file /etc/ypserv.conf per definire il comportamento di entrambi i programmi; inoltre ypserv può far uso di /etc/ypserv.securenets per conoscere gli indirizzi di rete da cui può accettare interrogazioni NIS, oppure può riutilizzare i tradizionali /etc/hosts.allow e /etc/hosts.deny. Per saperlo basta usare l'opzione -version, come nell'esempio seguente:
# ypserv -version[Invio]
ypserv - NYS YP Server version 1.1.7 (with tcp wrapper) |
L'esempio mostra il risultato di un ypserv compilato con il supporto per l'utilizzo dei file /etc/hosts.allow e /etc/hosts.deny, gli stessi che utilizza il TCP wrapper allo scopo di filtrare gli accessi ai programmi controllati dal supervisore dei servizi di rete.
ypserv - NYS YP Server version 1.3.12 (with securenets) |
Questo esempio ulteriore riguarda invece il risultato di un ypserv compilato con il supporto per l'uso di /etc/ypserv.securenets (o di un file analogo collocato in una posizione diversa nel file system.
Il dominio NIS viene definito attraverso domainname, nel modo seguente:
domainname dominio_nis
Quando viene usato senza argomenti, si ottiene il nome del dominio NIS; in questo modo si può controllare se l'impostazione è corretta. Per esempio, l'impostazione del dominio NIS rost.nis-yp può essere fatta e controllata nel modo seguente:
# domainname rost.nis-yp[Invio]
# domainname[Invio]
rost.nis-yp
Mentre l'impostazione del dominio è di competenza dell'utente root, la verifica può essere fatta anche da un utente comune.
Di solito, si può fare riferimento a questo programma anche con altri nomi:
domainname [opzioni] [dominio_nis]
nisdomainname [opzioni] [dominio_nis]
ypdomainname [opzioni] [dominio_nis]
L'utilizzo tipico di domainname è riservato agli script della procedura di inizializzazione del sistema. Le istruzioni necessarie potrebbero essere organizzate nel modo seguente:
# Set the NIS domain name
if [ -n "$NISDOMAIN" ]
then
domainname $NISDOMAIN
else
domainname ""
fi
|
Oppure in modo alternativo anche come segue, dove il nome del dominio è contenuto in un file. In tal caso, bisogna fare attenzione al fatto che il file in questione deve essere composto esclusivamente da una riga, altrimenti viene presa in considerazione solo l'ultima, ma se questa è vuota, il dominio non viene definito.
# Set the NIS domain name
if [ -f "/etc/nisdomain" ]
then
domainname -F /etc/nisdomain
else
domainname ""
fi
|
In condizioni normali, ypserv non richiede l'uso di argomenti particolari, al massimo si tratta di controllare il file di configurazione /etc/ypserv.conf e l'eventuale /etc/ypserv.securenets (prima si deve verificare con l'opzione -v se questo file è necessario, o se al suo posto si usano i file di configurazione del TCP wrapper). In ogni caso, è importante che la directory /var/yp/ sia stata creata (al suo interno si dovrebbe trovare un file-make, ma questo verrà mostrato in seguito).
# ypserv[Invio]
Se tutto va bene, il programma si avvia sullo sfondo e si disassocia dalla shell, diventando un processo figlio di quello iniziale (Init).
# pstree[Invio]
init-+-...
|-portmap
|-...
`-ypserv
|
Se il Portmapper RPC non fosse attivo, oppure se non fosse stato definito il dominio NIS, l'avvio di ypserv non dovrebbe riuscire. Eventualmente, si può verificare il funzionamento del Portmapper stesso, attraverso il comando seguente:
# rpcinfo -p localhost[Invio]
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
|
Le righe che si vedono dall'esempio mostrato sono la dichiarazione esplicita del funzionamento del Portmapper. Per verificare espressamente la connessione con ypserv, si può usare il comando seguente:
# rpcinfo -u localhost ypserv[Invio]
program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting |
La sintassi per l'avvio di ypserv è molto semplice:
ypserv [opzioni]
L'elenco seguente descrive alcune opzioni della riga di comando di ypserv che possono essere utili.
ypserv, quando tutto è configurato correttamente, viene controllato dalla procedura di inizializzazione del sistema, attraverso uno dei suoi script. L'esempio che segue rappresenta un modo semplice per ottenere questo, dove la variabile di ambiente NISDOMAIN viene usata per contenere il dominio NIS; se manca questa variabile non ha senso avviare il servente NIS.
if [ -n "$NISDOMAIN" ]
then
if [ -f /usr/sbin/ypserv ]
then
/usr/sbin/ypserv
echo ypserv
fi
fi
|
Quello mostrato è solo uno dei tanti modi; in generale bisogna ricordare che si può avviare il servizio NIS solo dopo aver avviato il Portmapper.
Nelle distribuzioni più accurate, è normale trovare uno script apposito che permette di avviare e di interrompere l'attività del servente NIS, assieme a tutto quello di cui potrebbe avere bisogno. Questo genere di script può trovarsi nelle directory /etc/rc.d/init.d/, /etc/init.d/ e altre possibili.
La configurazione di /etc/ypserv.conf riguarda il funzionamento di ypserv e rpc.ypxfrd in ogni caso. quando si fanno dei cambiamenti a questa configurazione occorre riavviare i demoni o inviare loro un segnale SIGHUP.
L'impostazione di questo file può essere anche molto complicata. In linea di massima ci si può fidare della configurazione predefinita, o dei suggerimenti posti nei suoi commenti.
Il file può contenere commenti, rappresentati inizialmente dal simbolo #, righe vuote o bianche, direttive riferite a opzioni e direttive riferite a regole di accesso. Le direttive di opzione hanno la forma seguente, dove la parola chiave yes attiva l'opzione, mentre no la disattiva.
opzione:[yes|no]
L'elenco seguente descrive tali opzioni.
Le direttive di accesso hanno invece il formato seguente:
host:mappa:livello_sicurezza:soppressione[:campo]
host
Si tratta di un indirizzo IP che può rappresentare un solo nodo o un gruppo. La rappresentazione può essere fatta attraverso un indirizzo IP incompleto, o la coppia indirizzo/maschera. Un indirizzo IP incompleto rappresenta tutti gli indirizzi che iniziano in quel modo, per cui, per esempio, «192.168.» equivale alla notazione 192.168.0.0/255.255.0.0, dove il secondo indirizzo è la maschera.
mappa
Il nome della mappa, oppure un asterisco per identificare tutte le mappe.
livello_sicurezza
Il livello, o il tipo di sicurezza, viene definito attraverso una parola chiave: none, port, deny, des. Il loro significato viene descritto di seguito.
| none | Concede qualunque accesso. |
| port | Permette di accedere se la richiesta viene da una porta inferiore al numero 1 024, ma solo se è stata specificata la soppressione. |
| deny | Vieta l'accesso alla mappa in questione. |
| des | Richiede l'autenticazione DES. Può funzionare solo se le librerie utilizzate sono in grado di gestire questa funzionalità. |
soppressione
Può contenere solo una tra le parole chiave yes e no. yes attiva la soppressione del campo specificato. La soppressione implica che al suo posto viene collocata una «x», se il controllo della porta rivela che la richiesta proviene da un accesso non privilegiato.
campo
Serve a specificare quale campo deve essere soppresso. Quello predefinito è il secondo.
L'esempio seguente rappresenta una configurazione predefinita di una distribuzione GNU:
# The following, when uncommented, will give you shadow like passwords. # Note that it will not work if you have slave NIS servers in your # network that do not run the same server as you. # Host : Map : Security : Passwd_mangle # # * : passwd.byname : port : yes # * : passwd.byuid : port : yes # * : * : none # This is the default - restrict access to the shadow password file, # allow access to all others. * : shadow.byname : port * : passwd.adjunct.byname : port * : * : none |
Il file /var/yp/securenets viene usato da ypserv per sapere quali sono gli indirizzi ammessi a eseguire interrogazioni nel sistema NIS. Bisogna ricordare che ypserv potrebbe essere stato compilato per non usare questo file, utilizzando al suo posto /etc/hosts.allow e /etc/hosts.deny. Questo lo si determina utilizzando l'opzione -v.
Nel caso in cui ypserv utilizzi questo file, se manca o è vuoto, vengono consentiti tutti gli accessi in modo indiscriminato. Ogni volta che si modifica il file è necessario riavviare ypserv, oppure gli si deve inviare un segnale SIGHUP.
A parte i commenti, rappresentati dalle righe che iniziano con il simbolo #, e le righe vuote, questo file è fatto principalmente per annotare coppie di indirizzi IP, dove il primo è la maschera e il secondo l'indirizzo della rete a cui si vuole concedere l'accesso. L'esempio seguente è simile a quello che si trova nella pagina di manuale ypserv(8) e dovrebbe essere sufficiente a comprendere il meccanismo.
# Consente le connessioni dallo stesso elaboratore locale (è necessario) # Equivale a 255.255.255.255 127.0.0.1 # host 127.0.0.1 # # # Permette le connessioni da tutti gli elaboratori della rete locale # 192.168.1.0 # 255.255.255.0 192.168.1.0 |
Anche se potrebbe essere inutile, se il proprio sistema utilizza i file /etc/hosts.allow e /etc/hosts.deny, è bene occuparsi della loro configurazione anche per ciò che potrebbe riguardare il NIS. Quelle che seguono sono le direttive che potrebbero essere inserite in /etc/hosts.allow:
portmap: specifica_dei_nodi ypserv: specifica_dei_nodi ypbind: specifica_dei_nodi yppasswd: specifica_dei_nodi |
Per converso, può essere conveniente inserire le righe seguenti nel file /etc/hosts.deny, allo scopo di escludere gli accessi che non provengano dai nodi autorizzati espressamente:
portmap: ALL ypserv: ALL ypbind: ALL yppasswd: ALL |
Naturalmente, per una sicurezza maggiore, può essere conveniente inserire soltanto la direttiva seguente nel file /etc/hosts.deny:
ALL: ALL |
Le mappe NIS, come già accennato, sono collocate nella directory /var/yp/dominio_nis/. I file delle mappe esistenti, per il solo fatto di esserci, definiscono implicitamente quali sono i dati amministrativi che vengono gestiti in quel dominio NIS particolare. La loro creazione e il loro aggiornamento, avvengono attraverso un file-make che si trova nella directory /var/yp/ e che generalmente viene utilizzato attraverso uno script. Il problema, semmai, sta nella necessità eventuale di modificare tale file-make per definire quali mappe debbano essere costruite.
In generale è indispensabile la lettura di questo file, per verificare come sono le impostazioni attuali. Si noteranno certamente molti commenti che spiegano il significato delle direttive che vengono date (può trattarsi di assegnamenti a variabili che poi sono riutilizzate nel file-make stesso). È molto importante osservare bene la conformazione dell'obiettivo all; nell'esempio seguente, questo obiettivo richiede probabilmente la modifica manuale per includere le mappe che si intendono gestire, secondo l'esempio commentato che lo precede:
#all ethers hosts networks protocols rpc services passwd group shadow \ # passwd.adjunct netid netgrp publickey mail timezone locale netmasks all: passwd group shadow ypservers |
L'esempio successivo mostra invece un obiettivo all controllato da una variabile, dove proprio le mappe per la gestione del file /etc/shadow sono controllate in modo automatico, in base alla presenza del file stesso:
# If you don't want some of these maps built, feel free to comment # them out from this list. ALL = passwd group hosts rpc services netid protocols netgrp networks #ALL += publickey mail ethers bootparams printcap #ALL += amd.home auto.master auto.home auto.local #ALL += timezone locale netmasks # Autodetect /etc/shadow if it's there ifneq ($(wildcard $(SHADOW)),) ALL += shadow endif # Autodetect /etc/passwd.adjunct if it's there ifneq ($(wildcard $(ADJUNCT)),) ALL += passwd.adjunct endif all: $(ALL) |
In questo file-make esiste comunque un'altra cosa molto importante da controllare:
# If we have only one server, we don't have to push the maps to the # slave servers (NOPUSH=true). If you have slave servers, change this # to "NOPUSH=false" and put all hostnames of your slave servers in the file # /var/yp/ypservers. NOPUSH=true |
Nella prima parte viene definito, attraverso una variabile, se il servente deve occuparsi di spedire gli aggiornamenti (push) ai serventi secondari. In questo caso, commentando l'assegnamento della variabile NOPUSH si ottiene di mantenere attivo questo aggiornamento.(4)
Una volta predisposto il file-make, si può usare il programma make, senza argomenti, oppure si può utilizzare un comando specifico (è la scelta più elegante, mentre make è la scelta più semplice quando si raggiunge una certa dimestichezza con il sistema).
# /usr/lib/yp/ypinit -m
Il vero vantaggio nell'utilizzo di questo programma (che poi è in realtà uno script), sta nel fatto che provvede a costruire al volo il file /var/yp/servers, con l'elenco dei serventi competenti per il dominio che si sta predisponendo.
At this point, we have to construct a list of the hosts which will run NIS
servers. dinkel.brot.dg is in the list of NIS server hosts.
Please continue to add the names for the other hosts, one per line.
When you are done with the list, type a <control D>.
next host to add: dinkel.brot.dg
next host to add:
Questa operazione va condotta dall'elaboratore che deve svolgere il ruolo di servente principale, di conseguenza, il suo indirizzo deve apparire per primo. Supponendo di avere un secondo elaboratore da utilizzare come servente secondario, si può aggiungere il suo nome e quindi terminare con la combinazione [Ctrl+d].
next host to add: roggen.brot.dg[Invio]
next host to add: [Ctrl+d]
The current list of NIS servers looks like this: dinkel.brot.dg roggen.brot.dg Is this correct? [y/n: y]
[Invio]
We need some minutes to build the databases... Building /var/yp/rost.nis-yp/ypservers... Running /var/yp/Makefile... NIS Map update started on Thu Jul 25 12:00:00 CEST 2002 make[1]: Entering directory `/var/yp/rost.nis-yp' Updating passwd.byname... Updating passwd.byuid... Updating group.byname... Updating group.bygid... Updating shadow.byname... make[1]: Leaving directory `/var/yp/rost.nis-yp' NIS Map update completed.
Questo è il tipo di risultato che si può osservare quando tutto procede regolarmente. Se non si utilizza lo script ypinit, si salta la predisposizione del file /var/yp/rost.nis-yp/ypservers, che però potrebbe essere già stato ottenuto da un'esecuzione precedente di ypinit. In pratica, lo script ypinit va utilizzato convenientemente la prima volta che si allestisce il servente, mentre le altre volte è sufficiente utilizzare solo make dalla directory /var/yp/:
# cd /var/yp[Invio]
# make[Invio]
Perché gli utenti del servizio NIS possano modificare la propria parola d'ordine di accesso, è necessario che nel servente principale sia in funzione il demone rpc.yppasswdd:
rpc.yppasswdd [opzioni]
Le opzioni disponibili dipendono molto dalla versione di questo programma e dal modo con cui è stato compilato. È da questo programma che dipende anche la possibilità o meno di utilizzare ypchsh e ypchfn. In generale, utilizzandolo senza opzioni particolari, è possibile solo la modifica delle parole d'ordine.
I serventi secondari, ammesso che se ne vogliano avere, devono poter comunicare con il servente principale, ma naturalmente ciò richiede implicitamente che questi, oltre che serventi secondari, siano anche dei clienti. Più avanti verrà spiegato come predisporre un cliente NIS; per il momento è bene affrontare ugualmente il problema, per mantenere mentalmente il collegamento con quanto già trattato sul servente principale.
Un servente secondario richiede le stesse cose del servente principale, a eccezione del demone rpc.yppasswdd che nel servente secondario non ha ragione di esistere. Questo significa che:
si deve impostare il dominio NIS;
si deve configurare ypserv attraverso /etc/ypserv.conf e /etc/ypserv.securenets, oppure gli altri file del TCP wrapper.
Si è già accennato al fatto che il servente secondario deve avere il cliente NIS in funzione, ma la differenza più interessante sta nell'assenza del file-make nella directory /var/yp/. Naturalmente, il file-make può anche esserci, ma non deve essere preso in considerazione.
Anche il servente secondario, per poter compiere il suo lavoro, deve disporre delle mappe NIS. Queste vengono create, copiandole dal servente principale, attraverso il comando seguente:
/usr/lib/yp/ypinit -s servente_nis_principale
In pratica, si avvia ypinit con l'opzione -s, indicando il nome dell'elaboratore che ospita il servente principale. Per esempio, se il servente principale è dinkel.brot.dg, il comando corretto è il seguente:
# /usr/lib/yp/ypinit -s dinkel.brot.dg
Perché l'operazione funzioni correttamente, occorre che il cliente NIS sottostante sia configurato e funzionante. In pratica, prima di utilizzare ypinit, si può verificare che sia tutto in ordine con il comando seguente:
# ypwhich -m
Questo deve restituire il nome del servente principale.
La presenza di serventi secondari introduce nel sistema NIS dei problemi di sincronizzazione di questi con il servente principale. Oltre a tutto, lo stesso procedimento di sincronizzazione accresce i problemi di sicurezza, dal momento che periodicamente viaggiano informazioni delicate nella rete.
Ci sono tre modi per sincronizzare i serventi secondari, ma non tutti funzionano sempre, a causa degli accorgimenti utilizzati per ridurre i problemi di sicurezza.
Quando il servente principale viene aggiornato, dovrebbe essere in grado di inviare ai serventi secondari le modifiche alle mappe (push). Questa operazione non funziona se i serventi secondari non sono in ascolto in quel momento, inoltre non funziona anche in altre circostanze, sempre per motivi di sicurezza.
I serventi secondari possono comunicare periodicamente con il servente principale per verificare la presenza di aggiornamenti delle mappe. Questa operazione richiede nel servente principale la presenza in funzione del demone rpc.ypxfrd.
In ultima analisi, i serventi secondari si aggiornano con il comando ypinit -s servente_principale.
Per quanto riguarda il secondo punto, il NIS offre generalmente tre script predisposti opportunamente per eseguire i compiti di aggiornamento. Si tratta di: ypxfr_1perhour, ypxfr_1perday e ypxfr_2perday. Questi si trovano nella directory /usr/lib/yp/ e sono pensati per essere inclusi in un file crontab, come nell'esempio seguente che rappresenta precisamente il file /etc/crontab.
20 * * * * root /usr/lib/yp/ypxfr_1perhour 40 6 * * * root /usr/lib/yp/ypxfr_1perday 55 6,18 * * * root /usr/lib/yp/ypxfr_2perday |
I diversi script si occupano di trasferire mappe differenti. In particolare, quello eseguito ogni ora è predisposto per trasferire le informazioni sugli utenti (la cosa più urgente).
Dal momento che non si può fare affidamento sul sistema di aggiornamento pilotato dal servente principale (quello del primo punto), se per qualche motivo l'aggiornamento a mezzo di ypxfr non funziona, occorre ripiegare necessariamente sull'uso periodico di ypinit -s, eventualmente collocando anch'esso in un file crontab.
Come già accennato, il demone rpc.ypxfrd viene utilizzato solo nel servente principale per facilitare l'aggiornamento delle mappe nei serventi secondari. La sua presenza non è indispensabile, ma è utile per accelerare il processo di aggiornamento.
rpc.ypxfrd [opzioni]
Generalmente può essere utilizzato senza argomenti e dovrebbe essere gestito direttamente dalla procedura di inizializzazione del sistema.
Quando la propria distribuzione GNU è ben organizzata, non è necessario intervenire direttamente nel file /var/yp/Makefile; inoltre, è normale che siano già predisposti correttamente gli script per il controllo del NIS attraverso la procedura di inizializzazione del sistema.
Nel caso particolare delle distribuzioni Debian, lo script della procedura di inizializzazione del sistema che controlla il NIS è /etc/init.d/nis. Questo script, a sua volta, utilizza le indicazioni contenute nel file /etc/default/nis per sapere se deve essere attivato un servizio NIS come servente principale, secondario, o come cliente. Nell'esempio seguente si intende allestire un servente principale, in cui i file contenenti le parole d'ordine si trovano nella directory /etc/ (come avviene di solito), che consente la modifica remota della shell:
# # /etc/default/nis Configuration settings for the NIS daemons. # # Are we a NIS server and if so what kind (values: false, slave, master) NISSERVER=master # Location of the master NIS password file (for yppasswdd). # If you change this make sure it matches with /var/yp/Makefile. YPPWDDIR=/etc # Do we allow the user to use ypchsh and/or ypchfn ? The YPCHANGEOK # fields are passed with -e to yppasswdd, see it's manpage. # Possible values: "chsh", "chfn", "chsh,chfn" YPCHANGEOK=chsh |
Gli elaboratori che devono condividere le informazioni amministrate con il NIS, devono utilizzare il demone ypbind, configurato opportunamente. In tal modo, su tali elaboratori, invece di utilizzare le informazioni amministrative locali, verranno usate quelle concentrate dal NIS.
La configurazione di ypbind avviene attraverso i file /etc/yp.conf e /etc/nsswitch.conf. Il primo serve a definire come raggiungere i serventi; il secondo definisce l'ordine di utilizzo dei servizi (Name service switch).
Come nel caso dei serventi, anche i clienti richiedono la definizione del dominio NIS, attraverso domainname. Se il dominio non viene predisposto ypbind non può funzionare.
Anche il cliente richiede la presenza della directory /var/yp/. Al suo interno viene creata la directory binding/.
Anche il cliente richiede l'attivazione del Portmapper RPC.
A seconda delle caratteristiche particolari del cliente, sono possibili delle configurazioni speciali per ciò che riguarda l'accesso da parte degli utenti. Quando la loro gestione è compito del NIS, si può configurare il cliente in modo da definire una graduatoria nella ricerca dei dati che identificano l'utente al momento dell'accesso. Di solito si cerca prima l'utente nel file /etc/passwd locale, quindi si prova con il NIS.
A parte questo particolare abbastanza semplice, si può porre il problema di voler concedere l'accesso su un certo elaboratore solo ad alcuni utenti definiti attraverso il NIS, oppure, più semplicemente, si può volere escludere l'accesso da parte di qualcuno. Per ottenere questo occorre intervenire sul file /etc/passwd utilizzando record con notazioni particolari; cosa che qui non viene descritta.
In generale, per fare in modo che gli utenti NIS del dominio a cui si fa riferimento possano accedere da un certo cliente, occorre aggiungere in coda un record speciale nei file /etc/passwd, /etc/group e /etc/shadow:
/etc/passwd
+:::::: |
/etc/group
+::: |
/etc/shadow
+:::::: |
Questo record viene interpretato come il punto in cui si vogliono inserire virtualmente gli utenti NIS.
ypbind è il demone necessario all'attivazione dell'accesso alle informazioni fornite da un servente NIS; è in pratica il cliente NIS. Utilizza la directory /var/yp/binding/ per collocarci all'interno un file contenente le informazioni sul dominio NIS per il quale è stato avviato.
ypbind [opzioni]
ypbind utilizza la configurazione del file /etc/yp.conf per trovare i serventi e quella del file /etc/nsswitch.conf per stabilire l'ordine di utilizzo delle informazioni amministrative.
In caso di difficoltà, può essere avviato con l'opzione -debug, in modo da farlo funzionare in primo piano, per controllare le informazioni diagnostiche emesse attraverso lo standard error.
La configurazione principale di questo demone avviene per mezzo del file /etc/yp.conf, il quale serve a definire come accedere ai serventi.
|
ypbind potrebbe essere in grado di utilizzare solo l'ultima riga di questo file. Di conseguenza, è bene limitarsi a una sola direttiva. |
Il file può contenere tre tipi di direttive, descritte dai modelli sintattici seguenti:
domain dominio_nis server host
domain dominio_nis broadcast
ypserv host
La prima definisce che per il dominio NIS indicato si deve interpellare il servente specificato; la seconda definisce che per il dominio si devono usare delle chiamate circolari a tutta la rete (locale); l'ultima definisce semplicemente un servente, indipendentemente dal dominio.
Quando si utilizza il sistema della chiamata circolare (broadcast), si rischia di ricevere la risposta da un possibile servente fasullo, collocato appositamente per sostituirsi a quelli veri allo scopo di carpire informazioni dai clienti. Se non si temono attacchi di questo tipo, la chiamata circolare è il modo migliore che consente al cliente di scegliersi il servente (quello che risponde prima).
Il servente può essere indicato per nome o per numero IP. Nel primo caso, è necessario che il sistema sia in grado di risolvere il nome in modo indipendente dal NIS (evidentemente). In generale, è conveniente utilizzare l'indirizzo IP per questo scopo.
L'esempio seguente mostra l'unica riga di un file /etc/yp.conf in cui si stabilisce che per il dominio rost.nis-yp si deve usare la chiamata circolare.
domain rost.nis-yp broadcast |
Il file /etc/nsswitch.conf viene usato dalla libreria C per attuare il NSS, ovvero il Name service switch, che in pratica stabilisce l'ordine in cui devono essere cercate le informazioni (se attraverso il NIS, file locali o altro). Pertanto, il modo corretto di configurare questo file dipende strettamente dal tipo e dalla versione della libreria utilizzata. Si veda a questo proposito quanto descritto nella pagina di manuale nsswitch.conf(5), oppure nell'ipertesto Info: libc.info.
Quello che segue è la configurazione proposta in una distribuzione GNU particolare.
# /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. # passwd: compat group: compat shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
Dal lato del cliente sono importanti altri programmi di contorno. Si tratta precisamente di ypwhich, ypcat, ypmatch e yppasswd.
ypwhich permette di conoscere quale sia il servente NIS utilizzato dal cliente, quando viene avviato senza opzioni, oppure quale sia precisamente il servente principale per una certa mappa.
ypwhich [opzioni]
Seguono alcuni esempi di utilizzo di ypwhich.
$ ypwhich
Emette il nome dell'elaboratore che funge da servente NIS per quel particolare cliente.
$ ypwhich -m
Emette l'elenco delle mappe gestire dal NIS con i rispettivi serventi principali competenti.
ypcat emette il contenuto di una mappa indicata come argomento della riga di comando. Questo programma dipende da ypbind.
ypcat [opzioni] mappa
| Opzione | Descrizione |
|
| Utilizza un dominio differente da quello predefinito. Per usare questa opzione occorre comunque che tale dominio diverso sia stato collegato. |
L'esempio seguente serve a emettere il contenuto della mappa corrispondente all'elenco dei gruppi per nome.
$ ypcat group.byname
ypmatch emette il valori corrispondenti a una o più chiavi di una mappa. Questo programma dipende da ypbind.
ypmatch [opzioni] chiave... mappa
| Opzione | Descrizione |
|
| Utilizza un dominio differente da quello predefinito. Per usare questa opzione occorre comunque che tale dominio diverso sia stato collegato. |
Seguono alcuni esempi di utilizzo di ypmatch.
$ ypmatch tizio caio passwd.byname
Emette i record corrispondenti agli utenti tizio e caio.
$ ypmatch 500 passwd.byuid
Emette il record corrispondente all'utente identificato dal numero UID 500.
yppasswd, ypchsh e ypchfn sono tre alias dello stesso programma. A seconda del nome usato per avviarlo, si intende cambiare la parola d'ordine, la shell o le informazioni personali.
yppasswd [utente]
ypchsh [utente]
ypchfn [utente]
Questi comandi si sostituiscono ai soliti passwd, chsh e chfn, che hanno effetto solo localmente, quando si vuole intervenire sulle utenze gestite dal NIS. A questo proposito, è bene considerare la possibiltà di fare «sparire» i comandi normali, in modo da non creare confusione agli utenti, predisponendo dei collegamenti simbolici opportuni per fare in modo che passwd, chsh e chfn avviino rispettivamente i corrispondenti yppasswd, ypchsh e ypchfn.
Questi comandi, quando vengono invocati, si mettono in contatto con il servente principale, nel quale deve essere in funzione il demone rpc.passwdd. È da questo demone che dipende la possibilità di cambiare questi valori, ma potrebbe capitare che sia abilitata solo la sostituzione delle parole d'ordine.
Solo l'utente root può indicare il nome di un altro utente attraverso la riga di comando.
Quando si gestiscono gli utenti (e i gruppi) attraverso il NIS, si intende permettere a tutti questi utenti di utilizzare indifferentemente tutte le macchine su cui si fa funzionare il cliente NIS. Per raggiungere questo obiettivo, occorre fare in modo che le rispettive directory personali (home) siano accessibili da qualunque postazione. Evidentemente è necessario usare uno spazio condiviso in rete, attraverso il protocollo NFS.
Il modo più semplice potrebbe essere quello di predisporre una partizione apposita in un servente NFS, montando tale file system nella directory /home/ di ogni cliente NIS. Come si può intuire non si tratta di una soluzione ottimale, ma comunque è qualcosa di pratico, almeno inizialmente.
Il file system condiviso dovrà essere accessibile in lettura e scrittura.
La gestione del protocollo NFS è descritta nel capitolo 137.
Il servizio NIS si avvale per il suo funzionamento del Portmapper e di altri demoni specifici, come descritto nel capitolo. In generale, questi demoni comunicano utilizzando porte TCP o UDP definite in modo dinamico, pubblicizzate poi dal Portmapper stesso. Pertanto, a parte il Portmapper che opera alla porta 111, non esiste la possibilità di controllare il traffico NIS per mezzo di filtri di pacchetto che usano come riferimento le porte TCP e UDP.
Eventualmente, molti dei demoni del servizio NIS possono accettare un opzione della riga di comando con la quale si specifica espressamente un numero di porta; in questo modo di può stabilire una convenzione interna e sfruttare questa per la configurazione di un firewall.
Thorsten Kukuk, The Linux NIS(YP)/NYS/NIS+ HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
daniele @ swlibero.org2) YP Bind-mt GNU GPL
4) Se non serve, o non funziona, si ottiene al massimo una segnalazione di errore nel momento in cui si utilizza il file-make, senza altri effetti collaterali.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome nis.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]