7.3. NIS (YP)

In order to facilitate the administration and make the system more user-friendly, in networks of different sizes that execute GNU/Linux (or Sun's Solaris or any other operating system that supports this service), there are Network Information Services, NIS (or yellow pages, YP, Sun's original name). GNU/Linux can provide support as an NIS client/server and can act as a client ("beta" version) of NIS+, which is a safer and more optimised version of NIS. The information that can be distributed in NIS is: users (login names), passwords (/etc/passwd), user directories (home directories), group information (/etc/group), which has the advantage that, from any client machine or from the server itself, the user may connect with the same account and password and to the same directory (although the directory must have been previously mounted on all the machines with NFS or using the automount service). [Miq01, Kuk03]


The NIS architecture is of the client-server type, in other words, there is a server that will have all the databases and some clients that will consult these data in a transparent manner for the user. For this reason, we must consider configuring the 'reinforcement' servers (called secondary servers) so that users will not be blocked because the primary server is unavailable. This architecture is called multiple server architecture (master+mirrors-clients).

7.3.1. ┐How do we initiate a local NIS client in Debian?

Having a local client means adding the computer to an existing NIS domain:

7.3.2. What resources must be specified in order to use NIS?

Let us assume that we have installed one of Debian's latest distributions (for example, 3.0 Woody or 3.1 Sarge), which supports Libc6 (the same for FC4 or higher) and that we want to configure the system so that the users of one client machine may access the information in the server. In this case, we must send the login request to the appropriate databases by:

1) Verify that the /etc/nsswitch.conf and ensure that the passwd, group, shadow and netgroup entries are similar to:

passwd: compat
group: compat
shadow: compat ...
netgroup: nis

See man nsswitch.conf for the syntax of this file.

2) Add the following line in the NIS client machines, in the /etc/passwd file at the end of the file (this will indicate that if the user is not local, the NIS server will be asked):

+:::::: (one '+' and six ':')

3) It should be remembered that in /etc/passwd we can use the + and the ? in front of each user name in /etc/passwd, to include/override the login of these users. If we are using passwords with shadows (more secure, as it will not allow a normal user to see the encrypted passwords of other users), the following line must be added at the end of the /etc/shadow file:

+:::::::: (one '+' and eight ':')

4) The following line must also be added at the end of /etc/group:

+::: (one '+' and three ':')

5) The searches for hosts (host lookups) will be carried out through DNS (and not NIS), which means that, for Libc6 applications, in file /etc/nsswitch.conf we will have to change the hosts entry for the following line: hosts: files dns. Or, if we prefer to do this using NIS, hosts: files nis. For Libc5 applications, we must modify the /host.conf file by entering order hosts, DNS or order hosts, NIS, as required.


With this configuration, it will be possible to establish a local connection (over the NIS client) with a user that is not defined in the /etc/passwd file, in other words, a user defined in another machine (ypserver).

For example, we may execute ssh -l user localhost, where the user is a user defined in ypserver.

7.3.3. How should we execute a master NIS server?

Let us assume that we have installed the nis package and portmap (and portmap is working) and that the data bases of the NIS have been created (see the following section):

7.3.4. How should we configure a server?


The server is configured with the command /usr/lib/yp/ypinit -m; however, it is necessary to verify that the /etc/networks file exists, as it is essential for this script.

If this file does not exist, create an empty one with touch /etc/networks. It is also possible to make the ypbind client execute on the server; in this way, all the users entered by NIS, as mentioned above, modifying the /etc/passwd file, where all the normal entries before the line +:::::: will be ignored by the NIS (they may only access locally), whereas the subsequent ones may access through the NIS from any client. [Miq01]

Consider that as of this moment, the commands for changing the passwd or user information such as passwd, chfn, adduser are no longer valid. Instead, we will have to use commands such as yppasswd, ypchsh and ypchfn. If we change the users or modify the abovementioned files, we will have to rebuild the NIS tables by executing the make command in the /var/yp directory to update the tables.

Bear in mind that the Libc5 does not support shadow passwords, which means that shadow should not be used with NIS, if we have applications with Libc5. There will not be a problem if we have Libc6, which accepts NIS with shadow support.

Configuring a slave server is similar to configuring a master server, except in that NISSERVER = slave in /etc/default/nis. On the master, we must indicate that it has to distribute the tables automatically to the slaves by entering NOPUSH = "false" in the /var/yp/Makefile file.

Now we must tell the master who its slave is, by executing:

/usr/lib/yp/ypinit -m

and entering the names of the slave servers. This will rebuild the maps but it will not send the files to the slaves. For this, on the slave, execute:

/etc/init.d/nis stop

/etc/init.d/nis start

and, finally:

/usr/lib/yp/ypinit -s name_master_server.

In this way, the slave will load the tables from the master.

It would also be possible to place the nis file in the /etc/cron.d directory with a content similar to (remember to perform an chmod 755 /etc/cron.d/nis):

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

With which we will ensure that all the changes in the master will be transferred to the slave NIS server.

Recommendation: After using adduser to add a new user on the server execute make -C /var/yp to update the NIS tables (and do this whenever any user characteristic changes, for example, the password with the passwd command, which will only change the local password and not the NIS password). To check that the system is working and that the user is registered in the NIS, you may execute ypmatch userid passwd where userid is the user previously registered with adduser and after performing the make. To verify that the NIS system is working, you may use the script of http://tldp.org/HOWTO/NIS-HOWTO/verification.html, which permits a more detailed verification on the NIS.