NIS is Sun's Network Information Service. It was formerly known as Yellow Pages, but after a trademark dispute with British Telecom, Sun changed the name to Network Information Service. The history of Yellow Pages is why many NIS-related commands begin with yp.
NIS is a simple directory service whose main purpose is to allow remote authentication for systems on local network systems. NIS allows information such as passwd and group files, sendmail aliases, automount maps, and hosts files to be kept on a central server. Each system in the NIS domain runs the NIS client, ypbind, to find a server and retrieve the appropriate maps from it.
NIS uses a master/slave server configuration that resembles DNS. The master NIS server holds the NIS map files. Changes to the maps are then pushed to any slave servers. While an NIS domain can operate with only one server, it is best to have at least one slave server for redundancy.
You must run the RPC portmapper (/usr/sbin/portmap) to run NIS . The RPC portmapper servers convert the RPC program numbering to TCP/IP or UDP/IP protocol port numbers.
Most Linux distributions ship with NIS Version 2. NIS Version 3 is known as NIS+ and is not in widespread use.
Before setting up servers or clients, you must decide on a domain name for your NIS setup. The domain is used to ensure that you're talking to the right NIS servers . This domain name has nothing to do with DNS, your DNS domain name, or your hostnames. Most directory administrators use the same domain in NIS as in DNS to simplify network administration, but the NIS domain could be completely different from the DNS domain. The command domainname or ypdomainname are usually links to the hostname binary and can be used to set the NIS domain. This has nothing to do with the hostname command.
You should have at least two NIS servers, one master and one slave. If one of them fails, the clients using it will switch to the other automatically. To set up a server, start by installing the NIS and/or YP packages in your distribution. On the server side, you have the tools shown in Table 39-1:
Table 39-1. NIS server-side tools
Tool |
Description |
---|---|
ypserv |
The NIS server program |
yppasswdd |
Server that handles the NIS password changes |
yppush |
Notifies the slave servers when changes are made to master databases |
ypinit |
Installs and builds an NIS database |
Sometimes some of these have an rpc. prefix in their filenames. After having the server tools installed, you must configure and initialize them. Do the following to get a master server :
All planned NIS servers, masters, and slaves must be present in your /etc/hosts file. Following the IP address, place the fully qualified domain name, which is the hostname including the DNS domain, then the bare name and any aliases, like this:
10.0.0.5roke.example.com roke mailserver nisserver
Configure your domain name. On Debian, simply put the name in the /etc/defaultdomain file. On Red Hat you must set the NISDOMAIN
variable to your domain name in /etc/sysconfig/network.
Set the correct networks in /etc/ypserv.securenets. If your internal network uses the 10.0.0.0/255.255.255.0 subnet, for instance, the file should look something like this:
# Always allow access for localhost 255.0.0.0 127.0.0.0 # This line gives access to ourselves 255.255.255.010.0.0.0
Start the master server processes. On Debian, you simply set NISSERVER=master
in /etc/default/nis and start the needed services with /etc/init.d/nis start. On Red Hat you must start all the master server services one by one, using the scripts installed in /etc/init.d:
#ypserv start
#yppasswdd start
#ypxfrd start
#ypbind start
You can execute ypserv -d to run the process in the foreground and stream debug messages to console output. If you type ypserv without the -d option, the process will run in the background and just report errors (access violations, dbm failures) using the syslog facility.
Initialize the server maps or databases. Before doing this, you need an /etc/networks file, even if it's empty. Then you can do the initialization of the master server:
/usr/lib/yp/ypinit -m
This populates the databases from the contents of your master server system files. The work is done in /var/yp/Makefile. By customizing this file, you can change the location of the master files. Most often people change the location of the master passwd and groups files. If you do that, you should take a look at the yppasswdd manpage to tell that command where the master files are.
If you run ypcat passwd now, you should get a listing of all or some of the entries from your /etc/passwd file.
The tools provided for manipulating clients arelisted in Table 39-2.
Table 39-2. NIS client-side tools
Tool |
Description |
---|---|
ypwhich | |
ypcat |
Prints the values of all keys in the specified NIS map |
yppoll |
Returns the version and master server of the specified NIS map |
ypmatch |
Prints the values of specified keys from an NIS map |
ypdomainname |
Prints or sets the name of the NIS domain |
yppasswd |
Changes passwords in the NIS server |
yppasswd is needed because the standard passwd command can change only passwords in /etc/passwd and /etc/shadow, but that is not very well-suited for a network information service. You need a special command that is aware of NIS to update the password on the master server.
Setting up an NIS client is simple. The following steps cover the process:
Set the NIS domain name. On Debian, /etc/defaultdomain should contain the domain name. On Red Hat, set NISDOMAIN
in /etc/sysconfig/network.
Start ypbind. On Debian, set NISSERVER=false
in /etc/default/nis (unless you're on your master server, of course) and then run /etc/init.d/nis start. On Red Hat, simply run /etc/init.d/ypbind start. If your server is not on the same IP subnet, you must customize /etc/yp.conf and set the server name there.
Customize /etc/nsswitch.conf. All the name services that should get information from NIS should have nis
somewhere on the line. This includes the whole of the NIS map contents. On the passwd, group
, and shadow
lines, you should always put file
in front of nis
.
NIS offers an access control method based on users and groups. The entries for passwd, group
, and shadow
accept a special compat
option, which enables you to use a +
in the corresponding files. This is described later.
When you now enter getent passwd, you should see the contents of your local passwd file as well as the contents of the NIS passwd file.
After ypbind is running, you can see what NIS server it has bound itself to with ypwhich. ypcat
map
lists the contents of the specified map. ypmatch
keymap
lists just the specified entry of the specified map.
When compat
is listed as the passwd, shadow
, and group
source in nsswitch.conf, you can use a special syntax in the files. We'll use the password file as an example, but the same goes in the other files, save for the number of colons.
To allow access to the system to the users janl and killroy, the two first lines in the followng example do the job. The third line illustrates group access, allowing an NIS netgroup called ftpusers in as FTP users only. Note that even if janl and killroy are members of this netgroup, they still get full access, because they are listed in the password file before the netgroup line. The last line includes all the other users in NIS but sets their password to *
and shell to /etc/nologin, barring them from using the system.
+janl:::::: +killroy:::::: +@ftpusers::::::/etc/ftponly +:*:::::/etc/nologin
Most often, only the last form is used in group files. But it is easier and faster to just put groups: files, nis
in nsswitch.conf.
Once a host is an NIS client, it can be set up as a slave by performing these steps:
Ensure that your slave server is listed in the master's /etc/hosts file and vice versa.
Configure the slave's /etc/ypserv.securenets file.
The master must know that it has slaves. On the master, set NOPUSH
to false
in /var/yp/Makefile.
On the master, run /usr/lib/yp/ypinit -m again. Add your slave when it asks for it.
Back on the slave, start the slave server processes. On Debian, set NISSERVER=slave
in /etc/default/nis and run /etc/init.d/nis stop;/etc/init.d/nis restart (using restart because it's already started as a client). On Red Hat, start the server process with: /etc/init.d/ypserv start.
Initialize the slave server by running /usr/lib/yp/ypinit
-s
master-server
.
Run ypcat -h localhost passwd to verify that the slave works correctly.
Because NIS servers do not autosynchronize, you need to configure synchronization on the master. Put the following in /etc/cron.d/nis to ensure that it updates the slaves regularly:
10 * * * * root /usr/lib/yp/ypxfr_1perhour >/dev/null 2>&1 20 6,18 * * * root /usr/lib/yp/ypxfr_2perday >/dev/null 2>&1 40 5 * * * root /usr/lib/yp/ypxfr_1perday >/dev/null 2>&1
The hourly job transfers the passwd, shadow, and group maps. The twice daily job transfers hosts, netgroups, and the networks maps. The once daily file just transfers the protocols, RPC, and services maps. Of course, there is nothing wrong with running these more often, but they always transfer the complete maps, so on large sites with thousands of entries in the maps and multiple slave servers, they're going to take some time.
These map transfer scripts and cron times should be modified to meet your needs, such as including new maps and excluding old ones, as in this example:
[root@pirarucu yp]# cat ypxfr_1perhour
#! /bin/sh
YPBINDIR=/usr/lib/yp
MAPS_TO_GET="passwd.byname passwd.byuid shadow.byname publickey.byname
hosts.byname hosts.byaddr netgroup netgroup.byuser netgroup.byhost
group.byname group.bygid protocols.byname protocols.bynumber
networks.byname networks.byaddr rpc.byname rpc.bynumber services.byname
ypservers auto.home seismic_users"
for map in $MAPS_TO_GET
do
echo "Syncing map: $map ..."
$YPBINDIR/ypxfr -c -s ep.bc.nismaster.gov.br -d ep.bc.nisslave.gov.br $map
done
Don't forget to make all the NIS processes start when the system boots.
During the previous setup, you may have noticed that NIS does not have a passwd file, but it does have passwd.byname and passwd.byuid. If you look in /var/yp/
domain_name
, where domain_name
is the NIS domain name, you'll see the map names that NIS has as shown in a listing like this:
# ls /var/yp/nismaster.gov.br
group.bygid netgroup.byhost protocols.byname services.byservicename
group.byname netgroup.byuser protocols.bynumber shadow.byname
hosts.byaddr netid.byname rpc.byname ypservers
hosts.byname passwd.byname rpc.bynumber
netgroup passwd.byuid services.byname
These files are provided for the standard Unix and Linux system calls that do name resolution, such as getpwnam and getpwuid. When getting information from files, these functions have to iterate through the whole /etc/passwd file to find the given name or UID. In NIS, instead, they do a lookup into the map indexed by the username or the UID, namely passwd.byname and passwd.byuid. The same goes for the lookup functions for the other system files that are in NIS. The following example demonstrates a lookup by name and UID in the NIS passwd files.
#ypmatch killroy passwd.byname
killroy:x:1002:100::/home/killroy:/bin/bash #ypmatch 1002 passwd.byuid
killroy:x:1002:100::/home/killroy:/bin/bash
To obtain the complete NIS passwd file, one can iterate through the whole map, and any of the maps will do. That is what ypcat does. To make using NIS a bit more like the system files, there are map aliases so that you can refer to the databases by the name you're used to. passwd
is a alias for passwd.byname
, and so on for all the other maps. Table 39-3 shows these aliases, or nicknames.
Check the map nickname translation table with the command ypwhich -k.
If you ever suspect that your NIS maps are out of sync, you can do what the master server does: poll their versions to compare them:
#yppoll -h localhost passwd.byname
Domain example.com is supported. Map passwd.byname has order number 1076234245. [Sun Feb 8 10:57:25 2004] The master server is debian.example.com. #yppoll -h roke passwd.byname
Domain example.com is supported. Map passwd.byname has order number 1076234245. [Sun Feb 8 10:57:25 2004] The master server is debian.example.com.
These maps are the same. But if the slave is not up-to-date and you want to force updating just one map on one or more servers, use yppush. On the master, enter something like this:
# yppush -h roke passwd.byname
If you do not include the -h option, the map will be pushed to all the slaves. You can also enter several -h options to push it to several named slaves.
Netgroups have been mentioned before in this chapter and also in relation to NFS. They are most useful as a mechanism to support access control for machines (in the password file as shown earlier) and for restricting NFS shares to certain hosts. The general format is as follows:
netgroup
(host,user,domain
) |netgroup
[ , ... ]
The actual use may be clearer from the following example:
nfsservers (server1,,), (server2,,) nfsclients (client1,,), (client2,,), nfsservers serverusers (,user1,), (,user2,)
If you use compat
for passwd:
in /etc/nsswitch.conf, you can now enter +@serverusers::::::
at the end of the /etc/passwd to allow the NIS users user1 and user2 access. You may need to put the equivalent entries in your /etc/shadow file as well.
On NFS servers you can use @
netgroup
syntax in /etc/exports instead of hostnames. For instance:
/var/export @nfsservers(rw,no_root_squash) @nfsclients(rw,root_squash)
If you try to use ypcat on the netgroup map, it won't tell you much, because the netgroup names are only stored as keys and won't be shown. Add the -k option to se the keys as well, as shown here:
# ypcat -k netgroup
nfsservers (server1,,), (server2,,)
serverusers (,user1,), (,user2,)
nfsclients (client1,,), (client2,,), nfsservers
The utility rpcinfo can be used to detect and debug a variety of failures. Just type rpcinfo -p hostname to check how the things are going in your NIS server. Here's an output of a functional NIS server:
# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
390011 4 tcp 32772
390008 1 tcp 32776
100004 2 udp 852 ypserv
100004 2 tcp 855 ypserv
100007 2 udp 725 ypbind
100007 2 tcp 728 ypbind
100011 1 udp 840 rquotad
100011 1 tcp 857 rquotad
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs
100021 1 udp 33745 nlockmgr
100021 4 tcp 36331 nlockmgr
100005 1 udp 853 mountd
100005 1 tcp 865 mountd
100005 2 udp 853 mountd
100024 1 udp 32768 status
100024 1 tcp 32769 status
The output from rpcinfo shows the RPC program and version numbers, the protocols supported, the IP port used by the RPC server, and the name of the service. If rpcinfo times out while attempting to reach the remote machine and reports an error, check whether the portmapper service is alive.
# /etc/init.d/portmap status portmap (pid 2124) is running...