Basics of NIS management (Managing NFS and NIS, 2nd Edition)

3.2. Basics of NIS management

Now that we have laid a conceptual foundation, let's look at how to set the machinery in motion. Basic NIS management involves setting up NIS servers and enabling NIS on client hosts. Server management includes three tasks:

Installing a new NIS environment, building both master and slave servers.
Starting the ypserv daemon, which enables the system to act as an NIS server.
Adding new slave servers when growth of your network or NIS performance requires more server bandwidth.

Enabling NIS on a client requires two tasks:

Modifying the client's administrative files so that the client can take advantage of NIS.
Starting the ypbind daemon, which allows the client to make NIS requests.

In this section, we'll review the procedures required to initialize NIS, set up slave servers, and configure NIS clients.

3.2.1. Choosing NIS servers

First, a few words on how to plan your network. One of the most important decisions you will make is which systems will be your NIS servers. Because a client gets almost all of its configuration information from NIS, servers must be highly available in measures of both uptime and request handling bandwidth. If an NIS server stops responding or replies too slowly, the client tries to find another, less-loaded server. While this is an argument for at least one slave server for each master server, it supports an equally strong case for building NIS on reliable hosts. An interruption in NIS service affects all NIS clients if no other servers are available. Even if another server is available, clients will suffer periodic slowdowns as they recognize the current server is down and hunt for a new one.

Use your judgement in defining "highly available." You know what machines have troublesome hardware or are likely to be commandeered for a trade show, and would therefore make poor NIS servers. Request handling bandwidth is much harder to measure, because it is a product of network loading, CPU utilization, and disk activity. In later chapters, we'll come back to choosing the number of NIS servers and identifying signs that you have too few servers.

A second imperative for NIS servers is synchronization. Clients may get their NIS information from any server, so all servers must have copies of every map file to ensure proper NIS operation. Furthermore, the data in each map on the slave servers must agree with that on the master server, so that NIS clients cannot get out-of-date or stale data. NIS contains several mechanisms for making changes to map files and distributing these changes to all NIS servers on a regular basis.

3.2.2. Installing the NIS master server

We'll assume that you've already done your planning and decided that you need a single NIS domain, which will be called bedrock.[5] Before going any further, make sure you've set the NIS domain name on the master server using domainname. We'll install a server for an NIS domain named bedrock:

[5]The multiple-domain case is really no different than this; you just have to remember which systems belong to which domain.

newmaster# domainname bedrock

A line like this will usually appear in the /etc/rc2.d/S69inet file for every host (server and client) in the domain. Setting the domain name if you aren't using NIS is harmless. Reminder: you are setting the NIS domain name here, not the DNS domain. See Section 3.3.8.1, "Internet domains versus NIS domains" later in this chapter.

Note that on Solaris, the domain name setting will not survive a server reboot unless it is stored in the /etc/defaultdomain file. So, you need to do:

newmaster# domainname > /etc/defaultdomain

After establishing the domain's name, you should go over all the system's administrative files with a fine-toothed comb: make sure they contain only the entries you want, no more, and no less. It is important for your network to start with correct map information. Which administrative files NIS cares about varies, but generally includes the information shown in Table 3-1.

Table 3-1. Files managed by NIS

File	Contains
/etc/auto_*	Automounter maps
/etc/bootparams	Information about diskless nodes
/etc/ethers	Ethernet numbers (MAC addresses)
/etc/group	User groups
/etc/hosts	Hostnames and IP addresses
/etc/inet/ipnodes	Hostnames, IPv4, and IPv6 addresses
/etc/mail/aliases	Aliases and mailing lists for the mail system
/etc/netgroup	Netgroup definitions (used by NIS)
/etc/netid	Netname database for RPC/dh (RPC/dh is discussed in Section 12.5.4, "AUTH_DH: Diffie-Hellman authentication")
/etc/netmasks	Network "masks"
/etc/networks	Network addresses
/etc/passwd	Usernames and user IDs
/etc/protocols	Network protocol names and numbers
/etc/publickey	Public key database for RPC/dh
/etc/rpc	Remote procedure call program numbers
/etc/services	Network port numbers and service names
/etc/shadow	User passwords

With the exception of netgroup, these are all standard Solaris administrative files. Once NIS is running, it will replace or supplement all of these files, depending on how /etc/nsswitch.conf is configured. /etc/netgroup is an administrative file that is only consulted via the NIS database. Before creating it, see Section 3.3.2, "Netgroups" later in this chapter.

Make sure that your /etc/passwd file on the master server does not include the entry:

+::0:0::

This entry is used by NIS client hosts to indicate that they want to include NIS map information in their password files. On the NIS master server, all entries in the /etc/passwd file get put into the passwd NIS map. If you leave this NIS "marker" in the master server's /etc/passwd file, your NIS password file map will contain an entry for a user named +. If you do leave the entry in the password file, be sure to put an asterisk (*) in the password field so that this "user" will not have a valid password:

+:*:0:0::

Note that this will not work under all operating systems; in particular you must not use an asterisk in SunOS 4.0 or later. If you cannot fill the password field of the NIS "marker" entry, make sure you remove this entry if you decide not to run NIS at some future point. Also, in Solaris, the plus sign entry has been deprecated in favor of the use of the Name Service Switch, via the nsswitch.conf file.

If you are using NIS to manage any local files (company phone lists, etc.), you must also make sure that your local source files are up-to-date. Once you have established the domain's name and "purified" the master server's source files, you're ready to initialize a master server. To do so, you will use the ypinit utility. You will first need to ensure that ypinit gets its naming information from files:

newmaster# cp /etc/nsswitch.files /etc/nsswitch.conf

At this point, you are quite close to creating the NIS maps via the ypinit utility. However, there is one security issue you need to be aware of. The ypinit utility will generate maps from the set of files listed in Table 3-1. One of these files is /etc/shadow, which contains a one-way hash of the password for every account name listed in /etc/passwd. If you look at /etc/shadow, you should see something like:

root:eOUqsdfpdIaiA:6445::::::
daemon:NP:6445::::::
bin:NP:6445::::::
sys:NP:6445::::::
adm:NP:6445::::::
lp:NP:6445::::::
uucp:NP:6445::::::
nuucp:NP:6445::::::
listen:*LK*:::::::
nobody:NP:6445::::::
noaccess:NP:6445::::::
nobody4:NP:6445::::::
stern:aSuxcvmyerjDM:6445::::::
mre:96wqktpdmrkjsE:6445::::::

The fields are separated by colons (:). The first field is the name of the account or login. The second field is the one-way hash. Note that the "system" accounts, except for root, have a password hash of NP or *LK*. These are not valid hashes, so the accounts are effectively locked. The nonprivileged accounts, such as stern and mre, have a valid password hash. It is safe to put the locked accounts in the NIS passwd map, because the password hash is of no use to an attacker. It is safe to put the nonprivileged accounts in the map because they don't have privileges. However, it is not safe for the root account to be put into NIS. The reason is that if an attacker obtains the hash for root, he can perform an off-line brute force attack to determine the root password of the master NIS server. With that password, the attacker could render havoc on your network.

Thus, you must take steps to ensure that the passwd map does not have a root entry. The ypinit utility will invoke the make utility on /var/yp/Makefile. Then Makefile will by default get the passwd map contents from /etc/passwd and /etc/shadow, but by setting the PWDIR Makefile variable to something else, you can ensure that ypinit will create the passwd map without root in it. So do the following:

newmaster# mkdir /etc/nispw
newmaster# chmod 0700 /etc/nispw
newmaster# grep -v '^root:' /etc/passwd > /etc/nispw/passwd
newmaster# grep -v '^root:' /etc/shadow > /etc/nispw/shadow
newmaster# vi /etc/passwd /etc/shadow  # delete the nonprivileged entries,
                                       # e.g., stern and mre
newmaster# cp /var/yp/Makefile /var/yp/Makefile.save
newmaster# vi /var/yp/Makefile         # change the PWDIR variable to /etc/nispw

Before you create the new master server, you must decide how many slave servers you will have. For availability, it is a good idea to have at minimum one slave. Once NIS is installed, if it ever becomes unavailable, your network will become unusable. The first time your master server becomes unavailable, your users and you will appreciate being able to use the network. If you need additional server horsepower, then set up more than one NIS slave server. Once you know what the names of the slaves are, make sure that the master's /etc/hosts file has entries for each slave.

To create a new master server, become the superuser on the host and invoke ypinit with the -m flag:

Edit /etc/hosts to add entries for each slave
newmaster# /usr/sbin/ypinit -m

ypinit builds the domain subdirectory of /var/yp for the current default domain. Note that the ypinit utility lives in /usr/sbin, so you should use its full pathname if you don't have this directory in your search path. In this example, ypinit creates /var/yp/bedrock.

After building the domain subdirectory, ypinit builds a complete set of administrative maps for your system and places them in this directory. The first map created by ypinit -m is the ypservers map. ypinit will ask you for a list of hosts that will be running NIS. The hosts named in the ypservers map do not have to be running NIS at that time, but they should become NIS servers before the first modifications are made to NIS maps.

You must have one and only one master server per NIS domain. There is nothing in ypinit that checks for the existence of another master server, so it's possible to create two masters accidentally in the same domain. Having more than one master may lead to NIS map corruption; at best it confuses procedures that contact the NIS master, such as map transfers and NIS password file updates.

Now enable NIS in nsswitch.conf so that processes on your NIS master host can use NIS for all of its name service accesses:

newmaster# cp /etc/nsswitch.nis /etc/nsswitch.conf

If you are running Solaris 8 and if you think you will ever use the sec=dh option with NFS, then it would be an excellent idea to change the entry for publickey in nsswitch.conf to:

publickey: nis

The reason for this step is that the Solaris 8 utilities that manipulate the publickey map get confused if there are multiple database sources in the publickey entry of nsswitch.conf. You should do this on NIS slaves and NIS clients as well.

Once ypinit finishes and nsswitch.conf is set up to use NIS, you should start the NIS service manually via the ypstart script or by rebooting the server host. In Solaris, the relevant part of the boot script /etc/rc2.d//S71rpc normally looks like this:

# Start NIS (YP) services. The ypstart script handles both client
# and server startup, whichever is appropriate.

if [ -x /usr/lib/netsvc/yp/ypstart ]; then
        /usr/lib/netsvc/yp/ypstart rpcstart
fi

Assuming you opt to start the NIS service manually, you would do:

newmaster# /usr/lib/netsvc/yp/ypstart

As the comment in S71rpc says, the ypstart script handles the case when the host is an NIS server or NIS client or both. Both S71rpc and ypstart came with the system when it was installed, and normally won't need modifications. The logic in ypstart may require modifications if a server is a client of one domain but serves another; this situation sometimes occurs when a host is on multiple networks. Issues surrounding multiple domains are left for the next chapter.

Test that your NIS server is working:

newmaster# ypcat passwd
noaccess:NP:60002:60002:No Access User:/:
nobody4:NP:65534:65534:SunOS 4.x Nobody:/:
nobody:NP:60001:60001:Nobody:/:
listen:*LK*:37:4:Network Admin:/usr/net/nls:
daemon:NP:1:1::/:
nuucp:NP:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
uucp:NP:5:5:uucp Admin:/usr/lib/uucp:
sys:NP:3:3::/:
bin:NP:2:2::/usr/bin:
adm:NP:4:4:Admin:/var/adm:
lp:NP:71:8:Line Printer Admin:/usr/spool/lp:
stern:aSuxcvmyerjDM:6445::::::
mre:96wqktpdmrkjsE:6445::::::

You are now ready to add new slave servers or to set up NIS clients. Note that NIS must be running on a master server before you can proceed.

3.2.3. Installing NIS slave servers

As with a master server, you must establish the domain name and the /etc/hosts file with the IP addresses of all the slaves and the master:

newslave# domainname bedrock
newslave# domainname > /etc/defaultdomain
Edit /etc/hosts to add master and slaves

When you initialize a new slave server, it transfers the data from the master server's map files and builds its own copies of the maps. No ASCII source files are used to build the NIS maps on a slave server -- only the information already in the master server's maps. If the slave has information in ASCII configuration files that belongs in the NIS maps, make sure the master NIS server has a copy of this data before beginning the NIS installation. For example, having password file entries only on an NIS slave server will not add them to the NIS passwd map. The map source files on the master server must contain all map information, since it is the only host that constructs map files from their sources.

The slave will need to act as an NIS client in order get initial copies of the maps from the server. Thus you must first set up the slave as a client:

newslave# /usr/sbin/ypinit -c

You will be prompted for a list of NIS servers. You should start with the name of the local host (in this example, newslave), followed by the name of the master (in this example, newmaster), followed by the remaining slave servers, in order of physical proximity.

Now check to see if your slave was already acting as an NIS client already. If so, use ypstop to terminate it:

newslave# ps -ef | grep ypbind
newslave# /usr/lib/netsvc/yp/ypstop

Now start ypbind:

newslave# /usr/lib/netsvc/yp/ypstart

Slave servers are also initialized using ypinit. Instead of specifying the -m option, use -s and the name of the NIS master server:

newslave# /usr/sbin/ypinit -s newmaster

Now you need to start the ypserv daemon:

newslave# /usr/lib/netsvc/yp/ypstop
newslave# /usr/lib/netsvc/yp/ypstart

Finally, set up nsswitch.conf to use NIS:

newslave# cp /etc/nsswitch.nis /etc/nsswitch.conf

3.2.3.1. Adding slave servers later

In general, it is a good idea to initialize your NIS slave servers as soon as possible after building the master server, so that there are no inconsistencies between the ypservers map and the hosts that are really running NIS. Once the initial installation is complete, though, you can add slave servers at any time. If you add an NIS slave server that was not listed in the ypservers map, you must add its hostname to this map so that it receives NIS map updates.

To edit ypservers, dump out its old contents with ypcat, add the new slave server name, and rebuild the map using makedbm. This procedure must be done on the NIS master server:

master# ypcat -k ypservers > /tmp/ypservers 
Edit /tmp/ypservers to add new server name 
master# cd /var/yp 
master# cat /tmp/ypservers | makedbm - /var/yp/`domainname`/ypservers

Once you've changed the master ypservers map on the new slave, you must follow the steps described in Section 3.2.3, "Installing NIS slave servers" in this chapter.

3.2.4. Enabling NIS on client hosts

Once you have one or more NIS servers running ypserv, you can set up NIS clients that query them. Make sure you do not enable NIS on any clients until you have at least one NIS server up and running. If no servers are available, the host that attempts to run as an NIS client will hang.

To enable NIS on a client host, first set up the nsswitch.conf file:

newclient# cp /etc/nsswitch.nis /etc/nsswitch.conf

Set up the domain name:

newclient# domainname bedrock
newclient# domainname > /etc/defaultdomain

Run ypinit:

newclient# /usr/sbin/ypinit -c

You will be prompted for a list of NIS servers. Enter the servers in order of proximity to the client.

Kill (if necessary) ypbind, and restart it:

newclient# ps -ef | grep ypbind
newclient# /usr/lib/netsvc/yp/ypstop
newclient# /usr/lib/netsvc/yp/ypstart

Once NIS is running, references to the basic administrative files are handled in two fundamentally different ways, depending on how nsswitch.conf is configured:

The NIS database replaces some files. Local copies of replaced files (ethers, hosts, netmasks, netgroups,[6] networks, protocols, rpc, and services) are ignored as soon as the ypbind daemon is started (to enable NIS).
[6]The netgroups file is a special case. Netgroups are only meaningful when NIS is running, in which case the netgroups map (rather than the file) is consulted. The netgroups file is therefore only used to build the netgroups map; it is never "consulted" in its own right.
Some files are augmented, or appended to, by NIS. Files that are appended, or augmented, by NIS are consulted before the NIS maps are queried. The default /etc/nsswitch.conf file for NIS has these appended files: aliases, auto_*, group, passwd, services, and shadow. These files are read first, and if an appropriate entry isn't found in the local file, the corresponding NIS map is consulted. For example, when a user logs in, an NIS client will first look up the user's login name in the local passwd file; if it does not find anything that matches, it will refer to the NIS passwd map.

Although the replaced files aren't consulted once NIS is running, they shouldn't be deleted. In particular, the /etc/hosts file is used by an NIS client during the boot process, before it starts NIS, but is ignored as soon as NIS is running. The NIS client needs a "runt" hosts file during the boot process so that it can configure itself and get NIS running. Administrators usually truncate hosts to the absolute minimum: entries for the host itself and the "loopback" address. Diskless nodes need additional entries for the node's boot server and the server for the diskless node's /usr filesystem. Trimming the hosts file to these minimal entries is a good idea because, for historical reasons, many systems have extremely long host tables. Other files, like rpc, services, and protocols, could probably be eliminated, but it's safest to leave the files distributed with your system untouched; these will certainly have enough information to get your system booted safely, particularly if NIS stops running for some reason. However, you should make any local additions to these files on the master server alone. You don't need to bother keeping the slaves and clients up to date.

We'll take a much closer look at the files managed by NIS and the mechanisms used to manage appended files in Section 3.3, "Files managed under NIS". Meanwhile, we'll assume that you have modified these files correctly and proceed with NIS setup.


3. Network Information Service Operation		3.3. Files managed under NIS