Certification Objective 11.02Working with NIS
Certification Objective 11.02—Working with NIS
Exam Objective 5.5: Configure the NIS domain: build and update NIS maps, manage the NIS master and slave server, configure the NIS client, and troubleshoot NIS for server and client failure messages.
NIS is a distributed naming service that provides a mechanism for identifying and locating network entities and resources. It enables you to store and retrieve network information in a standard way and to distribute this information in the form of maps over master servers and slave servers. Then, you can update that information from a central location—that is, you don't need to log on to each server individually to update the information. This will ensure that all clients share the same naming service information, which is consistent throughout the network.
The main components of the NIS service are NIS maps and NIS master and slave servers.
Managing NIS Maps
As you know, NIS is used to manage network information. The set of files in which NIS keeps the information is referred to as NIS maps. These files are written in a binary format called ndbm. Historically speaking, network information was originally maintained in /etc and some other configuration files, and the maps were designed to replace those files. As you will see, the maps contain much more than just the names and addresses.
The information in NIS maps is stored in two-column tables, one column containing the key and the other column containing the information associated with the key. For example, a key may be the name of a host, and the information column may contain the IP address of the host with that name. Solaris offers a set of default maps for an NIS domain in the following directory of the NIS domain server:
/var/yp/<domainName>
For example, the maps for the domain capital.com will be in the /var/yp/capital.com directory. Some of these maps are listed in Table 11-3.
| Map Name | Corresponding NIS Admin File | Description |
|---|---|---|
| auth_attr, exec_attr, prof_attr, user_attr | auth_attr, exec_attr, prof_attr, user_attr | Contains attribute information about profiles, users, and authorization; part of RBAC as discussed in Chapter 14. |
| bootparams | bootparams | Contains the path names for files that the client needs during boot: root, swap, and so forth. |
| ethers.byaddr, ethers.byname | ethers | Contain name-to-address mapping. The key in the ethers.byaddr file is the Ethernet address, whereas the key in the ethers.byname file is the machine name. |
| group.bygid, group.byname | group | Contain group security information with group ID as the key in the group.bygid file and group name as the key in the group.byname file. |
| hosts.byaddr, hosts.byname | hosts | Contain machine name and IP address with address as the key in the hosts.byaddr file and name as the key in the hosts.byname file. |
| ipnodes.byaddr, ipnodes.byname | ipnodes | Contain machine name and IP address with address as the key in the ipnodes.byaddr file and name as the key in the ipnodes.byname file. |
| mail.aliases, mail.byaddr | aliases | Contain alias and mail address with alias as the key in the mail.aliases file and address as the key in the mail.byaddr file. |
| netgroup, netgroup. byhost, netgroup. byuser | netgroup | Contain group name, user name, and machine name with group as the key for the netgroup file, host as the key for the netgroup.byhost file, and user as the key for the netgroup.byuser file. |
| netmasks.byaddr | netmasks | Contains the network mask information for IP addresses with IP address as the key. |
| networks.byaddr, networks.byname | networks | Contain network names known to your system and their IP addresses with IP address as the key for the networks.byaddr file and name as the key for the networks.byname file. |
| passwd.byname, passwd.byuid | passwd, shadow | Contain password information with user name as the key in the passwd.byname file and user ID as the key in the passwd.byuid file. |
| protocols.byname, protocols.bynbumber | protocols | Contain the network protocols known to your network with protocol name as the key in the protocols .byname file and protocol number as the key in the protocol.bynumber file. |
| rpc.bynumber | rpc | Contains the program number and the name of the RPCs known to your system with the RPC number as the key. |
| services.byname, services.byservice | services | Contain the list of network services known to the network with port (or protocol) on which the service is running as the key in the services.byname file and service name as the key in the services.byservice file. |
If you wanted to use the /etc files to manage network information, you would have to change the files on all the machines to reflect a change in the network environment. In the case of NIS maps, you only have to update the information on the master server, and the update will be propagated automatically to the slave servers. The client machines will get this information as needed from the servers (primary or secondary). As an example, suppose you add a new machine to your network, which is running NIS. You will do the following:
-
Update the input file in the master server only (you will learn how further along).
-
Run the make utility. This will automatically update the hosts.byname and hosts.byaddr files on the master server.
-
These updates will be propagated automatically to the slave servers and will be available to the client machines.
Now you can see how NIS (as opposed to /etc files) simplifies the process of information management. But what is the input file and what is the make utility? The make is the utility that transforms the information in the input file into ndbm format (i.e., the map format). The input file is a text file that simply contains the information that the /etc file will contain. For example, suppose you add a new user with user name agore; a line like the following will be added to the /etc/passwd file:
agore:x:123:10:User agore:/home/agore:/bin/csh:
You would copy this line to the password input file that the make utility will then transfer to the password map, such as passwd.byuid.
When you designate a machine as server during installation, a Makefile is stored in the /var/yp directory. When you run the make command, it is the instructions in the Makefile that are actually executed; they locate the input files and execute makedb, which creates or updates NIS maps from the input files.
| On the Job | You should always create maps on the master server, because they will be automatically pushed to the slave servers. If you create maps on a slave server, they will not automatically be pushed to the master server, or to other slave servers. |
So it is the NIS master server on which you create or update maps. Let's explore how to manage the master server.
Managing the NIS Master Server
Recall that without NIS, we would have /etc files to manage network information on each machine. It is basically these files that make the source files for the NIS server. The goal is to convert these files on the server machine into NIS maps and then manage the NIS maps and serve the information from them.
Preparing the Source Files
The source files are the text files that will be converted to NIS maps, and they originally reside in the /etc directory. But you want to separate the view of the source files and the local files for various reasons. For example, local files also include passwd and shadow files, and if you use the /etc as the source file directory, the passwd file will also be converted to a NIS map and made available to the clients. Therefore, a good strategy is to use some other directory as a source directory and copy the necessary files from the /etc directory into this source directory. Edit the passwd file in the source directory, and remove the root entry from it. To find out in detail how to prepare the source files, check out the following exercise.
Exercise 11-1: How to Prepare Source Files for Conversion to NIS Maps
 |
To prepare the source files for conversion into NIS maps, perform the following steps:
-
Log on to the machine that will be the primary NIS server. Become a superuser.
-
You need to make sure that the files in the /etc directory that will be the source files reflect an up-to-date picture of your system. To do this, check the following files:
-
auto.home or auto_home
-
auto.master or auto_master
-
bootparams
-
ethers
-
group
-
hosts
-
ipnodes
-
netgroup
-
netmasks
-
networks
-
passwd
-
protocols
-
rpc
-
service
-
shadow
-
user_attr
-
-
Copy all of these source files, except passwd, to the <DIR> directory that you have specified in the /var/yp/Makefile to be the source directory.
-
Copy the passwd file to the password directory <PWDIR> that you have specified in the Makefile as a source directory for the password file.
-
Copy the audit_user, auth_attr, exec_attr, and prof_attr to the selected <RBACDIR> directory that you have specified in the Makefile.
-
Check the /etc/mail/aliases file. Unlike other source files, you cannot move this file to another. However, make sure that it has all the mail aliases that you want to make available throughout the domain.
-
Weed out all the comments and other extraneous information from the source files. The Makefile does perform some file cleaning automatically, but it's good practice to examine and clean these files manually.
-
Check each source file and make sure the data is in the correct format.
|
The source files, once prepared, must be converted to NIS maps. The Makefile will do that. But you first need to make sure the Makefile will do the right thing.
Preparing the Makefile
When you designate a machine as server during installation, a Makefile is stored in the /var/yp directory. Because you are recommended to put the source files in a directory other than the /etc directory, you will need to make a few changes in the Makefile. Before making these changes, copy the original Makefile to some other name, to be on the safe side. Make any of the following changes in the Makefile if necessary:
-
DIR value. The value of DIR in the Makefile is the /etc directory by default. If you have copied the source files to some other directory, change the value of the DIR field accordingly.
-
PWDIR value. If you have copied the passwd and shadow files to a directory other than the /etc directory, change the value of the PWDIR field accordingly.
-
Domain name resolver. If you want your server to use the domain name resolver for machines not in this domain, comment out the following line:
B=
and uncomment the following line:
B=-b
| On the Job | Make sure that the source password file on the master server that will be used to make the password map file does not have an entry for the root, and that the source file is in a directory such as /var/yp (not in the /etc directory); then change the value of PWDIR accordingly. When you change the values of DIR or PWDIR in the Makefile, make sure you do not indent the line. |
Now that you have prepared the source files and modified the Makefile accordingly, you are ready to convert the source files into NIS maps. Solaris offers the ypinit command to accomplish that.
Setting Up the Master Server with the ypinit Command
The ypinit command is used to set up the master server, the slave servers, and the clients for NIS. It also builds a fresh set of NIS maps from the source files cited in the Makefile. After you issue the ypinit command to build NIS maps, the following steps are executed:
-
The ypinit script constructs the list of servers.
-
The ypinit command invokes the make command.
-
The make command cleans up the remaining comments in the Makefile.
-
The make command uses the Makefile to find out where the source files are and runs makedbm to convert the source files to the NIS maps.
Keep in mind that the domainname command is used on the master server to determine to which domain the maps will be pushed. If you are not sure it will do the right thing, you can hard code the domain into the make command in the ypinit script. For example, the following command in the ypinit script will push the passwd file to the domain senate.com:
make DOM=senate.com passwd
This way you can push a map file to the intended domain, even if the domain is different from that of the master server.
Check out the following exercise to see how you can use the ypinit command to set up an NIS master server.
Exercise 11-2: Setting Up a Master Server by Using the ypinit Command
|
You can set up the master server for NIS, by performing the following steps:
-
Log on to the master server machine as superuser.
-
Copy the /etc/nsswitch.files file to the /etc/nsswitch.conf file by issuing the following command:
cp /etc/nsswitch.files /etc/nsswitch.conf
-
Edit the /etc/hosts and /etc/inet/ipnodes file and add the name and IP address of each of the NIS servers.
-
To build new NIS maps on this master server, issue the following command:
/usr/sbin/ypinit -m
When you are prompted by ypinit for a list of other machines to become NIS slave servers, type the name of the server you are working on along with the names of other machines that you want to become NIS slave servers.
-
When you are asked by ypinit whether you want the procedure to terminate at the first nonfatal error or continue despite nonfatal errors, type y. If you choose y, and ypinit encounters a problem, it will exit. In this case, fix the problem and restart ypinit.
-
You are asked whether the existing files in the /var/yp/<domainName> directory can be destroyed. Obviously, this message would appear only if NIS was previously installed. At this point, the ypinit command executes the make command that triggers converting the source files to the NIS maps.
-
Issue the following command to enable NIS as the naming service:
cp /etc/nsswitch.nis /etc/nsswitch.conf
Note that by issuing this command you are replacing the existing switch file with the default NIS-oriented switch file. You can edit this file later if it becomes necessary.
|
Note that the passwd maps are built from the /PWDIR/passwd, /PWDIR/shadow, and /PWDIR/security/passwd.adjunct files, and the value for the PWDIR field is defined in Makefile. Make sure this field carries the correct value; otherwise, change it.
The NIS maps that will be created are listed under all in the Makefile. After the makedbm command has been executed, the information is collected in the following two files:
mapname.dir mapname.pag
Both of these files reside in the /var/yp/<domainName> directory on the master server where the <domainName> specifies the domain. Once you set up the server with the ypinit command, it will automatically be started each time the machine is booted. However, situations may arise in which you will need to stop and restart the server when system is up and running.
Domains and Daemons
You can look at an NIS domain as a collection of Solaris machines that share a common set of NIS maps. A domain has a domain name, and each machine sharing the common set or maps belongs to that domain. Any machine on a network can be configured to belong to a given domain, as long as there is a server on the network to maintain the domain's NIS maps. An NIS client machine acquires its domain name and binds to an NIS server at boot time.
|
Make sure you understand that the NIS utilities are different from the NIS daemons and you know the function of each daemon and utility. In other words, you should be able to identify a daemon or a utility needed to accomplish a given task.
|
The NIS service is managed by Service Management Facility (SMF), as discussed in Chapter 10, and the service itself is provided by five daemons (background processes running all the time) listed in Table 11-4.
| Daemon | Description |
|---|---|
| ypserv | The NIS server process |
| ypbind | Binding process |
| ypxfrd | High-speed map transfer |
| rpc.yppasswdd | The NIS daemon to update the passwords |
| rpc.ypupdated | Modifies other maps such as public key |
In addition to the five daemons that keep the service running, a number of utilities, listed in Table 11-5, support the service.
| Utility | Description |
|---|---|
| ypcat | Lists data in a map. |
| ypinit | Initializes NIS client's server's list ypservers, and builds and installs an NIS database. Used to set up a client. |
| ypmatch | Looks up a specific entry in a map. |
| yppoll | Gets a map order number from a server by using the ypserv daemon. |
| yppush | Pushes an NIS map from the master server to the slave servers. |
| ypset | Sets binding of a machine to particular server. |
| ypwhich | Returns the name of the NIS server for this client as well as the nickname translation table. |
| ypxfr | Transfers NOS maps from a master server to the slave servers. |
You can administer (enable, disable, restart, and the like) these processes by using the svcadm command.
Starting and Stopping the NIS Service
Once you have configured the NIS master server by using the ypinit command, the server is started automatically during boot time by invoking the ypstart command. You can also stop and start (or restart) the server when the system is up and running.
You can stop the server by using cither of the following two commands:
svcadm disable network/nis/server ypstop
You can start the server by using either of the following two commands:
svcadm enable network/nis/server ypstart
To restart (stop and immediately start) the server, you can issue the following command:
svcadm restart network/nis/server
Recall from Chapter 10 that the svcadm is an SMF (Service Management Facility) utility.
At this point, the master server is up and running and you know how to stop and restart it. Now you can set up a slave server. However, note that before you can configure a machine as a slave server for the first time, it must be configured as a client. With that said, let's first finish the server story before we move on to the clients.
Managing the NIS Slave Servers
You can have one or more slave servers for one master server. A slave server is the server that contains a copy of the network information from the master server. Remember, the updates are made only on the master server and then pushed to the slave servers. The slave servers are useful in two ways: they can balance the load by serving requests from the clients, and they offer fault tolerance by continuing to serve if the master server goes down.
To set up a slave server follow the instructions in the following exercise.
Exercise 11-3: Setting Up an NIS Slave Server
|
To set up an NIS slave server, perform the following steps:
-
Log in as superuser to the machine you want to set up as a slave server. Perform the following steps on this machine.
-
Add the names and IP addresses of all the other NIS servers to one of the following files:
/etc/hosts /etc/inet/ipnodes
-
Change the directory to /var/yp.
-
Initialize the machine as a client by issuing the following command:
/usr/sbin/ypinit -c
The ypinit script will prompt you for a list of NIS servers. Enter the names in the following order: the server that you are setting up, the master server, and other NIS slave servers.
-
Determine whether the NIS client is running by issuing the following command:
svcs network/nis/client
-
If you determined in step 5 that the client was running, restart the client service with the following command:
svcadm restart network/nis/client
If you determined that the client was not running, start the client by issuing the following command:
svcadm enable network/nis/client
-
Initialize this machine as a slave by issuing the following command:
/usr/sbin/ypinit -s <masterServer>
The <masterServer> argument specifies the name of the master server that has already been configured (set up).
-
Repeat steps 1 to 7 for each machine you want to configure as an NIS slave server.
|
NIS is a network service offered in the client/server environment. Now that you know the server side of NIS, let's explore the client side.
EAN: N/A
Pages: 168