Deploying NIS | Solaris 9 Sun Certified System Administrator Study Guide

NIS was developed to make computer network administration easier. An alternative to using local /etc files, NIS provides a centralized repository for storing important configuration information.

If you are running a Solaris network, using NIS can save you a lot of time. For example, if users on your network needed access to several different computers, you would have to update the local /etc/passwd (not to mention shadow and group) files on each computer that each user needed to log into. This could be not only cumbersome, but potentially confusing and a possible security risk. Each time a user changed her password on one computer, she would either have to change it on all other computers as well, or notify the administrator to make the change.

What if you were to add another computer to the network? You would have to manually edit the hosts file on each computer to recognize the new machine. Even if you simply changed an IP address on one computer, you would have to update all hosts files. These types of situations cause unneeded stress for users and administrators alike.

By using NIS, though, all of these changes can be maintained in a centralized location. The administrator needs to make the changes on only one computer, and they will affect the entire network. It sounds a lot easier than using /etc files, and it is.

Note

NIS was originally called the Sun Yellow Pages (YP). However, the term Yellow Pages is a registered trademark, so Sun had to change the name. You'll notice that most of the commands and directories associated with NIS still have YP somewhere in their names (such as /var/yp, ypcat, and yppush).

The Logical NIS Structure

The logical grouping of computers supported by NIS is called a NIS domain. Each NIS domain must have one and only one master server. The master server is the primary source of information for the domain. Information is held in a series of databases known as NIS maps. These maps are stored in the /var/yp/domainname directory on the master server. If, for example, your domain name is abc.com, the directory is /var/yp/abc.com. Each map is stored as two files: mapname.dir and mapname.pag. The master server should be a fast, reliable server with high uptime.

Note

Although NIS domains support Internet naming standards (abc.com), a NIS domain cannot be directly connected to the Internet with just a NIS server. You can, however, use NIS and DNS together to provide an Internet solution.

You can also install one or more NIS slave servers. Slave servers function as backups to the master server and help spread the workload among NIS servers. Slave servers, like master servers, provide information to client computers. The master server will propagate its NIS information to the slave server(s), which is how all NIS servers stay synchronized. Each slave server has a map directory identical to the map directory on the master server.

Typically, all computers on the network, including the NIS master and slave servers, will be NIS clients. When client computers boot up, they will broadcast a request looking for the nearest NIS server. The client will bind to the first NIS server that responds and will subsequently request information from that server for the duration of the client's session (until it's rebooted).

A master server can be a master for only one domain. It can, however, be a slave for another domain. Slave servers can be slaves for multiple domains. Client computers can belong to only one domain at a time.

The conventional wisdom for NIS servers says that you need one NIS server for every 30 clients. If the client computers are faster than the server (which shouldn't be the case), then you will need more NIS servers. If the server is faster than the clients, it can generally handle about 50 clients before showing signs of performance degradation. If your network has multiple IP subnets, you should place one NIS server on each subnet. NIS clients older than Solaris 8 will require this, but Solaris 8 and Solaris 9 clients do not require their NIS servers to be on the same subnet as they are.

Tip

Even if your network is made up of all Solaris 9 NIS clients, place a NIS server on each subnet. It will speed up NIS performance.

Overview of NIS Maps

NIS stores its information in a set of files called maps. As mentioned earlier, these maps are stored in a central location (on the master server) and can be replicated to backup servers (called slave servers).

NIS maps are two-column tables. The first column is the key, which is used by NIS as a search criteria when NIS information is requested. The second column is the information related to the key. Some information is stored in multiple maps. For example, Ethernet addresses are stored in two maps: ethers.byadr and ethers.byname. The first one sorts Ethernet addresses by address (the address is the key, and the name is the value), and the second map stores the addresses by name (the name is the key, and the address is the value). Both maps contain the same information, just sorted differently.

Maps are stored in the NIS server's /var/yp/domainname directory. If your domain name is abc.com, the directory containing the maps will be /var/yp/abc.com.

Maps are created from source files that contain the information to be included in the maps. By default, these source files are located in the /etc directory (/etc/passwd, /etc/hosts, and so forth), but you can change the default directory if you want to. Running the make command in the directory containing the source files causes the makedbm program to create or modify the default NIS maps based on the input files.

Tip

Always run the make command on the master server. Never run it on slave servers. Running make on the master server will ensure that maps are properly pushed to slave servers, whereas maps "made" on slave servers will not be pushed to the master server or other slaves, and will be subsequently overwritten the next time the master pushes changes to slaves.

Table 15.3 lists the default NIS maps.

Table 15.3: Default NIS Maps
Name	Source File	Contents
bootparams	bootparams	The pathnames of files that clients need to boot.
ethers.byaddr	ethers	Machine names (host names) and Ethernet addresses, with the address as the key.
ethers.byname	ethers	Machine names (host names) and Ethernet addresses, with the host name as the key.
group.bygid	group	Group security information, with the GID as the key.
group.byname	group	Group security information, with the group name as the key.
hosts.byaddr	hosts	Host names and IP addresses, with the address as the key.
hosts.byname	hosts	Host names and IP addresses, with the host name as the key.
mail.aliases	aliases	Mail aliases and mail addresses, with the alias as the key.
mail.byaddr	aliases	Mail aliases and mail addresses, with the mail address as the key.
netgroup.byhost	netgroup	Netgroup names, usernames, and computer names, with the host name as the key.
netgroup.byuser	netgroup	Netgroup names, usernames, and computer names, with the username as the key.
netgroup	netgroup	Netgroup names, user names, and computer names, with netgroup name as the key.
netid.byname	passwd, hosts, and group	Host names, mail addresses, and domain names. Used for UNIX-style authentication. If the netid file is available, it's consulted in addition to other files containing the same data.
netmasks.byaddr	netmasks	Network masks to be used with IP subnetting.
networks.byaddr	networks	Names of networks known to this computer, with the network address as the key.
networks.byname	networks	Names of networks known to this computer, with the network name as the key.
passwd.adjunct.byname	passwd and shadow	Auditing information and hidden password information for C2 network clients.
passwd.byname	passwd and shadow	Password information, with the username as the key.
passwd.byuid	passwd and shadow	Password information, with the UID as the key.
protocols.byname	protocols	Network protocols known to your network, with the protocol name as the key.
protocols.bynumber	protocols	Network protocols known to your network, with the protocol number as the key.
rpc.bynumber	rpc	Program numbers and names of RPCs known to the computer.
services.byname	services	Internet services known to your network, with the key port or protocol as the key.
services.byservice	services	Internet services known to your network, with the service name as the key.
ypservers	N/A	NIS servers known to your network.

Keep in mind that these are only the default databases. Applications can install their own NIS maps, and you can also create custom NIS maps as necessary. For the most part, though, the default maps are sufficient to serve most networks.

Two useful commands related to maps are ypcat and ypwhich. The ypcat command performs similarly to the cat command, except that it shows the contents of a map file. For example, to see the data in the passwd.byname map, you would use ypcat passwd.byname. If a map contains only keys (such as the ypservers map), use ypcat -k mapname. To see which server is the master server for a particular map, use ypwhich -m mapname.

Some maps can also be referenced by nicknames instead of their full names. For example, the passwd.byname map can also be referenced simply as passwd. Nicknames can be used with any of the yp* management commands. The /var/yp/nicknames file contains a list of nicknames associated with map names. You can add or modify nicknames for any map file.

NIS Daemons and Utilities

The two software packages composing the NIS service, SUNWypu and SUNWypr, should have been installed by default when you installed Solaris. You can check to see whether these packages are installed by using the pkginfo command. The NIS service is supported by five daemons. They are listed in Table 15.4.

Table 15.4: NIS Daemons
Daemon	Description
ypserv	The NIS server daemon looks up information in the NIS server's maps. It is also responsible for logging error conditions in the NIS service to the /var/yp/ypserv.log file, if the file exists.
ypbind	The NIS binding daemon is responsible for connecting the client to a server (called binding), and initiating future communications between the client and server.
ypxfr	Provides high-speed map transfers between NIS servers.
rpc.yppasswdd	Responsible for handling password changes, as requested with the yppasswd command. It updates the passwd and shadow files.
rpc.ypupdated	Updates NIS information, such as which maps need to be updated after changes are made to the source files.

Table 15.5 lists the commands you will use to manage NIS.

Table 15.5: NIS Commands
Command	Description
make	Creates or updates NIS maps by reading the makefile (/var/yp/ makefile) and the NIS source files.
makedbm	Creates a dbm file for a NIS map. Running the make command initiates the makedbm command, creating or updating maps.
ypcat	Displays the data in a map.
ypinit	Automatically creates NIS maps from the source files. Used to set up NIS servers for the first time, and on clients to initialize the NIS service and update the client's ypservers list.
ypmatch	Displays the value for one or more keys in a specified map.
yppoll	Gets a map version number from a NIS server.
yppush	Manually initiates a push of the NIS maps from the master server to the slave server(s).
ypset	Configures NIS client binding to a specific server.
ypstart	Starts the NIS service.
ypstop	Stops the NIS service.
ypwhich	Lists the name of the NIS server that supplies NIS information to that client, or displays the name of the master for a given map.
ypxfr	Copies a NIS map from the NIS master server to the local host. Similar to the yppush command.

You will get a feel for when and how to use these commands as you continue to read through this chapter.

Installing a NIS Master Server

If you are going to use NIS, the first NIS computer that you must install is the NIS master server. As mentioned before, this server will contain the master copies of map files and will provide service to clients as well as slave servers. You should pick a server that is both fast and highly reliable. Interruptions in the NIS service due to poor server performance can cripple your network if you rely on NIS as your only naming service.

Before configuring your NIS master server, decide on a domain name for your NIS domain. The domain name must have 256 characters or fewer (preferably fewer) and is case sensitive. If you already have an Internet domain name, you can use the same name for your NIS domain. Each computer that will use NIS must have the correct domain name in their /etc/defaultdomain file, as well as a unique computer name defined in their /etc/nodename file.

Preparing Source Files

The first thing you need to do when setting up a NIS master server is to prepare the source file for the master passwd map. Source files contain the information from which you will build maps. All source files (which are listed in Table 15.3) are located in the /etc directory by default. For most files, this is not a problem. But for the passwd and shadow files, this presents a security risk, because the /etc/passwd and /etc/shadow files include all user account information, including that of the root user. If you were to create the NIS maps from these files, all users on the network would have access to the root password, because all users need access to the master maps. Yes, the password is encrypted. But given enough time, users can easily hack it by using brute force.

So, for security reasons, it is best to place the source passwd and shadow files in a directory other than /etc. Many administrators like to put these source files in the /var/yp directory because that makes them easy to locate. Others like to create a subdirectory in /var/yp, such as /var/yp/source, to locate the files. In either case, ensure that the security on the source directory allows only root access to the files.

After you have created your source directory and copied the passwd and shadow files into it, you can prepare them for use as source files. The whole reason you moved them to an alternate location in the first place was because of security concerns: you don't want everyone having access to the root password. And, of course, if you were to delete the root entry from /etc/passwd and /etc/shadow, you wouldn't be able to log in as the root user. So, in your copied passwd and shadow files, remove the entries for root, as well as for other accounts you don't want users trying to log in as.

There's one more step you need to complete before creating your passwd map. By default, the NIS service looks to the /etc directory for its source files. The /var/yp/makefile file contains the parameters used by NIS to create maps. You need to edit makefile to point to your new source directory; otherwise, NIS will just pull data from the /etc files.

/var/yp/makefile is quite large, but here's a sampling of it showing the lines that you will need to modify:

 # /var/yp/makefile # B= DIR =/etc # INETDIR=/etc/inet # RBACDIR=/etc/security # PWDIR =/etc DOM = `domainname` NOPUSH = "" ALIASES = /etc/mail/aliases YPDIR=/usr/lib/netsvc/yp SBINDIR=/usr/sbin YPDBDIR=/var/yp YPPUSH=$(YPDIR)/yppush MAKEDBM=$(SBINDIR)/makedbm MULTI=$(YPDIR)/multi REVNETGROUP=$(SBINDIR)/revnetgroup STDETHERS=$(YPDIR)/stdethers STDHOSTS=$(YPDIR)/stdhosts MKNETID=$(SBINDIR)/mknetid MKALIAS=$(YPDIR)/mkalias ... #

You need to change DIR =/etc and PWDIR =/etc to point to your new source file location. If, for example, you copied the passwd file to /var/yp, then you need to change each of these lines to read =/var/yp. You can also see that other Solaris services, such as RBAC (RBACDIR=) and e-mail (ALIASES=), have their own lines in makefile as well.

Creating Source Files

After you have created your new source directory (such as /var/yp) and made the necessary modifications to makefile, you need to verify that all of your source files contain the correct information. Remember, the point of using NIS is to ensure that all users and computers have access to current network information, located in a centralized place. It's imperative to ensure that the source files you are working with are correct.

There are several ways you could approach this process. One would be to copy the /etc/ passwd files from each host to the server and then use the cat command to concatenate each file into a master passwd file. After removing duplicate entries (usernames and/or UIDs), you could use the new master passwd file for the source file. You could do the same with the shadow and group files as well. There are utilities that will help you sort these files, as well as ensure that each entry is unique, such as sort and uniq.

Another way you could create master source files is to manually edit each source file, ensuring that the information contained within is correct. For files such as hosts, bootparams, and netmasks, this is often the preferred method. You can also do the same for the passwd, shadow, and group files. If you have a large network, creating source files this way might take a long time, but the time you invest in the beginning will save you a lot of work in the long run.

The purpose of this section isn't to teach you the best way to create source files for your NIS server, as that can be a matter of opinion. But, there are some general guidelines to follow when setting up source files on your master server:

Create an alternate directory, other than /etc, for your source files.
Copy all source files that you want to make maps for into your new source directory.
Ensure that the makefile file points to your new source directory.
And most importantly, make sure your source files have information that reflects the current status of your network.

The one source file that cannot be moved is the /etc/mail/aliases file. It must remain in the /etc/mail directory. If you want your e-mail aliases to be available through the NIS server, ensure that this file is current as well.

After your source files are ready, you are ready to use the ypinit command to initialize your master server.

Setting Up the Master Server

The ypinit command is a versatile command that is used to install and configure NIS servers and clients. On the computer that will be your master server, ypinit creates the master maps. It does this by calling the make program, which in turn reads makefile, which contains scripts to create all appropriate databases (by using makedbm) from the source files. After the source data is passed through makedbm, it is collected in two files, mapname.dir and mapname.pag, both of which are located in the /var/yp/domainname directory on the master server.

The passwd maps are built from the /PWDIR/passwd, /PWDIR/shadow, and /PWDIR/ security/passwd.adjunct files, as appropriate.

To install a NIS master server, you must have root permissions on the computer. Here are the steps to set up your master server by using ypinit:

Ensure that the local computer receives its name service information from local /etc files, not from NIS. This might seem counterintuitive, but it's a necessary step, and you will fix this "problem" later.
```
 # cp /etc/nsswitch.files /etc/nsswitch.conf 
```
Make sure that the /etc/hosts file contains the names and IP addresses of each computer that will become a NIS slave server. (If your network has a properly configured DNS server, this step is optional.)
Build the master maps with the ypinit command.
```
 # ypinit -m 
```
The ypinit program will ask you for a list of other computers that will become NIS servers. You will enter the name of the server you are working on, as well as the names of all planned NIS slave servers. Type each server name separately and then press the Enter key. When you are done entering slave servers, press Control+D.
ypinit will ask whether you want to terminate the procedure at the first nonfatal error or to continue despite nonfatal errors. Type y. This will cause ypinit to terminate if it encounters an error, enabling you to fix the problem and restart ypinit. This option is recommended if this is the first time you have run ypinit on this computer. (Nonfatal errors can occur when some of the map files aren't present. This doesn't necessarily affect NIS functionality, but it might be a situation you want to rectify.)
If you have previously installed NIS, ypinit will ask whether the existing files in /var/yp/domainname can be destroyed. To continue with a new installation of NIS, answer yes.
ypinit will construct a list of NIS servers and invoke the make command. This will create the appropriate maps and set the name of the master server for each map.
After this is complete, you will want the local computer to use NIS as the name service. You can edit your current nsswitch.conf file, but the preferred method is to copy the switch file template for NIS.
```
 # cp /etc/nsswitch.nis /etc/nsswitch.conf 
```
Edit your new nsswitch.conf file, if needed, to reflect any custom name service settings.

After these steps are completed, you need to start the NIS service. The two services that need to be running are ypserv and ypbind. Both of these daemons are started by the /usr/lib/ netsvc/yp/ypstart command. After NIS is installed, the ypstart command will run automatically at boot, starting the NIS service for you. If you want to stop the NIS service for any reason, issue the /usr/lib/netsvc/yp/ypstop command.

Configuring NIS Clients

NIS clients will use the NIS server to obtain network information. Although some networks use a combination of NIS and local /etc files for name service information, this section is going to assume that all network clients will be NIS clients and will use the NIS service exclusively.

To set up a NIS client, you must have root permissions on the client computer. You then need to complete these three tasks:

Remove user account information from the /etc/passwd, /etc/shadow, and /etc/group files on the local computer. You will be requesting login validation from the NIS server.

Note

For security purposes, some networks require user account information to be obtained from local /etc files, whereas all other information is obtained from the NIS server. This prevents usernames and passwords from being transmitted across the network.

Ensure that the domain name is configured in the client computer's /etc/defaultdomain file. Remember that domain names are case sensitive.
Configure the client with the appropriate name service switch file. Copying /etc/ nsswitch.nis to /etc/nsswitch.conf should work in most cases.

After these tasks are complete, you are ready to configure the client computer to use NIS. You have two choices on how to accomplish this. The recommended way is to issue the following command:

 # ypinit -c

The ypinit -c command will configure the computer to be a NIS client. Running this command will prompt you for a list of NIS servers in the domain. You can list as many or as few servers as you would like. For performance reasons, you should list servers that are physically closest to the client.

The other method of configuring NIS clients is to use broadcasting. After the domain name is set for the client, you can run the ypbind -broadcast command to broadcast on the local subnet looking for a NIS server. If a NIS server is located, the client binds to it. If, however, there is no NIS server on the local subnet, this method will fail.

Binding is an important concept to NIS clients. When a NIS client boots up, it will attempt to locate a NIS server. It can do this by searching its /var/yp/binding/domainname/ypservers list for valid NIS servers or by broadcasting. After a client locates a server, it will bind to that server and ask only that NIS server for NIS information. If or when the client is rebooted, the binding process will start over.

If you set up the NIS client with the ypinit -c command, the ypservers list will exist. If you configured the client to broadcast, or the ypservers list does not exist, the client will broadcast for a NIS server during boot. It's preferable to have clients search a list instead of creating excessive network broadcast traffic.

Tip

The yppasswd command is used to change user passwords for clients using the NIS service.

Installing NIS Slave Servers

It's good practice to have at least one NIS slave server on your network. Slave servers can help offset the load from the master server, and can keep name service resolution up and running if the master server fails for any reason. NIS slave servers are also NIS clients and consequently must be set up as NIS clients as part of the slave server installation process.

Before you configure a slave server, ensure that the domain name is properly set in the local /etc/defaultdomain file. Also, you will need to make sure that the network is functioning properly. When you attempt to create the slave, it will try to copy the maps from the master. The copying process is similar to the one used by the rcp command. So, if rcp works between the master and slave-to-be, then the slave installation process should run smoothly.

Just as in setting up a master server or NIS client, you need superuser permissions to install a NIS slave server. Here are the steps:

Ensure that the local /etc/hosts file contains the names and IP addresses of all other NIS servers on the network. (If your network has a properly configured DNS server, this step is optional.)
Change to the /var/yp directory on the slave server.
```
 # cd /var/yp 
```
Initialize the slave server as a NIS client by using the ypinit command.
```
 # ypinit -c 
```
The ypinit command will prompt you for a list of NIS servers. Enter the name of the slave you are working on first, followed by the master server, and then the other slave servers on the network. For performance reasons, add slave servers in order of proximity to this computer (closest first).
Check to see whether the ypbind service is running. If it is, then you will need to stop and restart it. If it's not, you need to start it.
```
 # pgrep ypbind 
```
1. If a listing is displayed from this command, then ypbind is running. Stop it with the /usr/lib/netsvc/yp/ypstop command.
2. If no listing is displayed, or if you've stopped ypbind, then you need to restart it with the /usr/lib/netsvc/yp/ypstart command.
Configure the computer to be a NIS slave by using the ypinit command. The master variable is the name of the NIS master server.
```
 # ypinit -s master 
```

Stop and restart the NIS daemons.

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

Repeat these steps on all computers that you want to make NIS slave servers.

Be sure to plan which computers you want to be slave servers before you begin your initial NIS installation. You can always add NIS slave servers later, but that process is different and more complex than the initial installation process.

Note

To change a NIS computer's NIS domain name, you must first change the computer's domain name in the /etc/defaultdomain file and then rerun ypinit to set up the computer as a master, slave, or client.

Working with NIS Maps

After maps are created on your NIS master server and propagated to the slave servers, the NIS map replication process is automatic. If any changes are made to maps on the master server, the changed maps will be pushed automatically to the slave servers.

Solaris provides two commands to help propagate maps manually. The yppush command, run from the NIS master server, pushes maps to the slave servers. The ypxfr command pulls maps from the NIS master server to the local host.

Solaris also provides several utilities to view and manage the data within existing maps.

Using Map Utilities

If you want to see the data in a specific map, you can use the ypcat command to list all values within the map. Here's an example:

 # ypcat passwd efrederick:JYa9rCO/9zq6Y:105:10:hey der eh:/home/efrederick:/bin/sh sjohnson:VAPzqVS9aBxL2:103:10:movie star:/home/sjohnsin:/bin/sh abradley:*LK*:3422:1::/export/home/abradley:/bin/sh ldocter:uXKXU926ue29M:107:100:Lauren:/home/ldocter:/bin/sh ramini:fWYc2uvcLUmc6:102:10:punny boy:/home/ramini:/bin/sh lfrederick:*LK*:109:1::/home/lfrederick:/bin/sh qdocter:6uoVIHZIxXiVI:100:10:author:/home/qdocter:/bin/ksh passmgr:/kOiiZaj.onTg:108:14::/home/passmgr:/bin/pfsh kdocter:SXBMd1wKhMN2k:101:10:support staff:/home/kdocter:/bin/sh adocter:hXVI4wCsDRVKs:106:100:Abbie:/home/adocter:/bin/sh mgantz:5Y/YmRlbWY/3g:104:10:Mac user:/home/mgantz:/bin/sh #

To display the keys along with the values in a map, use ypcat -k. In the case of the passwd database, the key will be the same as the username.

Another command, ypwhich, will show the name of the master server for a given map:

 # ypwhich -m passwd Q-Sol #

Running the ypwhich command with no arguments will display the name of the NIS master server providing information to your local machine.

One other useful command is ypmatch, which looks for and displays specific keys within a map. In the following example, the passwd database is searched for a user:

 # ypmatch qdocter passwd.byname qdocter:6uoVIHZIxXiVI:100:10:author:/home/qdocter:/bin/ksh #

The key in this case is qdocter, which is found within the passwd.byname map. If the key were not matched, ypmatch would inform you that there is no such key in the map.

You'll notice that with ypcat, as well as the other yp* utilities, you can use either the full name of the map or the map's nickname (if it has one) as the command-line argument. To display the list of available nicknames, use the -x option with ypcat, ypwhich, or ypmatch.

Changing a Map's Master Server

When you build a NIS map, the map's master server name is included as a key pair within the map. Therefore, you can't just copy (or move) a map to another server (by using a utility such as ypxfr) and have the new server be the master server. It would be nice if it were that easy, but it's not.

If you want to change master servers for a map, you must rebuild the map on the new master server. This is done to re-associate the key with the new master server's name. If the original map has an ASCII source file, you should copy this file to the new master.

To change a map's master server, log into the new master server as the superuser and change to the /var/yp directory. Once there, follow these steps:

Examine makefile to ensure that there's an entry for the new map you want to create. If not, you will need to create an entry. For example, if you were creating a custom map file named clients.byname, you would need a clients.byname entry in makefile.
After the entry is in makefile, you can create the new map by using the following command:
```
 # make clients.byname 
```
Of course, if your map name is different from clients.byname, substitute it here.
After you make the new map, log onto the old master server and comment out the line in makefile that refers to the map. This will prevent the old master server from remaking the map.
You now need to send a copy of the new map out to the slave servers. However, if you were to run yppush at this time, the other slaves would try to get the map from the original master, because their copy still contains the original master's key pair. The way around this is to log back onto the original master and use ypxfr to pull the map from the new master.
```
 # /usr/lib/netsvc/yp/ypxfr -h newmaster clients.byname 
```
It's now safe to use yppush to disseminate the new map. When slave servers receive the updated map, they will know who the new master is for the map.

If for some reason the push fails, you can log onto each slave server and run the ypxfr command as shown in step 4 to pull the map to each slave individually.

Although it's possible to have several servers act as master servers for different maps (each map can have only one master), to avoid confusion, it's generally best to have one master server for all maps.

Customizing Maps

Most network administrators will find that the default maps provided by NIS are sufficient to serve their needs. However, in some cases, a custom map needs to be created. In addition, applications have the ability to add their own custom maps as necessary.

To add a new NIS map, you need to get the map's ndbm files into the master server's /var/ yp/domainname directory. Normally this is done by makefile during the map creation process. It stands to reason then, that in order to create a custom map, the easiest way is to add an entry for the map in makefile. When you modify makefile, you need to add the name of the database to the all rule, write the time rule, and add a rule for the new database.

Note

The specific steps required to create entries in makefile are beyond the scope of this book. For more information, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) from Sun Microsystems. This document is also available online at docs.sun.com.

Creating a new map after an entry is in the makefile file is a relatively simple process. Use the make command on the master server to make the new map:

 # make mapname

After the map is created, use ypxfr from each of the slave servers to retrieve the map. You would think that you could just use yppush, but yppush will not work properly if the new map doesn't yet exist on the slave servers. If the map does exist on the slave servers, you can use yppush to push the map to the slave servers. The "make and push" process works well if you've made changes to the source files for an existing NIS map. Remake the map and then push it out.

Tip

You can also create maps without modifying makefile. Custom maps, such as those with ASCII or text source files, are created with the makedbm command. To modify the map, edit the source file, and then rerun makedbm to re-create the dbm file.

Automating Map Transfers

Some maps rarely change, yet others, such as passwd, change frequently. Either way, it's important to ensure that maps on all slave servers have current information. To help facilitate this process, you can create a crontab file (or use the root crontab file) on each slave server. In the crontab, use the ypxfr command to pull the maps you want. You can specify different ypxfr commands for each map if you want to. When initiated, ypxfr will contact the master server and, if changes in the map are present, will pull the map to the slave.

Additionally, you can log all ypxfr activity with the /var/yp/ypxfr.log file. By default, this file does not exist. However, if you create one, all ypxfr activity will be automatically logged by the ypxfrd daemon.

Troubleshooting NIS

NIS is a complex network-based service. For the most part, it runs well and doesn't have any inherent problems. But because of its complexity and network-based nature, you will occasionally run into trouble.

Errors in NIS have different forms. You might receive a message saying that ypbind can't find a server, or an error stating that the server is not responding or that NIS is not available. Alternatively, commands that need name resolution might take an inordinate amount of time to complete or just completely hang with no error message at all.

As with any network-based service, always keep the possibility of network problems in the back of your troubleshooting mind. To that end, check to see whether any other network services are accessible. If not, then you know the problem probably isn't with NIS.

If the problem seems to be isolated to NIS only, the next thing to check is whether the problem is affecting one computer or several computers.

Here are some things to check if only one computer is (or a few computers are) having problems:

Make sure that ypbind is running on the client. You can check this by running the pgrep ypbind command and looking for ypbind. If it's not there, log on as the superuser and issue a /usr/lib/netsvc/yp/ypstart command.

Check the client's domain name. If the domain name is set incorrectly, the client will not be able to obtain information from a NIS server. Run the domainname command to see what the client's domain name is, or check the /etc/defaultdomain file. Remember that the domain name is case sensitive.

Ensure that the client is bound to a NIS server. Check this by running the ypwhich command. The name of a NIS server should be returned. If you just restarted ypbind, run the ypwhich command several times, because sometimes the first time will report that the client is not bound, and the second (or third) try might succeed.

Check for server availability. If the server is unavailable, it could indicate a number of possible problems. First, check whether the client has a /var/yp/binding/domainname/ypservers file. This file should have several servers listed, just in case one or two NIS servers are unavailable. If the file doesn't exist, run ypinit -c to create one. If no servers are listed or are available, the client will attempt to broadcast to locate one. Also, if the NIS server doesn't have the client listed in its hosts file (or the DNS service isn't working properly), NIS can fail.

Investigate other miscellaneous problems. Check to make sure that the client's /etc/ nsswitch file is correct. Looking to local files instead of the NIS server can be a problem. Also remember that NIS relies on the rpc service. If that network service is having problems, NIS will likely fail as well.

If, instead of being isolated to one computer, the problem is network-wide, then the problem is most likely with the NIS server. One of the first things to consider is whether you have enough NIS servers for your network. Having too few servers can cause the existing ones to become overloaded, and they won't respond to clients in time.

Here are a few specific things to look for if the problem seems to be widespread:

Check server availability. Are the servers up and running? Use the ping command to verify.

Check whether the NIS daemons are running. On the server, both the ypserv and ypbind processes need to be running. Check by using the pgrep yp command. If needed, stop and restart the NIS service by using the /usr/lib/netsvc/yp/ypstop and /usr/lib/netsvc/yp/ ypstart commands.

Make sure that the servers all have the same map versions. Map inconsistencies can cause network problems. The yppoll command can tell you a map's version number. If you need to manually initiate a map transfer, use the yppush (from the master server) or ypxfr (from the slave server) command.

It would be difficult to come up with a complete list of possible NIS problems, but the ones provided in this section should give you a good jump on troubleshooting. The key to troubleshooting anything is to first narrow down the problem-where does it work and where doesn't it work-and then look for a solution.

Overview of NIS+

Although NIS provides a functional naming service structure for many networks, its flat naming structure does have some limitations. Although their names are similar, Network Information Service Plus (NIS+) was developed independently of NIS. NIS+ uses a hierarchical naming structure, much like that of a UNIX file system structure, to name and locate objects and can provide more information to clients than can NIS.

NIS+ is designed to be flexible enough to accommodate any logical network structure and to grow as the network grows. To that end, NIS+ namespaces can be divided into multiple domains, and clients can access information from several domains if necessary. NIS+ is virtually unlimited in scope.

NIS+ follows the client-server model. The main server in a domain is called a master server, and the backup servers are called replicas. Information is stored in NIS+ tables (as opposed to NIS maps) on the master server and all replicas.

In addition, NIS+ includes advanced security mechanisms not present in NIS, such as Data Encryption Standard (DES) authentication. Also unlike NIS, the yp* series of commands is not used to manage NIS+. Rather, NIS+ has its own series of nis* management commands, such as niscat, nisinit, and nisgrep. NIS+ is designed to replace NIS, and the two are not commonly found running on the same network.