Il NIS, 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 utilità che riguardano questo servizio hanno, tradizionalmente, il prefisso yp, e anche perché spesso si parli di «servizi YP» invece che di «servizi NIS».
Il NIS è un meccanismo che si sovrappone alla gestione amministrativa di un tipico sistema Unix, e 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 96.1 elenca alcuni file di configurazione, tipici di un sistema Unix, che possono essere gestiti in questo modo.
| File | Descrizione |
| /etc/passwd | Informazioni sugli utenti. |
| /etc/group | Gruppi di utenti. |
| /etc/shadow | Shadow password (quando gestibili). |
| /etc/aliases | Alias di posta elettronica. |
| /etc/hosts | Traduzione degli indirizzi IP dei nodi della rete locale. |
| /etc/networks | Traduzione degli indirizzi IP delle sottoreti (locali). |
| /etc/protocols | Nomi e numeri dei protocolli di rete. |
| /etc/rpc | Numeri delle chiamate RPC. |
| /etc/services | Abbinamento dei servizi di rete ai numeri di porta corrispondenti. |
|
È bene chiarire subito che il supporto alle shadow password non è disponibile in tutti i NIS esistenti; inoltre, la natura del NIS rende poco probabile l'utilità del loro utilizzo. |
La concentrazione amministrativa si attua facendo in modo che le informazioni dei file che interessano siano gestite a partire da un unico 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 e /etc/group.
Il NIS non utilizza i file amministrativi così come sono, ne crea una copia, e 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 server NIS.
La tabella
96.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>/.
| Mappa | Descrizione |
| passwd.byname | Utenti per nome. |
| passwd.byuid | Utenti per numero UID. |
| group.byname | Gruppi per nome. |
| group.bygid | Gruppi per numero GID. |
| shadow.byname | Utenti per nome (dal file /etc/shadow). |
| mail.aliases | Alias di posta elettronica. |
| hosts.byname | Nodi per nome. |
| hosts.byaddr | Nodi per indirizzo. |
| networks.byname | Reti locali per nome. |
| networks.byaddr | Reti locali per indirizzo. |
| protocols.byname | Protocolli di rete per nome. |
| protocols.bynumber | Protocolli di rete per numero. |
| rpc.byname | Chiamate RPC per nome. |
| rpc.bynumber | Chiamate RPC per numero. |
| services.byname | Servizi di rete per nome. |
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, e 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 server 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 client, maggiore sarà la frequenza con cui dovrà rispondere a richieste del protocollo NIS.
I file di mappa di un server NIS sono raggruppati distintamente per dominio, nella directory /var/yp/<dominio-NIS>/.
Finora si è fatto riferimento a un server NIS unico per tutto il suo dominio di competenza. Quando si attiva un servizio di questo tipo, tutti gli elaboratori client di questo dominio dipendono completamente dal server 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 client sarebbero in grave difficoltà.
Per risolvere il problema, si possono predisporre dei server NIS slave, definiti così solo perché riproducono le informazioni del server principale, o master.
|
Il motivo per il quale si utilizza il servizio NIS è quello di uniformare e concentrare la gestione di informazioni di un gran numero di elaboratori, altrimenti non sarebbe giustificato l'impegno necessario alla sua attivazione. Di conseguenza, è praticamente obbligatorio attivare dei server slave, sia per attenuare i rischi di blocco del sistema globale, sia per ridurre il carico di richieste NIS su un'unica macchina. |
La presenza di server slave impone la creazione di meccanismi automatici per il loro allineamento, generalmente attraverso il sistema Cron.
Finora si è parlato del compito del server NIS, senza prendere in considerazione i client, e all'inizio la distinzione dei compiti può sembrare confusa.
Il client è 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 tipica situazione è quella della procedura di accesso: se il nome dell'utente non viene trovato nel file /etc/passwd locale, il client NIS cerca di ottenerlo dal server NIS.
In pratica, le funzionalità di server e client sono indipendenti, e ci possono essere elaboratori che fungono da server, altri che utilizzano il programma client per accedere alle informazioni e altri ancora che fanno questo e quello.
Se si pensa che il server NIS master deve contenere tutte le informazioni che vengono condivise dai programmi client presso gli altri elaboratori, potrebbe sembrare inutile l'attivazione del programma client nello stesso server. Le cose cambiano quando si considerano i server slave. Questi non dispongono delle informazioni che ha il master, e per ottenerle occorre attivare il client NIS in modo da poterli mettere in comunicazione con il master.
Nel sistema NIS così strutturato, i client cercano le informazioni, riferite al loro dominio, dal server 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 master) sui dati di partenza;
la modifica di un'informazione attraverso gli strumenti offerti dal sistema NIS.
Nel primo caso le azioni da compiere sono:
aggiornare le mappe del master;
aggiornare le mappe degli slave.
Nel secondo caso le azioni da compiere sono:
aggiornare i file di configurazione corrispondenti nel master
aggiornare le mappe del master
aggiornare le mappe degli slave
Quando si interviene manualmente sui file di configurazione di partenza del server master, per esempio quando si vuole aggiungere o eliminare un utente, si deve poi comandare manualmente l'aggiornamento delle mappe NIS, ed eventualmente si può pilotare anche l'aggiornamento degli slave, 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 client, il quale si occupa di contattare il master che poi deve provvedere ad aggiornare i file normali e le mappe.
La propagazione delle mappe modificate agli slave potrebbe essere un problema. Per questo si utilizza generalmente il sistema Cron in ogni slave, in modo da avviare periodicamente il comando necessario a metterli in comunicazione con il master 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 password da un client NIS. Questo contatta il master che provvede ad aggiornare le mappe e il file /etc/passwd. Ma fino a che gli slave non ricevono l'aggiornamento, i client che li utilizzano continuano a permettere l'accesso utilizzando la password vecchia. Questo può capitare allo stesso elaboratore dal quale è stata compiuta l'operazione di modifica, se questo utilizza il servizio di uno slave non aggiornato. In queste condizioni, l'utente che ha appena cambiato password 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 client 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, e come tale anche la risoluzione dei nomi della rete deve essere considerato un problema 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 server DNS; al limite si possono unire le due cose:
order hosts,bind,nis |
Purtroppo non esiste un unico sistema NIS standard; ne esistono tre: NIS, NIS+ e NYS. Il primo, è il sistema NIS tradizionale, piuttosto debole dal punto di vista della sicurezza; il secondo è un sistema più complesso, con lo scopo di superare i limiti di sicurezza del NIS tradizionale; il terzo è il sistema che vuole incorporare le funzionalità di NIS+ e aggiungere altri vantaggi.
Il sistema NIS tradizionale è quello più comune; il NIS+ è disponibile solo su sistemi Sun Microsystems; il NYS è in corso di sviluppo e in linea di massima può essere usato almeno come un NIS normale.
Per ogni tipo di server NIS ci deve essere un programma client adatto, configurato conformemente alle particolarità del servizio da cui attinge. Oltre a questo, a seconda del tipo di servizio utilizzato ci sono esigenze diverse rispetto alle librerie.
In pratica, a meno di volere approfondire l'argomento studiando dettagliatamente le dipendenze che ci sono tra i vari programmi di ogni tipo di NIS, conviene affidarsi alle scelte fatte dalla propria distribuzione GNU/Linux. Per quanto riguarda il server può trattarsi solo di NIS o NYS, in quanto il NIS+ appartiene esclusivamente a Sun Microsystems; per il client dovrebbe trattarsi di quello adatto a connettersi con il server NIS della distribuzione. *1*
|
Il vero problema di tutto questo sta nel fatto che sono poche le distribuzioni GNU/Linux che pongono attenzione al NIS, e spesso capita che la configurazione definita in fase di compilazione dei sorgenti non sia perfetta. Tra le tante cose, potrebbe capitare che i file di configurazione debbano essere collocati in |
Il NIS utilizza le chiamate RPC per comunicare. Questo significa che è necessaria la presenza del portmapper in funzione sia nei server che nei client (si veda eventualmente il capitolo 85).
È anche importante verificare che i servizi di sincronizzazione, time service, siano previsti all'interno del file /etc/inetd.conf, come mostrato nel pezzo seguente:
# # Time service is used for clock syncronization. # time stream tcp nowait nobody /usr/sbin/tcpd in.timed time dgram udp wait nobody /usr/sbin/tcpd in.timed |
Se si devono apportare delle modifiche a questo file di configurazione, bisogna ricordare di riavviare inetd (vedere eventualmente il capitolo
84).
Gli elementi indispensabili di un server 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 master è anche opportuna la presenza di altri due demoni: rpc.passwdd e rpc.ypxfrd. Il primo serve a permettere la modifica delle password degli utenti attraverso il sistema NIS, il secondo serve a facilitare l'aggiornamento agli slave.
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 /var/yp/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
# ypserv [Invio]-version
ypserv - NYS YP Server version 1.1.7 (with tcp wrapper) |
L'esempio mostra il risultato di un ypserv NYS compilato con il supporto per il tcp wrapper, cioè per l'utilizzo dei file /etc/hosts.allow e /etc/hosts.deny, gli stessi che servono a tcpd per filtrare gli accessi ai programmi controllati da inetd.
|
Prima di poter avviare il server |
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, e 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.
domainname [<opzioni>] [<dominio-NIS>] |
nisdomainname [<opzioni>] [<dominio-NIS>] |
ypdomainname [<opzioni>] [<dominio-NIS>] |
domainname (e i suoi alias) permette di modificare o visualizzare il nome del dominio NIS.
|
Permette di definire il nome di un file contenente il nome del dominio.
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, e 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 /var/yp/securenets (prima si deve verificare con l'opzione -version/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 [Invio]-p localhost
program vers proto port
100000 2 tcp 111 rpcbind
100000 2 udp 111 rpcbind
...
|
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 [Invio]-u localhost ypserv
program 100004 version 2 ready and waiting |
ypserv [<opzioni>] |
ypserv è il demone che si occupa di servire un dominio NIS con le informazioni definite dalle mappe relative. ypserv accetta alcune opzioni nella riga di comando, ma viene configurato fondamentalmente attraverso il file /etc/ypserv.conf. Per il suo funzionamento corretto è necessario che il sistema RPC sia funzionante, che sia stato definito il dominio NIS e che la directory /var/yp/ sia stata predisposta.
|
Utilizzando questa opzione si fa in modo che ypserv funzioni in modalità diagnostica. Per questo, invece di passare sullo sfondo, continua a funzionare occupando il terminale dal quale è stato avviato, emettendo informazioni particolareggiate su ciò che avviene attraverso lo standard error. Eventualmente si può indicare un percorso come argomento dell'opzione, intendendo fare in modo che ypserv utilizzi le mappe contenute a partire da quella directory, invece di quelle che si trovano a partire da /var/yp/.
|
Specifica che se un nodo non viene identificato diversamente, si deve utilizzare il servizio DNS.
|
Visualizza i dati riferiti alla particolare versione di ypserv, e questa indicazione è molto importante, soprattutto per sapere quali file vengono utilizzati per controllare gli indirizzi che possono accedere al servizio.
ypserv, quando tutto è configurato correttamente, viene avviato 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, e se manca non ha senso avviare il server 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 server 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. Ogni volta che si fanno dei cambiamenti a questa configurazione occorre riavviare questi 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] |
Le direttive di accesso hanno il formato seguente:
<host>:<mappa>:<livello-sicurezza>:<soppressione>[:<campo>] |
dns
Attivando questa opzione, si fa in modo che il server NIS utilizzi il DNS quando gli vengono richieste informazioni sui nodi che non può risolvere con le mappe hosts.*. Il valore predefinito è no, e questa opzione può essere attivata anche attraverso la riga di comando di ypserv, -dns
sunos_kludge
L'attivazione di questa opzione permette di rispondere alle chiamate utilizzate da ypbind di SunOS 4. Il valore predefinito per questa opzione è yes, ma la compatibilità con SunOS non è completa.
tryresolve
Questa opzione riguarda la risoluzione dei nomi dei nodi. Il suo valore predefinito è no e non serve in un sistema GNU/Linux.
xfr_check_port
Attivando questa opzione, il server master deve utilizzare una porta inferiore al numero 1024. Il valore predefinito è yes.
<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 porta è inferiore al numero 1024, 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 hanno il supporto per 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/Linux.
# Some options for ypserv. This things are all not needed, if # you have a Linux net. sunos_kludge: no tryresolve: no dns: no # 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 # Not everybody should see the shadow passwords, not secure, since # under MSDOG everybody is root and can access ports < 1024 ! * : shadow.byname : port : yes # If you comment out the next rule, ypserv and rpc.ypxfrd will # look for YP_SECURE and YP_AUTHDES in the maps. This will make # the security check a little bit slower, but you only have to # change the keys on the master server, not the configuration files # on each NIS server. # If you have maps with YP_SECURE or YP_AUTHDES, you should create # a rule for them above, that's much faster. * : * : none |
|
Si è già accennato al fatto che i file di configurazione potrebbero essere cercati nella directory |
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 -version
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 documentazione interna 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 |
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 siano i dati amministrativi che vengono gestiti in quel dominio NIS particolare. La loro creazione, e il loro aggiornamento, avviene 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à di modificare tale file-make per definire quali mappe debbano essere costruite.
In linea di principio non è conveniente lasciare le cose come sono. Il NIS è un sistema troppo complesso perché un principiante possa permettersi di attivare subito la gestione completa di tutte le informazioni amministrative. Nell'esempio che segue viene mostrata una parte del file-make fornito con una particolare distribuzione GNU/Linux (non importa quale), modificato in modo da gestire esclusivamente le informazioni sugli utenti e i gruppi, senza password shadow. È bene ribadire che questo file-make è solo un esempio, come guida per la modifica di quello che si trova con la propria distribuzione.
# This Makefile should only be run on the NIS master server of a domain. #... # If this machine is an NIS master, comment out this next line so # that changes to the NIS maps can be propagated to the slave servers. # (By default we assume that we are only serving a small domain with # only one server.) # #NOPUSH = "True" #... # If you don't want some of these maps built, feel free to comment # them out from this list. # Note that we don't build the ethers or bootparams maps by default # since /etc/ethers and /etc/bootparams are not likely to be present # on all systems. # all: passwd group ypservers ##all: passwd hosts group netid networks protocols rpc services netgrp \ ## mail shadow ypservers publickey ethers # amd.home auto.master ### auto.home bootparams ethers: ethers.byname ethers.byaddr hosts: hosts.byname hosts.byaddr networks: networks.byaddr networks.byname protocols: protocols.bynumber protocols.byname rpc: rpc.byname rpc.bynumber services: services.byname passwd: passwd.byname passwd.byuid group: group.byname group.bygid shadow: shadow.byname netid: netid.byname netgrp: netgroup netgroup.byhost netgroup.byuser publickey: publickey.byname mail: mail.aliases #... |
Nella prima parte viene definito, attraverso una variabile, se il server deve occuparsi di spedire gli aggiornamenti (push) agli slave. In questo caso, commentando l'assegnamento della variabile NOPUSH si ottiene di mantenere attivo questo aggiornamento.
*2*
Più avanti, l'obbiettivo all permette di definire quali mappe costruire. Dall'esempio si può vedere ciò che veniva proposto, commentato, e quello che serve per generare esclusivamente le mappe abbinate ai file /etc/passwd e /etc/group. Il nome ypservers si riferisce al file /var/yp/ypservers, che viene utilizzato per contenere l'elenco dei server (master e slave) competenti per il dominio (verrà chiarito in seguito).
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 ha raggiunto 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 server 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 server master, di conseguenza, il suo indirizzo deve apparire per primo. Supponendo di avere un secondo elaboratore da utilizzare come slave, 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 Sun May 31 23:00:14 CEST 1998 make[1]: Entering directory `/var/yp/rost.nis-yp' Updating passwd.byname... Updating passwd.byuid... Updating group.byname... Updating group.bygid... 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 server, mentre le altre volte è sufficiente utilizzare solo make dalla directory /var/yp/.
rpc.yppasswdd [<opzioni>] |
Il demone rpc.yppasswdd deve essere utilizzato solo nel server master e la sua presenza permette agli utenti di cambiare la password di accesso attraverso il programma yppasswd.
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 della password.
I server slave, ammesso che se ne vogliano avere, devono poter comunicare con il server master, e questo richiede implicitamente che questi, oltre che server slave, siano anche dei client. Più avanti verrà spiegato come predisporre un client NIS; per il momento è bene affrontare ugualmente il problema, per mantenere mentalmente il collegamento con quanto già trattato sul server master.
Un server slave richiede le stesse cose del server master, a eccezione del demone rpc.yppasswdd che nello slave non ha ragione di esistere. Questo significa che:
si deve impostare il dominio NIS;
si deve configurare ypserv attraverso /etc/ypserv.conf e /var/yp/securenets, oppure gli altri file del tcp wrapper.
Si è già accennato al fatto che il server slave deve avere il client 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 server slave, per poter compiere il suo lavoro, deve disporre delle mappe NIS. Queste vengono create, copiandole dal server master, attraverso il comando seguente:
/usr/lib/yp/ypinit
|
In pratica, si avvia ypinit con l'opzione -sdinkel.brot.dg, il comando corretto è il seguente:
# /usr/lib/yp/ypinit -s dinkel.brot.dg
Perché l'operazione funzioni correttamente, occorre che il client 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 server master.
La presenza di server slave introduce nel sistema NIS dei problemi di sincronizzazione di questi con il server master. 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 server slave, e non tutti funzionano sempre, a causa degli accorgimenti utilizzati per ridurre i problemi di sicurezza.
Quando il server master viene aggiornato, dovrebbe essere in grado di inviare agli slave le modifiche alle mappe (push). Questa operazione non funziona se gli slave non sono in ascolto in quel momento, inoltre non funziona anche in altre circostanze, sempre per motivi di sicurezza.
I server slave possono comunicare periodicamente con il master per verificare la presenza di aggiornamenti delle mappe. Questa operazione richiede nel master la presenza in funzione del demone rpc.ypxfrd.
In ultima analisi, i server slave si aggiornano con il comando ypinit .
-s <master>
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 master (quello del primo punto), se per qualche motivo l'aggiornamento a mezzo di ypxfr non funziona, occorre ripiegare necessariamente sull'uso periodico di ypinit , eventualmente collocando anch'esso in un file crontab.
-s
rpc.ypxfrd [<opzioni>] |
Il demone rpc.ypxfrd viene utilizzato solo nel server master per facilitare l'aggiornamento delle mappe negli slave. La sua presenza non è indispensabile, ma è utile per accelerare il processo di aggiornamento.
Generalmente può essere utilizzato senza argomenti, e dovrebbe essere avviato dalla procedura di inizializzazione del sistema.
Gli elaboratori che devono condividere le informazioni amministrate con il NIS, devono utilizzare il client ypbind, configurato opportunamente. In tal modo, su tali elaboratori, invece di utilizzare le informazioni amministrative locali, verranno usate quelle concentrate dal NIS.
Quando si utilizza precisamente NYS, i servizi svolti da ypbind potrebbero essere forniti direttamente dalle librerie del sistema. Tuttavia, anche in questa circostanza, alcuni programmi come ypwhich e ypcat continuano a richiedere la presenza di ypbind.
La configurazione di ypbind e anche quella di NYS (con le sue librerie), avviene attraverso i file /etc/yp.conf e /etc/nsswitch.conf. Il primo serve a definire come raggiungere i server; il secondo definisce l'ordine di utilizzo dei servizi (Name Service Switch).
Come nel caso dei server, anche i client richiedono la definizione del dominio NIS, attraverso domainname. Se il dominio non viene predisposto ypbind non può funzionare.
Anche il client richiede la presenza della directory /var/yp/. Al suo interno viene creata la directory binding/.
Anche il client richiede l'attivazione del portmapper RPC.
A seconda delle caratteristiche particolari del client, 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 client 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, e 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 client, occorre aggiungere nel file /etc/passwd il record seguente:
+:::::: |
Questo viene interpretato come il punto in cui si vogliono inserire virtualmente gli utenti NIS. È probabile che, per fare in modo che vengano utilizzati prima i dati degli utenti già registrati in quel client, questo record debba essere collocato alla fine del file.
Quando si usa NYS, non dovrebbe essere necessario aggiungere questa indicazione; tuttavia, se c'è non può creare danno.
ypbind [<opzioni>] |
ypbind è un demone per l'attivazione dell'accesso alle informazioni fornite da un server NIS; è in pratica il client 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 utilizza la configurazione del file /etc/yp.conf per trovare i server, e quella del file /etc/nsswitch.conf per stabilire l'ordine di utilizzo delle informazioni amministrative.
|
Fa in modo che ypbind continui a funzionare in primo piano, in modo da emettere una serie di informazioni diagnostiche attraverso lo standard error.
Il file /etc/yp.conf serve a definire come accedere ai server. Viene utilizzato sia da ypbind che dalle librerie NYS.
|
|
Il file può contenere tre tipi di direttive, descritte dalle sintassi 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 server specificato; la seconda definisce che per il dominio si devono usare delle chiamate circolari a tutta la rete (locale); l'ultima definisce semplicemente un server, indipendentemente dal dominio.
Quando si utilizza il sistema della chiamata circolare (broadcast), si rischia di ricevere la risposta da un possibile server fasullo, posto appositamente per sostituirsi a quelli veri allo scopo di carpire informazioni dai client. Se non si temono attacchi di questo tipo, la chiamata circolare è il modo migliore per fare in modo che il client sia in grado di scegliersi il server (quello che risponde prima).
Il server, quando deve essere identificato, 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 dal client NIS per determinare l'ordine in cui devono essere richiesti i servizi. La sua configurazione dovrebbe riguardare tutti i tipi di dati amministrativi gestibili con il NIS, anche se di fatto ne sono stati abilitati solo alcuni. In questo modo, la determinazione di cosa gestire con il NIS viene fatta solo nel server master.
Quello che segue è la configurazione proposta in una particolare distribuzione GNU/Linux. Si può osservare che le informazioni sugli utenti (passwd, shadow, group) sono cercate prima nei file locali, e quindi nel servizio NIS.
# # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Legal entries are: # # nisplus or nis+ Use NIS+ (NIS version 3) # nis or yp Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # [NOTFOUND=return] Stop searching if not found so far # passwd: files nisplus nis shadow: files nisplus nis group: files nisplus nis hosts: files nisplus nis dns services: nisplus [NOTFOUND=return] files networks: nisplus [NOTFOUND=return] files protocols: nisplus [NOTFOUND=return] files rpc: nisplus [NOTFOUND=return] files ethers: nisplus [NOTFOUND=return] files netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files netgroup: nisplus publickey: nisplus automount: files nisplus aliases: files nisplus |
ypwhich [<opzioni>] |
ypwhich permette di conoscere quale sia il server NIS utilizzato dal client, quando viene avviato senza opzioni, oppure quale sia precisamente il master per una certa mappa. Questo programma dipende da ypbind, per cui, quest'ultimo deve essere presente anche se si utilizza il NYS.
|
Utilizza un dominio differente da quello predefinito. Per usare questa opzione occorre comunque che tale dominio diverso sia stato collegato.
|
Permette di conoscere quale sia il server master per la particolare mappa specificata, o per tutte quelle che vengono raggiunte.
$ ypwhich
Emette il nome dell'elaboratore che funge da server NIS per quel particolare client.
$ ypwhich -m
Emette l'elenco delle mappe gestire dal NIS con i rispettivi server master competenti.
ypcat [<opzioni>] <mappa> |
ypcat emette il contenuto di una mappa indicata come argomento della riga di comando. Questo programma dipende da ypbind, per cui, quest'ultimo deve essere presente anche se si utilizza il NYS.
|
Utilizza un dominio differente da quello predefinito. Per usare questa opzione occorre comunque che tale dominio diverso sia stato collegato.
$ ypcat group.byname
Emette il contenuto della mappa corrispondente all'elenco dei gruppi per nome.
ypmatch [<opzioni>] <chiave>... <mappa> |
ypmatch emette il valori corrispondenti a una o più chiavi di una mappa. Questo programma dipende da ypbind, per cui, quest'ultimo deve essere presente anche se si utilizza il NYS.
|
Utilizza un dominio differente da quello predefinito. Per usare questa opzione occorre comunque che tale dominio diverso sia stato collegato.
$ 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 [<utente>] |
ypchsh [<utente>] |
ypchfn [<utente>] |
yppasswd, ypchsh e ypchfn sono tre alias dello stesso programma. A seconda del nome usato per avviarlo, si intente cambiare la password, la shell o le informazioni personali.
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, creando 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 server master, nel quale deve essere in funzione il demone rpc.passwdd. È da questo demone che dipende la possibilità di cambiare questi valori, e potrebbe capitare che sia abilitata solo la sostituzione delle password.
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 client NIS. Per raggiungere questo obbiettivo, 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 server NFS, e montare tale filesystem nella directory /home/ di ogni client NIS. Come si può intuire non si tratta di una soluzione ottimale, ma comunque è qualcosa di pratico, almeno inizialmente.
Il filesystem condiviso dovrà essere accessibile in lettura-scrittura.
La gestione del protocollo NFS è descritta nel capitolo 86.
Thorsten Kukuk, The Linux NIS(YP)/NYS/NIS+ HOWTO
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 Daniele Giacomini -- daniele @ pluto.linux.it
1.) Anche se la propria distribuzione GNU/Linux non dovesse includerlo, esiste comunque un client adatto a utilizzare il servizio NIS+.
2.) 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.