NIS

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.

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 systems within an NIS network are configured in the following ways:

• Master server

• Slave servers

• Clients of NIS servers

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

The following guidelines can be used to determine how many NIS servers you need in your domain:

• You should put at least one server on each subnet in your domain, depending on the total number of clients. When a client starts up, it broadcasts a message to find the nearest server. Solaris 10 does not require the server to be on the same subnet, but it is faster and more resilient to do so.

• In general, the number of NIS clients a server can handle is limited by the physical hardware specification and current load of the server. A fast, lightly loaded server can easily support hundreds of NIS clients, while a slower, heavily loaded database server, for example, would struggle to support 50 clients.

Determining Which Hosts Will Be NIS Servers

Determine which systems on your network will be NIS servers as follows:

• Choose servers that are reliable and highly available.

• Choose fast servers that are not used for CPU-intensive applications. Do not use gateways or terminal servers as NIS servers.

• Although it isn't a requirement, it's a good idea to distribute servers appropriately among client networks. In other words, each subnet should have enough servers to accommodate the clients on that subnet.

Information Managed by NIS

As discussed, NIS stores information in a set of files called maps. Maps were designed to replace Unix /etc files, as well as other configuration files.

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

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.

Table 12.5. Default NIS Maps

Map Name	Corresponding NIS Admin File	Description
ageing.byname	/etc/shadow	Contains password aging information.
audit_user	/etc/security/audit_user	Contains per user auditing preselection data.
auth_attr	/etc/security/auth_attr	Contains the authorization description database, part of RBAC.
auto.home	/etc/auto_home	Automounter file for home directories.
auto.master	/etc/auto_master	Master automounter map.
bootparams	/etc/bootparams	Contains the pathnames that clients need during startup: root, swap, and possibly others.
ethers.byaddr	/etc/ethers	Contains system names and Ethernet addresses. The Ethernet address is the key in the map.
ethers.byname	/etc/ethers	Contains system names and Ethernet addresses. The system name is the key.
exec_attr	/etc/security/exec_attr	Contains execution profiles, part of RBAC.
group.adjunct.byname	/etc/group	C2 security option for group files that use passwords.
group.bygid	/etc/group	Contains group security information. The GID (group ID) is the key.
group.byname	/etc/group	Contains group security information. The group name is the key.
hosts.byaddr	/etc/hosts	Contains the system name and IP address. The IP address is the key.
hosts.byname	/etc/hosts	Contains the system name and IP address. The system (host) name is the key.
ipnodes.byaddr	/etc/inet/ipnodes	Contains the system name and IP address. The IP address is the key.
ipnodes.byaddr	/etc/inet/ipnodes	Contains the system name and IP address. The system (host) name is the key.
mail.aliases	/etc/mail/aliases	Contains aliases and mail addresses. The alias is the key.
mail.byaddr	/etc/mail/aliases	Contains mail addresses and aliases. The mail address is the key.
netgroup	/etc/netgroup	Contains the group name, username, and system name. The group name is the key.
netgroup.byhost	/etc/netgroup	Contains the group name, username, and system name. The system name is the key.
netgroup.byuser	/etc/netgroup	Contains the group name, username, and system name. The username is the key.
netid.byname	/etc/passwd	Used for Unix-style hosts and group authentication. It contains the system name and mail address (including domain name). If a netid file is available, it is consulted in addition to the data available through the other files.
netmasks.byaddr	/etc/netmasks	Contains the network masks to be used with IP subnetting. The address is the key.
networks.byaddr	/etc/networks	Contains names of networks known to your system and their IP addresses. The address is the key.
networks.byname	/etc/networks	Contains names of networks known to your system and their IP addresses. The name of the network is the key.
passwd.adjunct.byname	/etc/passwd and /etc/shadow	Contains auditing shadow information and the hidden password information for C2 clients.
passwd.byname	/etc/passwd and /etc/shadow	Contains password and shadow information. The username is the key.
passwd.byuid	/etc/passwd and /etc/shadow	Contains password and shadow information. The user ID is the key.
prof_attr	/etc/security/prof_attr	Contains profile descriptions, part of RBAC.
project.byname	/etc/project	Contains the projects in use on the network. The project name is the key.
project.bynumber	/etc/project	Contains the projects in use on the network. The project number (ID) is the key.
protocols.byname	/etc/protocols	Contains the network protocols known to your network. The protocol is the key.
protocols.bynumber	/etc/protocols	Contains the network protocols known to your network. The protocol number is the key.
publickey.byname	/etc/publickey	Contains public or secret keys. The username is the key.
rpc.bynumber	/etc/rpc	Contains the program number and the name of Remote Procedure Calls (RPCs) known to your system. The program number is the key.
services.byname	/etc/services	Lists Internet services known to your network. The key port or protocol is the key.
services.byservicename	/etc/services	Lists Internet services known to your network. The service name is the key.
timezone.byname	/etc/timezone	Contains the default timezone database. The timezone name is the key.
user_attr	/etc/user_attr	Contains the extended user attributes database, part of RBAC.
ypservers	N/A	Lists the NIS servers known to your network. It's a single-column table with the system name as the key.

The information in these files is put into NIS databases automatically when you create an NIS master server. Other system files can also be managed by NIS if you want to customize your configuration.

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.

Just as you use the cat command to display the contents of a text file, you can use the ypcat command to display the values in a map. Here is the basic ypcat syntax:

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.

These and other NIS commands are covered in the following sections.

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.

Step By Step 12.1: Planning Your NIS Domain 1. Decide which systems will be in your NIS domain. 2. Choose an NIS domain name. AN NIS domain name can be up to 256 characters long, although much shorter names are more practical. A good practice is to limit domain names to no more than 32 characters. Domain names are case sensitive. For convenience, you can use your Internet domain name as the basis for your NIS domain name. For example, if your Internet domain name is pdesigninc.com, you can name your NIS domain pdesigninc.com. 3. Before a system can use NIS, the correct NIS domain name and system name must be set. This must be done on the NIS servers as well as the clients. A system's host name is set by the system's /etc/nodename file, and the system's domain name is set by the system's /etc/defaultdomain file. These files are read at startup, and the contents are used by the uname -s and domainname commands, respectively. A sample /etc/nodename file would look like this: more /etc/nodename The system responds with this: sparcserver A sample /etc/defaultdomain file would look like this: more /etc/defaultdomain The system responds with this: pdesigninc.com In order to set the domain name, you would either have to run the domainname command, entering your domain name as the argument to the command, or reboot if you have edited /etc/defaultdomain. Whichever way you choose, you are now ready to configure your NIS master server.

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.

Table 12.6. NIS Daemons

Daemon	Function
ypserv	This daemon is the NIS database lookup server. The ypserv daemon's primary function is to look up information in its local database of NIS maps. If the /var/yp/ypserv.log file exists when ypserv starts up, log information is written to it (if error conditions arise). At least one ypserv daemon must be present on the network for the NIS service to function.
ypbind	This daemon is the NIS binding process that runs on all client systems that are set up to use NIS. The function of ypbind is to remember information that lets all NIS client processes on a node communicate with some NIS server process.
ypxfrd	This daemon provides the high-speed map transfer. ypxfrd moves an NIS map in the default domain to the local host. It creates a temporary map in the directory /var/yp/ypdomain.
rpc.yppasswdd	This daemon handles password change requests from the yppasswd command. It changes a password entry in the passwd, shadow, and security/passwd.adjunct files.
rpc.ypupdated	This daemon updates NIS information. ypupdated consults the updaters file in the /var/yp directory to determine which NIS maps should be updated and how to change them.

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.

Table 12.7. NIS Commands

Utility	Function
make	This command updates NIS maps by reading the Makefile (if run in the /var/yp directory). You can use make to update all maps based on the input files or to update individual maps.
makedbm	This command creates a dbm file for an NIS map. The makedbm command takes an input file and converts it to a pair of files in ndbm format. When you run make in the /var/yp directory, makedbm creates or modifies the default NIS maps from the input files.
ypcat	This command lists data in an NIS map.
ypinit	This command builds and installs an NIS database and initializes the NIS client's (and server's) ypservers list. ypinit is used to set up an NIS client system. You must be the superuser to run this command.
yppoll	This command gets a map order number from a server. The yppoll command asks a ypserv process what the order number is and which host is the master NIS server for the named map.
yppush	This command propagates a new version of an NIS map from the NIS master server to NIS slave servers.
ypset	This command sets binding to a particular server. ypset is useful for binding a client node that is on a different broadcast network.
ypstart	This command is used to start NIS. After the host has been configured using the ypinit command, ypstart automatically determines the machine's NIS status and starts the appropriate daemons. This command, although still available, is not the recommended way to start NIS and might even have unpredictable results. NIS should be started via the Service Management Facility (SMF).
ypstop	This command is used to stop the NIS processes. This command, although still available, is not the recommended way to stop the NIS processes and might even have unpredictable results. NIS should be stopped via the Service Management Facility (SMF).
ypwhich	This command returns the name of the NIS server that supplies the NIS name services to an NIS client, or it returns the name of the master for a map.

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

• Creating the master group file

• Creating the master hosts file

• Creating other master files

• Preparing the Makefile

• Setting up the master server with ypinit

• Starting and stopping NIS on the master server

• Setting up the name service switch

Each of these tasks is described in the following subsections.

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.

Step By Step 12.2: Creating the Password Source File 1. Copy the /etc/passwd file from each host in your network to the /var/yp directory on the host that will be the master server. Name each copy /var/yp/passwd.<hostname>, in which <hostname> is the name of the host it came from. 2. Concatenate all the passwd files into a temporary passwd file, as follows: cd /var/yp cat passwd passwd.hostname1 passwd.hostname2 ... > passwd.temp 3. Issue the sort command to sort the temporary passwd file by username, and then pipe it to the uniq command to remove duplicate entries: sort -t : -k 1,1 /var/yp/passwd.temp | uniq > /var/yp/passwd.temp Note Sorting the passwd File NIS does not require that the passwd file be sorted in any particular way. Sorting the passwd file simply makes it easier to find duplicate entries. 4. Examine /var/yp/passwd.temp for duplicate usernames that were not caught by the previous uniq command. This could happen if a user login occurs twice, but the lines are not exactly the same. If you find multiple entries for the same user, edit the file to remove redundant ones. Be sure each user in your network has a unique username and UID (user ID). 5. Issue the following command to sort the temporary passwd file by UID: sort -o /var/yp/passwd.temp -t: -k 3n,3 /var/yp/passwd.temp 6. Examine /var/yp/passwd.temp for duplicate UIDs once more. If you find multiple entries with the same UID, edit the file to change the UIDs so that no two users have the same UID. Note Duplicate UIDs and Usernames You will have to resolve duplicate UIDs (where the same UID has been used on more than one system) and usernames (where a user has previously had home directories on each system). The NIS-managed UID will have ownership of any duplicated UID's files unless they are changed accordingly to match modifications made to this file. 7. Remove the root login from the /var/yp/passwd.temp file. If you notice that the root login occurs more than once, remove all entries. 8. After you have a complete passwd file with no duplicates, move /var/yp/passwd.temp (the sorted, edited file) to /var/yp/passwd. This file is used to generate the passwd map for your NIS domain. Remove all the /var/yp/passwd.<hostname> files from the master server.

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.

Step By Step 12.3: Creating the Master Group File 1. Copy the /etc/group file from each host in your NIS domain to the /var/yp directory on the host that will be the master server. Name each copy /var/yp/group.<hostname>, in which <hostname> is the name of the host it came from. 2. Concatenate all the group files, including the master server's group file, into a temporary group file: cd /var/yp cat group group.hostname1 group.hostname2 ... > group.temp 3. Issue the following command to sort the temporary group file by group name: sort -o /var/yp/group.temp -t: -k1,1 /var/yp/group.temp NIS does not require that the group file be sorted in any particular way. Sorting the group file simply makes it easier to find duplicate entries. 4. Examine /var/yp/group.temp for duplicate group names. If a group name appears more than once, merge the groups that have the same name into one group and remove the duplicate entries. 5. Issue the following command to sort the temporary group file by GID: sort -o /var/yp/group.temp -t: -k 3n,3 /var/yp/group.temp 6. Examine /var/yp/group.temp for duplicate GIDs. If you find multiple entries with the same GID, edit the file to change the GIDs so that no two groups have the same GID. Note Duplicate GIDs You will have to resolve duplicate GIDs (where the same GID has been used on more than one system) and group names (where a group has previously existed on each system). The NIS-managed GID will have group ownership of any duplicated GID's files unless they are changed accordingly to match modifications made to this file. 7. Move /var/yp/group.temp (the sorted, edited file) to /var/yp/group. This file is used to generate the group map for your NIS domain. Remove the /var/yp/group.<hostname> files from the master server.

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).

Step By Step 12.4: Creating the Master hosts File 1. Copy the /etc/hosts file from each host in your NIS domain to the /var/yp directory on the host that will be the master server. Name each copy /var/yp/hosts.<hostname>, in which <hostname> is the name of the host from which it came. 2. Concatenate all the host files, including the master server's host file, into a temporary hosts file, as follows: cd /var/yp cat hosts hosts.hostname1 hosts.hostname2 ... > hosts.temp 3. Issue the following command to sort the temporary hosts file so that duplicate IP addresses are on adjacent lines: sort -o /var/yp/hosts.temp /var/yp/hosts.temp 4. Examine /var/yp/hosts.temp for duplicate IP addresses. If you need to map an IP address to multiple hostnames, include them as aliases in a single entry. 5. Issue the following command to sort the temporary hosts file by hostname: sort -o /var/yp/hosts.temp -b -k 2,2 /var/yp/hosts.temp 6. Examine /var/yp/hosts.temp for duplicate hostnames. A hostname can be mapped to multiple IP addresses only if the IP addresses belong to different LAN cards on the same host. If a hostname appears in multiple entries that are mapped to IP addresses on different hosts, remove all the entries but one. 7. Examine the /var/yp/hosts.temp file for duplicate aliases. No alias should appear in more than one entry. 8. Move /var/yp/hosts.temp (the sorted, edited file) to /var/yp/hosts. This file is used to generate the host's map for your NIS domain. Remove the /var/yp/hosts.<hostname> files from the master server.

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:

• /etc/security/audit_user

• /etc/security/auth_attr

• /etc/auto_home

• /etc/auto_master

• /etc/bootparams

• /etc/ethers

• /etc/security/exec_attr

• /etc/inet/ipnodes

• /etc/netgroup

• /etc/netmasks

• /etc/networks

• /etc/security/prof_attr

• /etc/project

• /etc/protocols

• /etc/publickey

• /etc/rpc

• /etc/services

• /etc/shadow

• /etc/timezone

• /etc/user_attr

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.

The Makefile builds passwd maps from the $PWDIR/passwd, $PWDIR/shadow, and $PWDIR/security/passwd.adjunct files, as appropriate.

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.

Step By Step 12.5: Using ypinit to Set Up the Master Server 1. Become root on the master server and ensure that the name service receives its information from the /etc files, not from NIS, by typing the following: cp /etc/nsswitch.files /etc/nsswitch.conf 2. Edit the /etc/hosts file to add the name and IP address of each of the NIS servers. 3. To build new maps on the master server, type /usr/sbin/ypinit -m ypinit prompts you for a list of other systems to become NIS slave servers. Type the name of the server you are working on, along with the names of your NIS slave servers. Enter the server name, and then press Enter. Do this for each server. Enter each server on a separate line. Press Ctrl+D when you're finished. At this point, the entered list of servers is displayed and you are asked if it is correct. Type y if it is correct. If the list is not correct, then type n and you will be returned to the list of servers to add extra entries. 4. ypinit asks whether you want the procedure to terminate at the first nonfatal error or to continue despite nonfatal errors. Type y. If you typed y, ypinit exits upon encountering the first problem; you can then fix the problem and restart ypinit. This procedure is recommended if you are running ypinit for the first time. If you prefer to continue, you can manually try to fix all the problems that might occur, and then restart ypinit. Note Nonfatal Errors A nonfatal error might be displayed if some of the map files are not present. These errors do not affect the functionality of NIS. 5. ypinit asks whether the existing files in the /var/yp/<domainname> directory can be destroyed. This message is displayed only if NIS was previously installed. You must answer yes to install the new version of NIS. 6. After ypinit has constructed the list of servers, it invokes make. The make command uses the instructions contained in the Makefile located in /var/yp. It cleans any remaining comment lines from the files you designated and then runs makedbm on them, creating the appropriate maps and establishing the name of the master server for each map. 7. To enable NIS as the naming service, type cp /etc/nsswitch.nis /etc/nsswitch.conf This command replaces the current switch file with the default NIS-oriented one. You can edit this file as necessary. The name service switch file /etc/nsswitch.conf is described later in this chapter.

Now that the master maps are created, you can start the NIS daemons on the master server.

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.

To manually stop the NIS server processes, run the svcadm disable nis/server command on the server as follows:

svcadm disable nis/server
svcadm disable nis/client

Setting Up NIS Clients

As root, you must perform four tasks to set up a system as an NIS client:

• Ensure that user account information from the /etc/passwd and /etc/group files on the client has already been taken into account in the master passwd and group files. If not, then refer back to the previous section "Setting Up the Master passwd File" and "Creating the Master Group File" for details on how to merge existing account information into the NIS-managed maps.

  Note

  Client Home Directories Home directories that have previously existed on separate systems need to be taken into account when NIS is introduced. Without correct handling, a user's files might come under the ownership of another user, unless they are dealt with at the time of any passwd and group modifications.

  
  

• Set the domain name on the client.

• Set up the nsswitch.conf file on the client, as described earlier in this chapter.

• Configure the client to use NIS, as explained next.

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:

ypinit -c

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.

Step By Step 12.6: Setting Up the NIS Slave Server 1. As root, edit the /etc/hosts file on the slave server to add the name and IP address of the NIS master server. At this point, we are assuming that you're not using DNS to manage hostnames (DNS is covered later in this chapter). Step 3 prompts you for the hostname of the NIS master server. You need an entry for this hostname in the local /etc/hosts file; otherwise, you need to specify the IP address of the NIS server. 2. Change directories to /var/yp on the slave server. 3. To initialize the slave server as a client, type the following: /usr/sbin/ypinit -c The ypinit command prompts you for a list of NIS servers. Enter the name of the local slave you are working on first and then the master server, followed by the other NIS slave servers in your domain, in order, from the physically closest to the farthest (in network terms). 4. Next, you need to determine whether ypbind is already running. If it is running, you need to stop and restart it. Check to see if ypbind is running by typing this: pgrep -l ypbind If a listing is displayed, ypbind is running. If ypbind is running, stop it by typing this: svcadm disable nis/client 5. Type the following to restart ypbind: svcadm enable nis/client 6. To initialize this system as a slave, type the following: /usr/sbin/ypinit -s master In this example, master is the system name of the existing NIS master server. Repeat the procedures described in these steps for each system that you want configured as an NIS slave server. 7. Now you can start daemons on the slave server and begin the NIS. First, you must stop all existing yp processes by typing the following: svcadm disable nis/server To start ypserv on the slave server and run ypbind, you can either reboot the server or type the following: svcadm enable nis/server

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 Security

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.

The securenets File

A further enhancement to NIS security is to restrict the hosts, or networks, that can access the NIS namespace. The file /var/yp/securenets achieves this.

Entries in this file consist of two fields, a netmask and a network.

An example securenets file is shown here:

255.255.255.0 210.100.35.0
255.255.255.0 210.100.36.0
255.255.255.0 210.100.37.0

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 210.100.35.0
255.255.255.0 210.100.36.0
255.255.255.0 210.100.37.0

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.

Troubleshooting NIS

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.

Binding Problems

Normally, when a client fails to bind with an NIS server, one of the following has occurred:

• ypbind isn't running on the client: In this case enter svcadm enable network/nis/client to start the process.

• The domain name is set incorrectly or not set at all: Check the contents of /etc/defaultdomain or run the domainname command. Frequently, this problem occurs because the domain name has been set manually, but not entered into the file /etc/defaultdomain, so when the system is rebooted, the domain name is lost.

• No NIS server is available: This would point to a possible network problem, particularly if you have several NIS servers configured in the domain. Check that the client has network connectivity. If only a single NIS server is present, then you should check that the ypserv daemon is running. Also, check that the client's /etc/nsswitch.conf is configured correctly.

Server Problems

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:

• ping the server to make sure it is accessible across the network.

• Run ypwhich to verify which server you are meant to be bound to.

• Check that the NIS daemons are running on the server and restart the service if necessary. You can restart the NIS server by executing svcadm restart network/nis/server.

• Check that the server isn't busy or overloaded. Use commands such as vmstat, iostat, and netstat to monitor the server for possible performance issues.