Dale W Park
Computer Science 193
NIS Overview
Section 0 Introduction
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.
Section 1 Introduction of NIS
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.)
Section 2 How NIS Works
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:
passwd.dir |
Index file |
passwd.pag |
Data file |
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:
Section 3 Enabling NIS
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:
Setting up NIS on clients includes:
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:
File |
Contains |
/etc/passwd |
User names, User Ids, and passwords |
/etc/hosts |
Hostnames and IP addresses |
/etc/ethers |
Ethernet numbers (MAC addresses) |
/etc/networks |
Network addresses |
/etc/netgroup |
Netgroup definitions (used by NIS) |
/etc/protocols |
Network protocol names and numbers |
/etc/group |
User groups |
/etc/bootparams |
Information about diskless nodes |
/etc/aliases |
Aliases and mailing lists for the mail system |
/etc/protocols |
Network protocol names and numbers |
/etc/netmasks |
Network ‘masks’ |
/etc/rpc |
Remote procedure call program numbers |
/etc/services |
Network port numbers and service names |
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:
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.
Section 4 Some Common NIS Tools
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:
ypcat passwd | grep -i /home/d
day:*:13:John Day:/net/horton/u4/home/day:/bin/csh
diego:*:9056:6208:Diego H. Pedreros:/net/oberon-u2/home/diego:/usr/local/bin/tcsh
danny:*:9052:6004:Danny Marks:/home/horton/u4/home/danny:/usr/local/bin/tcsh
damko:*:4018:31:(Jim Damkowitch):/net/maxz/u2/home/damko:/bin/csh
dar:*:1025:11:Dar Roberts, EH 5703:/net/oberon-u1/home/dar:/bin/csh
ypmatch dwp176 passwd
dwp176:*:14758:7176:Dale Winston Park:/net/class2/176/dwp176:/local/bin/tcsh
Section 5 Conclusions
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.