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).
Having a local client means adding the computer to an existing NIS domain:
First, we must verify that the netbase (basic TCP/IP network), portmap (server that turns RPC numbers into DARPA ports and that is necessary for programs that execute RPC, including NFS and NIS) and nis (specific) packages have been installed. We recommend using the kpackage command or directly with apt-get (we can check if this is installed with apt-cache pkgnames) in text mode. When installing the NIS package, you will be prompted for a domain (NIS domainname). This is a name that will describe the set of machines that will use NIS (it is not a host name). Bear in mind that NISPirulo is different to Nispirulo as a domain name. To configure this domain, you may use the command nisdomainname, a domain which will be saved in /proc/sys/kernel/domainname.
Firstly, we must start up the portmap service with:
We can check whether these are active using rpcinfo -p.
If the NIS server is not local, we must use the ypbind command. The ypbind command is used to find a server for the specified domain, whether it is through a broadcast (not recommended, as it is not secure) or through searching the server indicated in the configuration file /etc/yp.conf (recommended). The /etc/yp.conf file has the following syntax:
domain nisdomain server hostname: indicates that the hostname should be used for the nisdomain. It is possible to have more than one entry of this type for the same domain.
domain nisdomain broadcast: indicates that broadcast should be used on the local network to discover a server with a nisdomain.
ypserver hostname: indicates that hostname should be used as a server. It is advisable to use this line (ypserver) where we must enter the IP address of the NIS server. If the name is specified, make sure that the IP can be found by DNS or that it appears in the /etc/hosts file, as, otherwise, the client will be blocked.
Start up the service by executing:
This steps must start up, the NIS client will be working (this can be confirmed with rpcinfo or localhost ypbind, which will show the two versions of the active protocol) or we can use the ypcat mapname command (for example, ypcat passwd, which will show the NIS users defined in the server) where the relationship of the mapnames to the tables in the NIS database are defined in /var/yp/nicknames.
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:
|shadow: compat ...|
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.
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):
We must make sure that /etc/hosts contains all the machines that will form part of the domain in the FQDN (fully qualified domain name) format, which is where the IP, the name and domain and the name without the domain of each machine appears (for example, 192.168.0.1 pirulo.remix.com pirulo). This is only necessary in the server, as the NIS does not use DNS.
In addition, it exists in the /etc/defaultdomain file with the chosen domain name. Do not use your DNS domain so that you do not incur in any security risks, unless you appropriately configure the files /etc/ypserv.securenets, which indicates the sites from which the clients will be able to connect with a netmask/network pair, and /etc/ypserv.conf, which carried out a more detailed control because it indicates which hosts can access which maps, for example: passwd.byname o shadow.byname.
Verify that NISSERVER = master exists in /etc/default/nis.
For security reasons, it is possible to add the local network number to the /etc/ypserv.securenets file.
Start up the server executing the /etc/init.d/nis stop command and then the /etc/init.d/nis start command. This command will start up the server (ypserv) and the password daemon (yppasswdd), which may be consulted if it is active with ypwich -d domain.
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:
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:
/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.