NIS, formerly called the Yellow Pages (YP), is a distributed database system that lets the system administrator administer the configuration of many hosts from a central location. Common configuration information, which would have to be maintained separately on each host in a network without NIS, can be stored and maintained in a central location and then propagated to all the nodes in the network. NIS stores information about workstation names and addresses, users, the network itself, and network services. This collection of network information is referred to as the NIS namespace.
YP to NIS As stated, NIS was formerly known as Sun Yellow Pages (YP). The functionality of the two remains the same; only the name has changed.
Before beginning the discussion of the structure of NIS, you need to be aware that the NIS administration databases are called maps. An NIS domain is a collection of systems that share a common set of NIS maps.
The Structure of the NIS Network
The center of the NIS network is the NIS master server. The system designated as master server contains the set of maps that you, the NIS administrator, create and update as necessary. After the NIS network is set up, any changes to the maps must be made on the master server. Each NIS domain must have one, and only one, master server. The master server should be a system that can handle the additional load of propagating NIS updates with minimal performance degradation.
In addition to the master server, you can create backup servers, called NIS slave servers, to take some of the load off the master server and to substitute for the master server if it goes down. If you create an NIS slave server, the maps on the master server are transferred to the slave server. A slave server has a complete copy of the master set of NIS maps. If a change is made to a map on the master server, the updates are propagated among the slave servers. The existence of slave servers lets the system administrator evenly distribute the load that results from answering NIS requests. It also minimizes the impact of a server becoming unavailable.
Typically, all the hosts in the network, including the master and slave servers, are NIS clients. If a process on an NIS client requests configuration information, it calls NIS instead of looking in its local configuration files. For group and password information and mail aliases, the /etc files might be consulted first, and then NIS might be consulted if the requested information is not found in the /etc files. Doing this, for example, allows each physical system to have a separate root account password.
Any system can be an NIS client, but only systems with disks should be NIS servers, whether master or slave. Servers are also clients of themselves.
As mentioned earlier, the set of maps shared by the servers and clients is called the NIS domain. The master copies of the maps are located on the NIS master server, in the directory /var/yp/<domainname>, in which <domainname> is the chosen name for your own domain. Under the <domainname> directory, each map is stored as two files: <mapname>.dir and <mapname>.pag. Each slave server has an identical directory containing the same set of maps.
When a client starts up, it broadcasts a request for a server that serves its domain. Any server that has the set of maps for the client's domain, whether it's a master or a slave server, can answer the request. The client "binds" to the first server that answers its request, and that server then answers all its NIS queries.
A host cannot be the master server for more than one NIS domain. However, a master server for one domain might be a slave server for another domain. A host can be a slave server for multiple domains. A client, however, belongs to only one domain.
Determining How Many NIS Servers You Need
Determining Which Hosts Will Be NIS Servers
Information Managed by NIS
NIS maps are two-column tables. One column is the key, and the other column is the information value related to the key. NIS finds information for a client by searching through the keys. Some information is stored in several maps because each map uses a different key. For example, the names and addresses of systems are stored in two maps: hosts.byname and hosts.byaddr. If a server has a system's name and needs to find its address, it looks in the hosts.byname map. If it has the address and needs to find the name, it looks in the hosts.byaddr map.
Maps for a domain are located in each server's /var/yp/<domainname> directory. For example, the maps that belong to the domain pyramid.com are located in each server's /var/yp/pyramid.com directory.
An NIS Makefile is stored in the /var/yp directory of the NIS server at installation time. If you run the /usr/ccs/bin/make command in that directory, makedbm creates or modifies the default NIS maps from the input files. For example, an input file might be /etc/hosts. Issue the following command to create the NIS map files:
cd /var/yp /usr/ccs/bin/make
Generate Maps on the Master Server Only Always make the maps on the master server and never on a slave server. If you run make on a slave server, the maps will be generated from data in the slave server's local files and will be inconsistent with the rest of the domain. Additionally, NIS clients that are bound to the slave server will be querying inconsistent data and receiving unexpected results.
Creating NIS maps is described in more detail later in this chapter in the "Configuring an NIS Master Server" section.
Solaris provides a default set of NIS maps. They are described in Table 12.5, including the corresponding file that is used to create each of them. You might want to use all or only some of these maps. NIS can also use whatever maps you create or add, if you install other software products.
NIS makes updating network databases much simpler than with the /etc file system. You no longer have to change the administrative /etc files on every system each time you modify the network environment. For example, if you add a new system to a network running NIS, you only have to update the input file on the master server and run /usr/ccs/bin/make from the /var/yp directory. This process automatically updates the hosts.byname and hosts.byaddr maps. These maps are then transferred to any slave servers and made available to all the domain's client systems and their programs.
ypcat [-k] <mapname>
If a map is composed only of keys, as in the case of ypservers, use ypcat -kotherwise, ypcat prints blank lines.
In this case, mapname is the name of the map you want to examine.
You can use the ypwhich command to determine which server is the master of a particular map:
ypwhich -m <mapname>
In this case, mapname is the name of the map whose master you want to find. ypwhich responds by displaying the name of the master server.
Planning Your NIS Domain
Before you configure systems as NIS servers or clients, you must plan the NIS domain. Each domain has a domain name, and each system shares the common set of maps belonging to that domain. Step by Step 12.1 outlines the steps for planning an NIS domain.
Configuring an NIS Master Server
Before configuring an NIS master server, be sure the NIS software cluster is installed. The package names are SUNWypu and SUNWypr. Use the pkginfo command to check for these packages. Both packages are part of the standard Solaris 10 release. The daemons that support the NIS are described in Table 12.6.
The commands that you use to manage NIS are shown in Table 12.7. We describe some of these commands in more detail later when we show examples of setting up NIS.
Identifying Daemons Versus Commands Make sure you are familiar with what each daemon and command does. Exam questions are frequently presented by describing the daemon or command and asking you to identify it correctly.
An NIS master server holds the source files for all the NIS maps in the domain. Any changes to the NIS maps must be made on the NIS master server. The NIS master server delivers information to NIS clients and supplies the NIS slave servers with up-to-date maps. Before the NIS master server is started, some of the NIS source files need to be created.
The basic steps for setting up an NIS master server are as follows:
Creating the Master passwd File
The first task in setting up an NIS master server is to prepare the source file for the passwd map. However, be careful with this source file. The source files can be located either in the /etc directory on the master server or in some other directory. Locating the source files in /etc is undesirable because the contents of the maps are then the same as the contents of the local files on the master server. This is a special problem for passwd and shadow files because all users would have access to the master server maps, and because the root password would be passed to all YP clients through the passwd map.
Sun recommends that for security reasons, and to prevent unauthorized root access, the files used to build the NIS password maps should not contain an entry for root. Therefore, the password maps should not be built from the files located in the master server's /etc directory. The password files used to build the passwd maps should have the root entry removed from them, and they should be located in a directory that can be protected from unauthorized access.
For this exercise, copy all the source files from the /etc directory into the /var/yp directory. Because the source files are located in a directory other than /etc, modify the Makefile in /var/yp by changing the DIR=/etc line to DIR=/var/yp. Also, modify the PWDIR password macro in the Makefile to refer to the directory in which the passwd and shadow files reside by changing the line PWDIR=/etc to PWDIR=/var/yp.
Now, to create the passwd source file, use a copy of the /etc/passwd file on the system that becomes the master NIS server. Create a passwd file that has all the logins in it. This file is used to create the NIS map. Step by Step 12.2 shows you how to create the passwd source file.
Creating the Master Group File
Just like creating a master /var/yp/passwd file, the next task is to prepare one master /var/yp/group file to be used to create an NIS map. To create the master group file, follow Step by Step 12.3.
Creating the Master hosts File
Now create the master /etc/hosts file the same way you created the master /var/yp/passwd and /var/yp/group files (see Step by Step 12.4).
Creating Other Master Files
The following files, which were described in Table 12.2, can also be copied to the /var/yp directory to be used as source files for NIS maps, but first be sure that they reflect an up-to-date picture of your system environment:
Unlike other source files, the /etc/mail/aliases file cannot be moved to another directory. This file must reside in the /etc/mail directory. Be sure that the /etc/mail/aliases source file is complete by verifying that it contains all the mail aliases that you want to have available throughout the domain.
Preparing the Makefile
After checking the source files and copying them into the source file directory, you need to convert those source files into the ndbm format maps that NIS uses. This is done automatically for you by ypinit. We describe how to use ypinit in the next section.
The ypinit script calls the program make, which uses the file Makefile located in the /var/yp directory. A default Makefile is provided for you in this directory. It contains the commands needed to transform the source files into the desired ndbm format maps.
The function of the Makefile is to create the appropriate NIS maps for each of the databases listed under "all." After passing through makedbm, the data is collected in two files, mapname.dir and mapname.pag. Both files are located in the /var/yp/<domainname> directory on the master server.
Setting Up the Master Server with ypinit
The /usr/sbin/ypinit shell script sets up master and slave servers and clients to use NIS. It also initially runs make to create the maps on the master server. See Step by Step 12.5 to set up a master server using ypinit.
Selecting the Correct Command Option Exam questions are often based on the syntax of the ypinit command. You might be given a scenario where you are asked to select the correct command option to initialize either a master server, a slave server, or a client. Ensure that you are completely familiar with what each command option achieves.
Starting and Stopping NIS on the Master Server
To start up NIS on the master server, you need to start the ypserv process on the server and run ypbind. The daemon ypserv answers information requests from clients after looking them up in the NIS maps. You can start up NIS manually on the server by running the svcadm enable nis/server command from the command line, followed by svcadm enable nis/client. After you configure the NIS master server by running ypinit, the NIS server is is automatically invoked to start up ypserv whenever the system is started up. This is actioned via SMF.
svcadm disable nis/server svcadm disable nis/client
NIS and SMF You should note that the NIS service is now managed via the Service Management Facility (SMF) and can be stopped and started using the svcadm command. You can still use the ypstop and ypstart commands, but you might get unexpected results, especially as SMF could automatically restart the service if you stop it manually. The recommended way to start and stop NIS is via SMF.
Setting Up NIS Clients
The first step is to remove from the /etc/passwd file all the user entries that are managed by the NIS server. Don't forget to update the /etc/shadow file. Also, remove entries from /etc/group, /etc/hosts, and any other network files that are now managed by NIS.
After setting up the nsswitch.conf file and setting your domain name as described in the section titled "Planning Your NIS Domain," you configure each client system to use NIS by logging in as root and running the /usr/sbin/ypinit command, as follows:
You are asked to identify the NIS servers from which the client can obtain name service information. Enter each server name, followed by a carriage return. You can list one master and as many slave servers as you want. The servers that you list can be located anywhere in the domain. It is good practice to first list the servers closest (in network terms) to the system, followed by the more distant servers on the network because the client attempts to bind to the first server on the list.
When you enter a server name during the client setup, the file /var/yp/<domainname>/ypservers is populated with the list of servers you enter. This list is used each time the client is rebooted, to establish a "binding" with an NIS server. An alternative method is to rename the previously mentioned file and restart NIS. This causes the client to "broadcast" over the local subnet to try to find an NIS server to bind to. If no server responds, then the client will be unable to use the name service until either an NIS slave server is configured on the same subnet, or the list of servers is re-instated.
Test the NIS client by logging out and logging back in using a login name that is no longer in the /etc/passwd file and is managed by NIS. Test the host's map by pinging a system that is not identified in the local /etc/hosts file.
Setting Up NIS Slave Servers
Before setting up the NIS slave server, you must set it up as an NIS client. After you've verified that the NIS master server is functioning properly by testing the NIS on this system, you can set up the system as a slave server. Your network can have one or more slave servers. Having slave servers ensures the continuity of NIS if the master server is unavailable. Before actually running ypinit to create the slave servers, you should run the domainname command on each NIS slave to be sure that the domain name is consistent with the master server. Remember, the domain name is set by adding the domain name to the /etc/defaultdomain file.
To set up an NIS slaver server, see Step by Step 12.6.
Creating Custom NIS Maps
NIS provides a number of default maps, as we have already seen earlier in this chapter. You can also add your own map to be managed by NIS. This is a simple process where you first create the file with a normal text editor such as vi and then create the map. The following example shows how to create a fictional address book map called abook from the text file /etc/abook. We assume here that the domain being used is pdesigninc.com:
cd /var/yp makedbm /etc/abook pdesigninc.com/abook
The map is now created and exists in the master server's directory. You can now run such commands as ypcat to list the contents of the map. To distribute it to other slave servers, use the ypxfr command.
If you want to verify the contents of an NIS map, you can use the makedbm command with the -u flag. This will write the contents of the map to the screen, so redirect the output to another file if it's going to produce a large amount of text.
To make a new NIS map permanent, you will have to add the details of the new map to the Makefile in /var/yp. Have a look at the Makefile to see how to modify it to add a new entry. When this has been done, any further changes to the new map will automatically be propagated to all other NIS servers when the make command is run.
NIS has been traditionally insecure because the passwd map contains the encrypted passwords for all user accounts. Any user can list the contents of the passwd map, so a potential attacker could easily gather the encrypted passwords for use with a password cracking program. This issue is partially addressed in two ways: by using the passwd.adjunct file to remove encrypted passwords from the passwd map, and using the securenets file to restrict the hosts, or networks, that can access the NIS maps.
The passwd.adjunct Map
If you copy the contents of your shadow file to passwd.adjunct in the same directory as your passwd and shadow files (/var/yp in the examples used in this chapter) then a separate map, passwd.adjunct.byname, will be created. This map is only accessible by the root user and protects the encrypted passwords from unauthorized users. In addition to creating the file, you will also have to modify the NIS Makefile (held in /var/yp) to add the passwd.adjunct entry to the "all" section. This ensures that the map is updated when changes are made.
Extra Editing The only downside of using this option is that when a new user is created or an existing user modified, the passwd.adjunct file must be amended to correctly reflect the current shadow file. This is an overhead for the system administrator, but should be offset against the increased security that is achieved by doing this.
The securenets File
Entries in this file consist of two fields, a netmask and a network.
An example securenets file is shown here:
255.255.255.0 126.96.36.199 255.255.255.0 188.8.131.52 255.255.255.0 184.108.40.206
This code shows that only hosts with IP addresses in the specified networks can access the NIS namespace.
You can also add entries for specific hosts. A modified securenets file is shown below adding two individual hosts:
host 10.48.76.3 host 10.48.76.4 255.255.255.0 220.127.116.11 255.255.255.0 18.104.22.168 255.255.255.0 22.214.171.124
securenets Warning Don't fall into the trap of not allowing your own NIS servers to access the NIS namespace. You should make sure that all NIS servers are covered by the network entries in the securenets file; otherwise they might not be authorized. If any servers are not on these networks then you will need to add individual host entries.
The securenets file is read by the ypserv and ypxfrd processes on startup. If you make any modifications to the securenets file then you must also restart the NIS daemons to allow the changes to take effect.
This section provides some details of how to troubleshoot NIS when problems occur, and the actions to take. It looks briefly at some of the errors seen on the server as well as some of the errors seen on a client.
Problems encountered in an NIS environment normally point to network or hardware problems, especially when there are several NIS servers available. If you find that you cannot connect to an NIS server, or if you are not getting any response to NIS commands, try the following: