Dale W Park

Computer Science 193

NIS Overview

During this past summer I had the fortune of working at one of the leading companies within the computer industry – Sun Microsystems. The experience I gained there is priceless. Real hands on experience, taking what was learned in the academic environment and implementing that in practical solutions. It is amazing.

I do not come from a computer science background. Rather, my computer experience comes mainly from two sources: one, an insatiable desire to constantly learn about any type of technology, and two, the work experienced I gained from working on campus at Instructional Computing (formally known as MCL). I have been working there for nearly the two years I have been here since I transferred from a community college. I have slowly moved up the ranks there, starting out as a lab consultant, then moving up to joining the Microsystems Group (MSG) and the Faculty Liaison (FL) team where I handled student’s technical needs (MSG) and faculty’s technical needs (FL). After a year, I was given the opportunity to manage the two groups. And I have been doing that ever since.

Everything I know about computers I learned three years ago. Before then I knew nothing -- literally—about computers. When our family did buy a computer three years ago, it took me three hours (yes, painstakingly, it took me that long) to install our new modem. I was dealing with something way over my head- dealing with Com ports, jumper settings, and finding free IRQs. But since then I have tried to learn as much as I could. Taking classes in programming languages, networking, administration and anything else I could learn about. I’ve learned about hardware and the concepts behind them (i.e. interfaces between sub-system components and how they communicate), built computers, and consulted clients on system choices.

Now it is time for me to leave here and move on. I will be returning to Sun Microsystems to work for their Enterprise Network Services department as a UNIX System Administrator for both the Corporate and Javasoft divisions. I will be working with a group of 10 SysAdmins at the Cupertino Campus. I am sure there is a lot for me to learn there and I look forward to this new challenge.

One of the major problems of a large heterogeneous networked computing environment is maintaining separate copies of common configuration files such as the password, group, and hosts files. Ideally, the network should be consistent in its configuration, so that users don’t have to worry about where they have accounts or if they’ll be able to find a new machine on the network. Preserving consistency, however, means that every change to one of these common files must be propagated to every host on the network. As you can imagine, in a large computing environment with hundreds or thousands of systems, these simple administrative tasks can turn into a very long project. Furthermore, without an automated tool for making these changes, simple typo mistakes become more of a reality than a possibility.

NIS (Network Information System) tries to address these problems. It is a database system that replaces copies of commonly replicated configuration files on all hosts on the network with one centralized copy managed on a single, dedicated server. Instead of managing configuration files on each host (i.e. /etc/hosts, /etc/group, etc.), the administrator maintains a database for each configuration file on one dedicated server. Clients that use NIS can retrieve information as needed from these databases. And so, the primary purpose of NIS is to ensure the consistency of system administration information in a heterogeneous network environment. It does so by designating a single machine as the master of these configuration files and databases containing this information and provides a method to distribute the information to all other hosts on the network. (Note: the term NIS now refers to the service formerly known as Sun’s Yellow Pages or YP. The functionality remains the same; only the name has changed. Nonetheless, many NIS utilities retain the yp prefix, for example, ypmake and ypserv.)

NIS uses the client-server architecture to distribute information. A NIS server is a host that contains and manages NIS data files, known as maps. And a NIS client is a host that request information from these maps. NIS servers are further broken down to two types: master or slave-servers. The master-server (there is only one per domain) is the true single owner of the maps and it is the only one that can modify maps. Slave-servers can not modify map content, rather they exists only to handle client requests for map information. When NIS is initialized on the master-server, files being managed by the server are compiled into a series of maps. The maps are then propagated to all slave-servers on the network. All NIS servers have the same information, this is because a NIS client may request information from either a slave-server or the master-server. More on maps later.

As mentioned above, there can be only one master-server per domain- more accurately, per NIS domain. A NIS domain defines the group of computers sharing configuration information. A NIS domain consists of a single host serving as the master-server of the domain and all of the slave NIS servers and NIS clients who rely on that master for their configuration information. All NIS servers and clients within a NIS domain store a common domain name. This name is established during NIS initialization of the server or client. This domain name is used for authentication within NIS and is used to name the directory within which each host stores the NIS maps for that domain. For example, maps for the engineering domain would be stored in the /etc/yp/engineering directory.

NIS maps are initially constructed from DBM database files via the makedbm NIS utility. Under DBM, a database consists of a set of keys and associated values organized in a table with fast lookup capabilities. Specifically, the dbm database consists of a pair of files that are created by calls to the makedbm library package. One file contains a directory (that is, a bitmap of indices accessed by a hash table), ending with the .dir extension; the other file contains data, ending with the .pag extension. So, as an example, makedbm would create a database from the passwd file as:

Every key and value pair may be located using- at most- two filesystem accesses, making DBM an efficient storage mechanism for NIS maps.

But there are a few drawbacks to this system. One, DBM databases can only support one key per value. This means that if a configuration file needs to be accessed by more than one field value, NIS maps must be created for each key. A good example of a configuration file that warrants multiple NIS maps is the password file. A typical entry in the password file includes the user name, encrypted password, the user’s real name, user id, and group id. By making a map using the user name as key and another map using the user id as key, you can create two methods to search for a value within the password file. The actual map nomenclature used by NIS usually indicates the source of the data and the key field. So for the two password maps being created, their map names would be passwd.byname and passwd.byuid. The convention for map naming is:

filename.bykeyname

And two, because of the non-ASCII file structure imposed by dbm, you cannot edit the maps directly. You must edit the original ASCII files. Once the edits are done, NIS tools such as make are used to rebuild the maps from their original ASCII files, and ypxfr or yppush are used to propagate the maps from the master-server to the slave-servers.

Propagating (pushing) a map means moving it from place to place, generally from the NIS master server to a NIS slave server. Initially, the map is moved at system startup. Maps are not propagated to clients because clients request map information from servers rather than storing the maps themselves. After a NIS slave-server is initialized, xpxfr transfers updated maps from the master server. There are, however, other ways to push map information, the ypxfr command can be run in the following ways:

1. periodically by cron,
2. interactively by a user, or
3. by yppush

1. Maps have different rates of change; for instance, protocols.byname might not change for a long time, but passwd.byname might change several times a day in a large organization. You can set up a crontab entry as root to run ypxfr periodically at a rate appropriate for any map in a NIS database. The ypxfr program contacts the master server and transfers the map only if the master's copy is more recent than the local copy.
2. To use the interactive approach, run ypxfr as a command. Typically, this is done only in exceptional situations: for example, when setting up a temporary NIS server to create a test environment, when transferring a new NIS map, or when quickly updating an NIS server that was out of service.
3. The ypxfr command is also invoked by ypserv when the yppush command is run on the NIS master server. Yppush enumerates the NIS map ypservers to generate a list of NIS servers in the domain and sends a ``Transfer Map'' request to each named NIS server. The ypserv command spawns a copy of ypxfr, invoking it with the -C flag, and passes it the information needed to identify the map and call back the initiating yppush process with a summary status.

With the conceptual information laid out, we can now concentrate on how to enable NIS. This process can be broken down into two basic process: setting up NIS servers and enabling NIS on all the clients.

Setting up NIS servers includes:

• Installing a new NIS environment and building both the master server and all slave servers.
• Starting the ypserv daemon. This enables the system to act as a NIS server.

Setting up NIS on clients includes:

• Editing the client’s configuration files (i.e. /etc/passwd) to take advantage of NIS.
• Starting the ypbind daemon. This enables the client to make NIS queries.

Before we set up the NIS server, a domain name must be chosen for the NIS domain. This can be done on the master server using domainname. After establishing the domain’s name, a quick check of configuration files used by NIS for any errors should be done. Any incorrect entries could cause havoc. A list of commonly managed files by NIS are:

With NIS running, all these files will be replaced with maps and then managed by NIS. Once all files are in order the master server is ready to be initialized. To do so, run the ypinit utility. First, become the superuser on the host to become master server and invoke ypinit with the –m flag:

master# ypinit -m

Invoking this command will create all the necessary sub-directories in the /var/yp for the current NIS domain. Assuming the NIS domain name was enterprise, then the ypinit –m command will create the /var/yp/enterprise directory.

Once the domain directory is created, ypinit creates all maps from the configuration files listed above and places them within the enterprise directory. Maps are created in a specific order, ypservers being the first map created. This map contains a list of all NIS servers in the domain and ypinit will request a list of hosts that will be used as NIS servers. After the initialization process has completed, you can start NIS by manually giving the ypserv command or by rebooting the master server.

It is only after the master server has been brought up with NIS running can you bring up all other NIS servers (slave servers). Slave servers are also initialized using the ypinit command. However, instead of specifying the –m option, you must use the –s option and the name of the NIS master server:

slave# ypinit –s enterprise

After initialization of the slave server is complete, it will transfer maps from the master server and build it’s own copies of the maps. Remember, since the master server is the only one that can make changes to the maps and its maps override all other maps, any map information or pre-map information (ASCII files of the maps) on the slave server will be superceded by the master server. Also, only those slave servers whose names are listed within the ypservers file on master server will be recognized by NIS as slave servers. Therefore, if slave servers are added later, the ypservers file must be edited to include the new slave servers.

Once all the NIS servers are in place and running, focus can be given to setting up NIS clients. As mentioned earlier, NIS clients do not have its own copies of maps, rather, they query information from the NIS servers.

Basically, to enable NIS on a client host, three things must be in place:

1. Configuration files on the client must point to NIS. This can be accomplished by adding a + to the respective files.
2. The domain name must be set on the client. This can be accomplished by utilizing the domainname tool.
3. The ypbind daemon must be started on the client. This allows the client to locate NIS servers and maintain a binding of domain names to servers.

Once NIS is running two possible outcomes can occur for local configuration files. One outcome is that NIS completely replaces local files. These would include ethers, hosts, netmasks, netgroups, networks, protocols, rpc, and services. These files are completely ignored while NIS is running. Another outcome is that NIS augments or appends itself to local files. These files are passwd, bootparams, group, and aliases. A + must be included at the end of the file in order to have NIS augment the local file. The methodology of NIS augmented files is: local files are read first, if the appropriate entry cannot be found in the local file, then the respective NIS map is consulted. By appending a + at the end of a file it ensures that the local entries will be read first before the NIS maps are consulted.

The most common NIS tools are ypcat and ypmatch. These are tools that help get information out of NIS maps. There are some differences between the two tools in their output. Ypmatch locates a key in a NIS map and prints the data value associated with that key, while ypcat dumps all data values in the entire NIS map that matches the search parameters. Ypmatch should be used when you are searching for a particular data value associated with that key, while ypcat should be used when you need to search an entire NIS map for a field other than the key (i.e. searching for home directory of a user in the passwd.byname map). Below are some outputs of searches made on a NIS client:

NIS gives a large, heterogeneous, networked computer environment an effective management strategy. Centralizing common configuration files into one location allows for quick and easy changes. And pushing NIS maps from the master server to the slave servers relieves the workload for the master server. All of this allows users to freely move between clients within a NIS domain and retrieve all their data.