Installato il pacchetto nis, si è specificato come nome di dominio il dominio DNS dell'host, in questo esempio mydomain.org. Viene salvato in /etc/defaultdomain (vedi avanti come cambiarlo).

Fare attenzione al contenuto dei seguenti file:

• /etc/defaultdomain
• /etc/default/nis
• /etc/hosts
• /etc/ypserv.securenets

Conviene che in /etc/hosts i nomi dei server NIS siano presenti sia nella versione breve che in quella completa, qualcosa del tipo:

127.0.0.1       localhost.localdomain localhost
10.0.1.47       nisserver.mydomain.org nisserver

Poiché vogliamo essere NIS master server, in /etc/default/nis si imposta

NISSERVER=master

Per decidere chi ha accesso al server NIS si mette in /etc/ypserv.securenets una riga come segue (commentando la riga che garantisce accesso a tutti):

255.255.255.0 10.0.1.0

NOTA: se il server NIS ha più di una interfaccia di rete e si vuole rispondere a richieste broadcast da parte dei client, è opportuno aggiungere in /etc/ypserv.securenets anche tutti gli indirizzi alternativi del server NIS, oltre all'indirizzo loopback:

# Always allow access for localhost
255.0.0.0       127.0.0.0

# Allow access from localhost (when proxying broadcast requests?)
# See Debian bugs:
# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280537
# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=126177
# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329382
255.255.255.255 192.168.144.2

infatti pare che ypserv - in risposta ad una richiesta broadcast di un client - inoltri a sé stesso una richiesta broadcast utilizzando l'indirizzo IP aggiuntivo che non è nelle securenets, facendo fallire la richiesta del client e generando questo errore in syslog:

ypserv[9960]: refused connect from 192.168.144.2:46594 to procedure ypproc_domain_nonack (mydomain.org,;0)

Bisogna inizializzare il database del dominio NIS, che verrà tenuto nella directory /var/yp/mydomain.org/. Si usa il comando

/usr/lib/yp/ypinit -m

Per testare il corretto funzionamento del server si può usare il comando ypcat passwd. Mostra tutte le voci del database “passwd” presente nel server NIS. Quali database ci sono sul server NIS lo si vede dal file /var/yp/nicknames. Per es. le shadow password si vedono con ypcat shadow.byname.

Per modificare il nome del dominio NIS da mydomain.org a newdomain.org:

/etc/init.d/nis stop
vi /etc/defaultdomain
rm -r /var/yp/mydomain.org
domainname newdomain.org
/usr/lib/yp/ypinit -m
/etc/init.d/nis start

Invece di usare i file in /etc/ (passwd, group, …), si vogliono usare delle copie in /var/yp/ypfiles. Modificare /var/yp/Makefile:

YPSRCDIR = /var/yp/ypfiles
YPPWDDIR = /var/yp/ypfiles

Si deve editare anche /etc/default/nis:

YPPWDDIR=/var/yp/ypfiles

Per fare in modo che ypinit riesca a generare i database necessari bisogna creare i seguenti file nella directory /var/yp/ypfiles/:

Dopo aver modificato il contenuto di tali file bisogno aggiornare lo stato del server NIS:

make -C /var/yp

Per far partecipare gli utenti NIS a gruppi di sistema (ad esempio plugdev, lpadmin, ecc. di Ubuntu) bisogna aggiungere le voci opportune in /var/yp/ypfiles/group e modificare il valore di MINGID in /var/yp/Makefile in modo che tali gruppi siano esportati via NIS.

Si installa il pacchetto nis. Chiunque voglia essere NIS client (eventualmente anche il NIS server stesso) deve impostare NISCLIENT=true nel file /etc/default/nis.

La GNU C Library fornisce i servizi ad esempio per avere l'elenco degli utenti. Bisogna integrare gli utenti standard Unix con quelli NIS, il file di configurazione da verificare è /etc/nsswitch.conf.

Per integrare gli utenti e i gruppi NIS in quelli standard unix si devono modificare i file /etc/passwd, /etc/shadow e /etc/group aggiungendo le seguenti righe rispettivamente:

+::::::

+::::::::

+:::

Verificare nel file /etc/nsswitch.conf che i servizi passwd, group, e shadow includano la sorgente compat, che significa utilizzare la sorgente files (i tradizionali file Unix /etc/passwd, ecc) con l'estensione NIS dovuta alle righe aggiuntive vista sopra.

In alternativa si può indicare in /etc/nsswitch.conf la sorgente files ed esplicitamente la sorgente nis, in questo caso le righe aggiuntive con il prefisso + non sono necessarie. In questo caso il file /etc/nsswitch.conf contiene qualcosa del genere:

passwd:         files systemd nis
group:          files systemd nis
shadow:         files nis

ATTENZIONE: Questa modalità non è compatibile con il demone accountsservice utilizzato ad esempio da Ubuntu 20.4. In questo caso l'elenco degli utenti non viene integrato con le informazioni NIS e quindi gli utenti NIS non vengono elencati nel greeter di LightDM.

La ricerca del NIS server avviene tramite richieste broadcast sulla rete locale. Per evitarle (potrebbero fallire per regole di firewall) si dichiarano esplicitamente i server in /etc/yp.conf:

# We states NIS servers explicitly to avoid broadcast requests.
ypserver bianca.rigacci.org
ypserver neve.rigacci.org

Un altro motivo per cui la richiesta broadcast potrebbe fallire è se il server NIS è multihomed (ha più di una interfaccia di rete), vedi la nota sopra riguardo ypserv.securenets.

L'utente autenticato via NIS può cambiare la propria password con yppasswd. Durante il cambio password il server NIS indica al client il nome dello stesso server, quindi il client deve poterlo risolvere in indirizzo IP. Verificare le opportune impostazioni di /etc/hosts, ecc.

Configurare l'host che dovrà essere slave server come se fosse un NIS client, quindi mettere in /etc/default/nis la riga NISSERVER=slave.

Sul master modificare /var/yp/Makefile mettendo NOPUSH=“false”, quindi eseguire /usr/lib/yp/ypinit -m.

Riavviare NIS sullo slave ed eseguire /usr/lib/yp/ypinit -s <master_server> per trasferire il contenuto dei file.

Le repliche dovrebbero avvenire automaticamente dal master allo slave. Nel caso qualcosa vada storto è opportuno configurare un cron job sullo slave come suggerito dal file nis.debian.howto:

20 *    * * *    root  /usr/lib/yp/ypxfr_1perhour >/dev/null 2>&1
40 6    * * *    root  /usr/lib/yp/ypxfr_1perday  >/dev/null 2>&1
55 6,18 * * *    root  /usr/lib/yp/ypxfr_2perday  >/dev/null 2>&1

Se il server NIS è protetto da firewall che filtra in base al numero di porta si deve avere l'accortezza di impostare i vari server su porte predefinite (non su porte dinamiche come sarebbe l'impostazione predefinita) ed aprire di conseguenza il firewall. Come per il servizio NFS la gestione delle porte è affidata a portmapper, vedere in proposito la pagina relativa.

In particolare si devono indicare le porte per ypserv, yppasswdd, ypbind, fypxfrd.

In un sistema Debian vedere /etc/default/nis:

YPSERVARGS="--port 808"
YPPASSWDDARGS="--port 600"

Attenzione al percorso delle home directory, se si sceglie qualcosa di diverso da /home/ potrebbe essere necessario aggiustare qualcosa, come la configurazione di apparmor nelle recenti versioni Ubuntu GNU/Linux (es. 12.04).

Il rischio è di incappare in errori “Permission denied” nella lettura o scrittura di file della propria home directory, nonostante che i permessi sembrino a posto, vedere ad esempio il bug 778638.

Ad esempio se le home directory sono state montate su /nfshome/, lanciando evince si può notare l'errore:

(evince:21345): Gtk-WARNING **: Attempting to read the recently used resources file at
    `/nfshome/francesco/.local/share/recently-used.xbel',
    but the parser failed: Failed to open file '/nfshome/francesco/.local/share/recently-used.xbel': Permission denied.

contestualmente il kernel logga:

Jan  9 11:35:02 nisclient kernel: [ 5422.898561] type=1400 audit(1357727702.213:1085):
    apparmor="DENIED" operation="chmod" parent=12077 profile="/usr/bin/evince"
    name="/nfshome/francesco/.local/share/recently-used.xbel" pid=12470 comm="evince"
    requested_mask="w" denied_mask="w" fsuid=1003 ouid=1003

In questo caso è sufficiente modificare il file /etc/apparmor.d/tunables/home impostando:

@{HOMEDIRS}=/home/ /nfshome/

Sui client NIS è opportuno installare il pacchetto nscd che tiene in cache le informazioni nsswitch (passwd, group, ecc.) senza doverle richiedere continuamente al server NIS.

Potrebbe capitare che sul server viene cambiato un UID oppure un GID e il client non se ne accorge immediatamente; la cache di NSCD resiste anche al reboot perché viene salvata in /var/cache/nscd/

Per invalidare la cache di nscd su un particolare database (es. passwd) si può usare il comando:

nscd -i passwd

Si può anche configurare il time to live e la persistenza della cache intervenendo su /etc/nscd.conf sulle righe del tipo:

positive-time-to-live   passwd  600
persistent              passwd  yes

After installing an Ubuntu 18.04 as a NIS client with home directories mounted over NFS, we noticed very long times required to complete the login. Even on the tty1 console, there was a wait time of about 25 seconds after typing the passowrd, before to get the command line prompt.

The only apparent error message found in the syslog was:

systemd-logind[2133]: do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted

A nice solution was to install the nscd package. The complete story was a bit more complicated, the right direction was found in the following posts:

• systemd-logind: do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted
• systemd-logind's IP sandbox breaks nss-nis and suchlike #7074

One user pointed out that the bug affects also what is reported in /run/user/, where the NIS user logged-in (after the long wait) was missing. Other users suggested to edit the file /lib/systemd/system/systemd-logind.service, commentig-out a line from the [Service] section:

IPAddressDeny=any