Configurazione server NIS

Configurazione di un server NIS (Network Information Service)

Operazioni preliminari

Si assume che il server NIS che si sta per configurare debba essere il solo ad essere attivo nella rete locale, il cosiddetto “master”, senza server secondari, detti “slave”.

Per far funzionare il NIS serve che il portmapper sia in esecuzione sia sul server che sul client. Per controllare che il pacchetto sia installato si può eseguire uno dei comandi che seguono (per sistemi Linux RedHat/SuSE/Mandriva oppure Debian o ancora Gentoo, nell'ordine - notazione lunga):

rpm --query portmap
dpkg --list portmap
emerge --search portmap

Se non risultasse installato, lo si installi. Per mandarlo in esecuzione, si esegua questo comando:


[root@server ~]# /etc/init.d/portmap start

Per verificare che stia funzionando a dovere si fa così:


[servizio@server ~]$ /usr/sbin/rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper

Adesso si deve modificare il file /etc/hosts.allow per rendere il portmap disponibile alle macchine della rete che se ne dovranno servire. Supponendo che tale rete sia la 192.168.1.0/24, si deve mettere in questo file la riga seguente:


portmap:     192.168.1.0/255.255.255.0

Con il comando che segue si verifica l'effettiva presenza di questa riga nel file:

[servizio@server ~]$ grep ^portmap /etc/hosts.allow
portmap:     192.168.1.0/255.255.255.0

Ora si deve verificare che il file /etc/yp.conf sia presente e che contenga la configurazione giusta. Ad esempio, potrebbe contenere queste righe (il comando riportato nel seguito esclude le linee di commento):

[servizio@server ~]$ grep ^[^#] /etc/yp.conf
ypserver principale.internalia
domain internalia server principale.internalia

"principale" è il nome della macchina che funge da server NIS per il dominio “internalia”. Non è necessario che sia lo stesso nome di quello canonico pienamente qualificato DNS: se si prendono alcune precauzioni si può distinguere il dominio NIS da quello DNS. È quello che infatti suggerisce di fare diversa documentazione sulla configurazione e la gestione di un server NIS, per motivi di sicurezza. Essendo un server NIS più difficile da mettere in sicurezza della maggior parte dei servizi Internet per via della sua complicazione, si preferisce creare un dominio parallelo a quello usato per gli altri servizi TPC/IP, il cui nome sia ignoto a quanti non siano al suo interno. Nel nostro caso il server NIS ha già un nome di host e di dominio, che sono server.localdomain, però per quanto riguarda il servizio NIS sarà la macchina di nome “principale” sul dominio “internalia”.

Il nome del dominio NIS si imposta con il comando "domainname":

[root@server ~]# domainname
(none)
[root@server ~]# domainname internalia
[root@server ~]# domainname
internalia
[root@server ~]#

Per rendere questa impostazione permanente si deve scrivere questo nome nel file /etc/defaultdomain :

[root@server ~]# echo internalia > /etc/defaultdomain

Nella Fedora Core5 il file di avvio del servizio NIS /etc/init.d/nis cerca questo file e, se lo trova, esegue questo comando:

domainname `cat /etc/defaultdomain`

Preparazione del server NIS

Fin'ora si è attivato il portmap e si è configurato il nome del dominio NIS e il suo relativo server. Il programma server che gestisce le interrogazioni da parte dei client e che fornisce loro le risposte è “ypserv”. Per averlo disponibile è necessario avere installato il pacchetto ypserv. Prima di mandarlo in esecuzione è bene configurare il sistema perché ponga dei limiti a quali host delle reti cui è connesso il server deve poter rispondere. Ci sono due metodi per farlo: o il programma ypserv è stato compilato per usare i file /etc/hosts.deny e /etc/hosts.allow che usano molti altri servizi di rete, oppure usa un file suo specifico: il file /etc/ypserv.securenets. Per sapere quale di questi file il programma ypserv sia stato configurato ad usare in fase di compilazione, si può tentare di farglielo dire con l'opzione -version:

[servizio@server ~]$ /usr/sbin/ypserv -version
ypserv - NYS YP Server version 1.3.11 (with securenets)
                                      ^^^^^^^^^^^^^^^^^

Altrimenti si sarebbe letto “tcp wrapper” al posto di “securenets”.
Nel caso non sia possibile saperlo con questo comando si deve leggere la relativa pagina man per saperlo. Ad esempio, la versione fornita con Debian GNU/Linux 3.1 non fornisce tale informazione:

ypserv (ypserv) 2.14

Nel seguito compare un esempio del file /etc/ypserv.securenets realtivo ad un ypserv compilato per usare il meccanismo “securenets”:

[servizio@server ~]$ cat /etc/ypserv.securenets 
#
# securenets    This file defines the access rights to your NIS server
#               for NIS clients (and slave servers - ypxfrd uses this
#               file too). This file contains netmask/network pairs.
#               A clients IP address needs to match with at least one
#               of those.
#
#               One can use the word "host" instead of a netmask of
#               255.255.255.255. Only IP addresses are allowed in this
#               file, not hostnames.
#
# Always allow access for localhost
host 127.0.0.1
# same as 255.255.255.255 127.0.0.1
#255.0.0.0      127.0.0.0

# This line gives access to everybody. PLEASE ADJUST!
#0.0.0.0                0.0.0.0
255.255.255.240 192.168.1.0

Fosse stato ypserv compilato per usare invece il meccanismo tcp_wrapper si dovrebbe avere una riga come la seguente nel file /etc/hosts.allow:

ypserv: 127.0.0.0/255.0.0.0,192.168.1.0/255.255.255.0

Adesso si deve passare a configurare il server preparando opportunamente il file /etc/ypserv.conf. Un esempio completo è ripostato nel seguito:

[servizio@server ~]$ cat /etc/ypserv.conf
#
# ypserv.conf   In this file you can set certain options for the NIS server,
#               and you can deny or restrict access to certain maps based
#               on the originating host.
#
#               See ypserv.conf(5) for a description of the syntax.
#

# 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                       : Domain  : Map              : Security
#
# *                          : *       : passwd.byname    : port/mangle       
# *                          : *       : passwd.byuid     : port/mangle       

# This is the default - restrict access to the shadow password file,
# allow access to all others.
192.168.1.0/255.255.255.240        : *       : shadow.byname    : port
192.168.1.0/255.255.255.240        : *       : passwd.adjunct.byname : port
192.168.1.0/255.255.255.240        : *       : *                : none

Perché ora sia usato il sistema di recupero informazioni NIS sulle macchine attive sulla rete locale invece di quello standard basato sui file locali o il DNS, bisogna agire sul file /etc/host.conf, dove si specifica in quale ordine effettuare questo genere di ricerca. Nell'esempio che segue si instruisce il sistema ad eseguire le ricerche prima consultando il file locale /etc/hosts, quindi interrogando il server NIS specificato nel file /etc/yp.conf, altrimenti, in ultima istanza, cercando di interrogare il server DNS indicato in /etc/resolv.conf:

[servizio@server ~]$ cat /etc/host.conf
order hosts,nis,bind
multi on

Il prossimo file cui ci si deve dedicare è il file /etc/nsswitch.conf. Questo file determina l'ordine in cui sono eseguire le ricerche nei database o servizi di informazione disponibili al sistema ogni volta che un client richiede un'informazione. Tipicamente contiene queste instruzioni di configurazione:

[servizio@server ~]$ cat /etc/nsswitch.conf
# /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 nis dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

# As suggested in the NIS HOWTO:

passwd_compat: nis
group_compat: nis
shadow_compat: nis

# As suggested in the NIS HOWTO, with "db" added just before "files":

services:   nis [NOTFOUND=return] db files
networks:   nis [NOTFOUND=return] db files
protocols:  nis [NOTFOUND=return] db files
rpc:        nis [NOTFOUND=return] db files
ethers:     nis [NOTFOUND=return] db files
# netmasks:   nis [NOTFOUND=return] files
# netgroup:   nis
bootparams: nis [NOTFOUND=return] files
publickey:  nis [NOTFOUND=return] files
automount:  files
aliases:    nis [NOTFOUND=return] files

Il file /etc/resolv.conf non è specifico per NIS. Serve invece per configurare le interrogazioni DNS. Ci sarà bisogno di averlo sistemato per bene in ogni caso, eccone quindi un esempio:

[servizio@server ~]$ cat /etc/resolv.conf
nameserver 192.168.1.70
domain internalia

Questo file istruisce il sistema a tentare di contattare il server DNS all'indirizzo 192.168.1.70 ogni volta che è necessario risolvere un nome di dominio in un indirizzo IP.

Normalmente ai client NIS è possibile avere visione dei soli dati del file /etc/passwd relativi agli utenti non privilegiati. Esiste la possibilità di limitare ulteriormente questo elenco, ma essendo questo un corso base non si prenderanno in considerazione questo ed altri dettagli.
Ora si passa ad editare il file /var/yp/Makefile. In questo file sono definiti i file il cui contenuto è gestito dal server NIS nel corso del suo esercizio. Si deve essere sicuri che tutti i file che vi sono elencati esistano realmente, altrimenti s'incorrerà in un errore nel passo successivo. Inoltre è bene si controlli che il contenuto di tutti i file qui presenti è accettabile sia reso disponibile a tutti i client NIS che avranno accesso a questo servizio.
I file che sono definiti in questo file come contenenti i dati reperibili con interrogazioni NIS sono quelli elencati in righe come queste:

ALL =   passwd group hosts rpc services netid protocols netgrp
ALL +=  timezone networks
#ALL += publickey mail ethers bootparams printcap
#ALL += timezone locale networks netmasks

Adesso si può procedere con la creazione del database che NIS userà per fornire i dati che i client chiederanno (il comando è seguito dall'output che fornisce):

[root@server ~]# /usr/lib/yp/ypinit -m

At this point, we have to construct a list of the hosts which will run NIS
servers.  server 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:  principale
        next host to add:
The current list of NIS servers looks like this:

principale

Is this correct?  [y/n: y]  y
We need some  minutes to build the databases...
Building /var/yp/internalia/ypservers...
Running /var/yp/Makefile...
make[1]: Entering directory `/var/yp/internalia'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating netgroup...
Updating netgroup.byhost...
Updating netgroup.byuser...
make[1]: Leaving directory `/var/yp/internalia'

Adesso si può provare a lanciare in esecuzione il server NIS. Si può fare a mano:

[root@server ~]# /usr/sbin/ypserv

Oppure, preferibilmente, si usa l'apposito script di attivazione/disattivazione del servizio:

[root@server ~]# /etc/init.d/nis start

Questo script avvia non solo il server ypserv, ma anche il programma yppasswdd che gestisce le password del sistema NIS e il programma ypbind che si connette con il server definito nel file /etc/yp.conf rendendone disponibili i servizi ai client NIS.
Dovesse l'attesa per riottenere il controllo del terminale dal quale si è mandato in esecuzione il server risultare troppo lunga (più di un paio di secondi), si dovrebbe sospettare l'esistenza di un problema che ha impedito al programma ypbind di connettersi al server ypserv per renderne disponibili i servizi ai client, cosa che continuerà a tentare nel “sottofondo” dopo essersi distaccato dalla console che l'ha mandato in esecuzione. In tale caso, il server starebbe girando, ma non sarebbe interrogabile dai client.
Per essere sicuri che il server ypbind stia girando si può fare:

[root@server ~]# rpcinfo -u localhost ypserv
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting

La prima riga può mancare, ma che è la seconda che è importante. In questo caso il programma sta girando. Si fosse ottenuto il messaggio: "Port mapper failure - RPC: Unable to receive", avrebbe voluto dire che non c'è ancora il portmap in esecuzione. Si controlli ora che sia disponibile anche ypbind. Questo si può vedere con il comando:

[root@server ~]# rpcinfo -u localhost ypbind
rpcinfo: RPC: Program not registered
program 100007 is not available

Si provi allora ad avviare manualmente ypbind sul server:

[root@server ~]# ypbind
[root@server ~]#

Se il prompt della console ritorna velocemente a disposizione, ciò vuol dire che probabilmente ypbind si è connesso con il server ypserv senza problemi. Tardasse invece a tornare a disposizione il prompt, questo vorrebbe dire che ypbind è andato incontro a dei problemi nel tentativo di connettersi con ypserv. Potrebbe ad esempio comparire una fila di puntini sullo schermo seguita alla fine dalla scritta backgrounded, come in questo esempio:

[binding to YP server .......... backgrounded]

In questo caso, si provi ad eseguire ypbind in modalità “debug”, per tentare di rilevare la causa del problema:

[root@server ~]# ypbind -d
parsing config file
Trying entry: ypserver principale.internalia
parsed ypserver principale.internalia
add_server() domain: internalia, host: principale.internalia, nobroadcast, slot: 0
do_ypcall: clnt_call: RPC: Unable to receive; errno = Connection refused
Host name lookup failure
Trying entry: domain internalia server principale.internalia
parsed domain 'internalia' server 'principale.internalia'

In questo caso il problema è causato dall'impossibilità per ypbind di risolvere il nome del server 'principale.internalia' in un IP numerico (Host name lookup failure). Per correggere questo problema si può o aggiungere una riga nel file /etc/hosts che attribuisca un IP numerico al server solo alla macchina locale, oppure si deve configurare il server DNS disponibile nella rete locale perché faccia lui questo lavoro. Si adottasse il primo metodo, si deve aggiungere nel file /etc/hosts una riga come la seguente:

192.168.1.40     principale.internalia   principale

Si deve adesso rilanciare ypbind. Si controlli quindi che stia funzionando a dovere:

[servizio@server ~]$ ypwhich
principale.localdomain
[servizio@server ~]$

Bene, funziona. Adesso si provi quest'altro:

[servizio@server ~]$ ypcat passwd
antonio:x:1000:100::/home/antonio:/bin/bash
guest:x:1001:107::/home/guest:/bin/rbash
ltsp:x:1002:100::/home/ltsp:/bin/bash
rpc:x:1003:65534:RPC user:/home/rpc:/dev/false

Si ottenesse un risultato analogo si potrebbe stare tranquilli che tutto è andato ottimamente.
Il server è pronto per essere interrogato anche da altri host presenti nella rete. Ci si ricordi di permettere a questi host di contattare il portmap del server:

[servizio@server ~]$ grep ^portmap /etc/hosts.allow 
portmap: 192.168.1.0/255.255.255.0

Configurazione del client

Sullo host deve girare il portmap e deve quindi essere configurato il file /etc/yp.conf perché indichi quale server NIS di default si deve usare:

[tizio@client ~]$ cat /etc/yp.conf
ypserver  principale.internalia
domain internalia server  principale.internalia

Ci si può accertare che il file di configurazione locale sia di gradimento a ypbind:

[root@client ~]# ypbind -c
Trying entry: ypserver  principale.internalia
Trying entry: domain internalia server  principale.internalia
Config file /etc/yp.conf is ok.

Si lancia ypbind perché si connetta al server NIS remoto dal client:

[root@client ~]# ypbind
[root@client ~]#

Per essere sicuri, si vedono due cose:

1) che ypbind abbia creato i due file (uno per versione del protocollo) in /var/yp/binding/:

[tizio@client ~]$ ll /var/yp/binding/
totale 2,0K
-rw-r--r-- 1 root root 14 10 mag 22:51 principale.1
-rw-r--r-- 1 root root 14 10 mag 22:51 principale.2

2) che il relativo servizio RPC sia visibile (indicare localhost è facoltativo):

[tizio@client ~]$ /usr/sbin/rpcinfo -p localhost
 programma vers proto   porta
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100007    2   udp    764  ypbind
    100007    1   udp    764  ypbind
    100007    2   tcp    767  ypbind
    100007    1   tcp    767  ypbind

Si veda se lo host riconosce il server come suo server NIS:

[tizio@client ~]$ ypwhich
server

In questo caso, tutto bene. Si provi allora ricevere qualche informazione dal server NIS, come gli utenti presenti nel suo database:

[tizio@client ~]$ ypcat passwd
antonio:x:1000:100::/home/antonio:/bin/bash
guest:x:1001:107::/home/guest:/bin/rbash
ltsp:x:1002:100::/home/ltsp:/bin/bash
rpc:x:1003:65534:RPC user:/home/rpc:/dev/false

Si veda ora la lista completa delle tabelle e dei loro pseudonimi:

[root@client ~]# ypwhich -m
shadow.byname principale.internalia
networks.byname principale.internalia
networks.byaddr principale.internalia
timezone.byname principale.internalia
netgroup.byuser principale.internalia
netgroup.byhost principale.internalia
netgroup principale.internalia
protocols.bynumber principale.internalia
services.byservicename principale.internalia
netid.byname principale.internalia
services.byname principale.internalia
rpc.bynumber principale.internalia
rpc.byname principale.internalia
hosts.byaddr principale.internalia
hosts.byname principale.internalia
group.bygid principale.internalia
group.byname principale.internalia
passwd.byname principale.internalia
protocols.byname principale.internalia
ypservers principale.internalia
passwd.byuid principale.internalia

Si veda se un utente non privilegiato ha la stessa fortuna:

[tizio@client ~]$ ypwhich -m
Can't find master for map shadow.byname. Reason: No such map in server's domain
networks.byname principale.internalia
networks.byaddr principale.internalia
timezone.byname principale.internalia
netgroup.byuser principale.internalia
netgroup.byhost principale.internalia
netgroup principale.internalia
protocols.bynumber principale.internalia
services.byservicename principale.internalia
netid.byname principale.internalia
services.byname principale.internalia
rpc.bynumber principale.internalia
rpc.byname principale.internalia
hosts.byaddr principale.internalia
hosts.byname principale.internalia
group.bygid principale.internalia
group.byname principale.internalia
passwd.byname principale.internalia
protocols.byname principale.internalia
ypservers principale.internalia
passwd.byuid principale.internalia

Così è normale che sia, avendo limitato l'accesso al contenuto del file shadow nel file di configurazione del server /etc/ypserv.conf.
Sono adesso disponibili tutti gli strumenti di gestione del sistema e degli utenti come yppasswd, che permette di cambiare la password dell'utente, ypchsh, per cambiare la shell di login, ypchfn, per cambiare il nome e altri dati dell'utente e ypcat, per avere informazioni varie dai file di sistema cui NIS procura l'accesso. Questi comandi specifici per NIS sono tuttavia considerati obsoleti, in quanto le versioni più recenti dei normali comandi per il controllo degli stessi dati locali (dal nome analogo senza il prefisso "yp") funzionano anche in ambiente NIS.

Ultima modifica: 16 ottobre 2008
Alcuni diritti riservati dall'autore, Alessandro Selli (http://alessandro.route-add.net)
Distribuito sotto licenza Creative Commons Attribuzione - Non commerciale 3.0

< Torna al livello superiore <
<< Torna alla pagina inziale <<