Configurazione di un server NIS (Network Information Service)
Prima stesura del 06 maggio 2006
Aggiornato il 24 ottobre 2013
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/Fdora/SuSE/Mandriva:
rpm --query portmap

# Per sistemi Debian/Ubuntu:
dpkg --list portmap

# Per sistemi Gentoo:
emerge --search portmap

Da qualche anno le principali distribuzioni sono passate ad utilizzare il pacchetto rpcbind piuttosto, forse perché il suo sviluppo è più attivo:

rpm --query rpcbind
dpkg --list rpcbind
emerge --search rpcbind

D'ora in avanti si considererà solo rpcbind come fornitore del servizio portmap.
Se non risultasse installato, lo si installi.  Per mandarlo in esecuzione, si esegua questo comando:

# Debian 7 (Wheezy):
[root@server ~]# service rpcbind start

# Fedora 19 (Schrödinger's Cat):
[root@server ~]# systemctl start rpcbind.service

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

[servizio@server ~]$ rpcinfo -p
   programma vers proto   porta
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    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:

rpcbind:     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 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

In Debian Wheezy lo script di controllo del servizio NIS /etc/init.d/nis cessa l'esecuzione se non trova questo file e, se lo trova, esegue questi comandi:

nname=`cat /etc/defaultdomain`
	[...]
domainname "$nname"

Preparazione del server NIS

Fin'ora si è attivato rpcbind e si è configurato il nome del dominio NIS e il suo relativo server.  Il demone che gestisce le interrogazioni da parte dei client e che gli fornisce le risposte è ypserv, contenuto nel pacchetto nis in Debian e nel pacchetto ypserv in Fedora.  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 (ossia usa le librerie tcpwrappers), oppure usa un file suo specifico: /etc/ypserv.securenets .  Da un po' di anni l'ho sempre visto usare questo file securenets.  In caso di dubbi, se la pagina man non chiarisce quale meccanismo di configurazione dell'accesso dalla rete usi il proprio demone, si può tentare di farglielo dire con l'opzione -version:

# Su una vecchia versione di Fedora Core:
[servizio@server ~]$ /usr/sbin/ypserv -version
ypserv - NYS YP Server version 1.3.11 (with securenets)
                                      ^^^^^^^^^^^^^^^^^

# Su Debian Wheezy invece si ha:
ypserv (ypserv) 2.19

Fosse stato il server compilato con il supporto libwrap si sarebbe potuto leggere "tcp wrapper" al posto di "securenets".
Nel caso non sia possibile saperlo neanche con questo comando, si può tentare di saperlo investigando il responso del comando:

[servizio@server ~]$ ldd /usr/sbin/sshd | grep libwrap
        libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb76e6000)

Nell'esempio mostrato, il server è stato compilato con il supporto libwrap.

Nel seguito compare un esempio del file /etc/ypserv.securenets relativo ad un server 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.  In Debian Wheezy contiene questa configurazione:

[servizio@server ~]$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files nis mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

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

netgroup:       nis

Il documento NIS HOWTO, del luglio 2003, suggerisce invece questa configurazione:

# 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 serve 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, ad es., risolvere un nome di dominio in un indirizzo IP.

Normalmente ai client NIS è reso possibile prendere visione dei soli dati del file /etc/passwd relativi agli utenti non privilegiati.  Esiste la possibilità di limitare ulteriormente questo elenco, ma per semplicità ci si limiterà agli aspetti base e 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 deve avviare il servizio ypserv.  In Debian Wheezy questo si fa lanciando il servizio nis:

[root@server ~]# service nis start
[info] Setting NIS domainname to: internalia.
[....] Starting NIS services: ypserv yppasswdd ypxfrd ypbind[....] binding to YP[FAILer...........................................failed (backgrounded).
. ok

La causa di questo errore appare nel file di log syslog:

[root@server ~]# tail -n1 /var/log/syslog
Oct 23 01:14:40 krill ypbind: Unknown host: principale.internalia

In alternativa si può provare ad eseguire ypbind in modalità debug:

[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'

Se, come in questo esempio, il nome del server NIS non è noto al server DNS, si deve mettere una riga come la seguente nel file /etc/hosts per renderlo noto al sistema:

192.168.1.1	principale.internalia	principale

Fatto questo, tutto bene:

[root@server ~]# service nis start
[ ok ] Starting NIS services: ypserv yppasswdd ypxfrd ypbind.

Questo script avvia non solo il server ypserv, ma anche il programma RPC 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 a ypserv, connessione che continuerà a tentare nel "sottofondo" (background) dopo essersi distaccato dalla console che l'ha mandato in esecuzione.  In tale caso, il server starebbe girando, ma non sarebbe interrogabile dai client.

Adesso si può procedere con la creazione della base dati che NIS userà per fornire i dati che i client chiederanno.
Attenzione: il comando che segue fallisce se il server ypserv non sta girando!

[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'

Controlli

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

oppure:

rpcinfo: RPC: Program not registered
program 100004 is not available

vorrebbe dire che non c'è ancora rpcbind in esecuzione.

Si controlli ora che sia disponibile anche ypbind.  Questo si può vedere con il comando:

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

Nel caso il programma non fosse disponibile, si sarebbe letto un messaggio d'errore come il seguente:

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

La più probabile causa di questo fallimento è, come già spiegato in precedenza, l'impossibilità di risolvere l'indirizzo IP del server ypserv.

Appurato che il programma ypbind sta girando, si può controllare che funzioni a dovere usando un comando client:

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

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.
Configurazione del client


Sull'host deve girare rpcbind 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:

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

Si deve adesso lanciare ypbind perché si connetta al server NIS remoto dal client:

# Su Fedora/RedHat:
[root@client ~]# systemctl start ypbind.service

# Su Debian/Ubuntu:
[root@client ~]# service ypbind start

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 l'host riconosce il server come suo server NIS:

[tizio@client ~]$ ypwhich
principale.internalia

In questo caso, tutto bene.  Si provi allora a 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

Il messaggio d'errore che si legge nella prima riga prodotta dal comando è normale, avendo limitato agli utenti privilegiati 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.  Diversi di questi comandi specifici per NIS sono tuttavia considerati obsoleti, in quanto le versioni più recenti dei normali comandi per il controllo degli stessi dati in locale (dal nome analogo senza il prefisso "yp") funzionano anche in ambiente NIS.

Alcuni diritti riservati dall'autore, Alessandro Selli (http://alessandro.route-add.net)
Distribuito sotto licenza Creative Commons Attribuzione - Non commerciale 3.0 Creative Commons Creative Commons Attribuzione Creative Commons Non Commerciale
< Torna al livello superiore <
<< Torna alla pagina inziale <<