NIS Maps

The following list shows the “important” administration files that will be brought under the control of NIS so we know which ones we need to be concerned with:

• /etc/aliases

• /etc/auto_home

• /etc/auto_master

• /etc/bootparams

• /etc/ethers

• /etc/group

• /etc/hosts

• /etc/netgroup

• /etc/netmasks

• /etc/networks

• /etc/passwd

• /etc/protocols

• /etc/rpc

• /etc/services

• /etc/timezone

To do this, they are imported into NIS and stored as a series of database files under the NIS data directory, /var/yp. These database files are known as the “NIS maps” and are based on a simple database format known as “dbm,” which stores and indexes its data in files using the following naming convention:

• <filename>.pag (this contains the data)

• <filename>.dir (this is an index to the .pag file)

For example, the /etc/inet/hosts file would be read and from it a NIS hosts database consisting of the following two files would be produced:

hosts.pag

hosts.dir

The “dbm” format works on a “key-value” pair. This means that each entry comprises a single key field that can be searched and a value that is associated with the key. Since the database can only have one key field, this means that if we need to search using a different key, we have to create another file that uses the new key.

For example, sometimes we may want to determine the hostname of a machine using its IP address as the key, while at other times we might want to determine the IP address using the hostname as the key. To do this, a hosts.byname and a hosts.byaddr file is generated. The hosts.byname is used when we know the name and want to find the IP address (the key is the name) and the hosts.byaddr map is used when we know the IP address but need the name (the key is the IP address).

Another example is the password database; the NIS password maps are passwd.byuid and passwd.byname, which use a key of the UID and the login name, respectively.

To automate the maps' creation we use two additional utilities—make and makedbm, which we'll take a look at now.

Makedbm

Makedbm takes an input file (or standard input) and generates the “dbm” formatted files (both the index and the data file). Let's run it on a portion of the password file to illustrate how it works:

tin# head -3 /etc/passwd | makedbm - /tmp/passwd
tin# ls -l /tmp/passwd*
-rw-------   1 root     other       0 Jun  6 12:11 /tmp/passwd.dir
-rw-------   1 root     other    1024 Jun  6 12:11 /tmp/passwd.pag
tin#

Once we have generated the database file, we can also use makedbm to display its contents, as shown below:

tin# makedbm -u /tmp/passwd
root:x:0:1:Super-User:/:/sbin/sh
bin:x:2:2::/usr/bin:
daemon:x:1:1::/:
YP_LAST_MODIFIED 1016794876
YP_MASTER_NAME tin
tin#

We can see that the output also contains additional lines. These are some of the keys that can be added along with the data. They are used by NIS and, because makedbm is primarily used for NIS, some of these keys are added by default.

The list of available keys and what they represent are shown in Table 12.5.

The following comparison shows how the key is stored in one of the NIS maps, along with how it is used by one of the NIS commands:

tin# cd /var/yp/nis.solarisbootcamp.com
tin# makedbm -u passwd.byuid | grep YP
YP_LAST_MODIFIED 0997357987
YP_MASTER_NAME tin
tin#

tin# yppoll passwd.byuid
Domain nis.solarisbootcamp.com is supported
Map passwd.byuid has order number 0997357987
The master server is tin
tin#

Make and Makefiles

Imagine how often the files might change due to, for example, users altering their passwords or machines being moved around the network. It's a very time-consuming process for us to have to run the makedbm commands manually—in fact, it has already taken us quite a few pages to get this far! To automate the procedure we use make, which is a tool often used by programmers to build files rapidly by defining dependencies between them.

Briefly, make allows us to define a series of targets (the files that need building) and a set of dependencies for them. It then checks the time stamps of the targets and their dependents to see if they are different. If the target is up-to-date, then fine, nothing happens. If it isn't, it will be rebuilt.

The rules, target, and dependencies are supplied to make through a file known as a makefile, which by default is called either Makefile or makefile.

NIS distributes a makefile that defines a whole series of rules that allows us to build the entire “standard” NIS maps. This automates the entire process for us, so we only need to enter the sequence of commands shown below to build the whole set.

If this sounds a little complicated, don't be too concerned; we'll take another look at it later in the section “Customizing NIS” on page 300.

One thing that we do have to be aware of is that make is installed in /usr/ccs/bin, which in most cases is not in the user's path (see Chapter 5, “Shells”). Just to be sure we'll use the full path here, but later in the chapter we'll assume the path has been set correctly and just refer to make, so everything looks clearer:

tin# cd /var/yp
tin# /usr/ccs/bin/make
tin#

Alternatively, we can build a specific map by passing it as a parameter to make:

tin# cd /var/yp
tin# /usr/ccs/bin/make passwd
tin#

DNS Forwarding

If the machine is configured for DNS, then any host lookups that cannot be determined can be passed onto the DNS server. This is termed “DNS forwarding” and is configured as follows.

First, we need to inform NIS that it should forward any failed queries onto DNS, which we do by updating /var/yp/Makefile. After the changes, it will look like the one shown below:

hydrogen# cat /var/yp/Makefile
<lines removed for clarity>
#
# Set the following variable to "-b" to have NIS servers use the
# domain name resolver for hosts not in the current domain.
B=-b
#B=
<lines removed for clarity>
hydrogen#

When the maps are next rebuilt, makedbm will insert the YP_INTERDOMAIN key into them, which forces ypserv to pass its failed query onto DNS.

This also means that we don't need to specify both “dns” and “nis” as name service options when we add support for NIS to the system. For example, if the machine is already configured for DNS and “local files,” we would probably have something similar to the following for the “hosts” entry:

hosts: files dns

After adding support for NIS, we should remove the “dns” service from the switch file and only use “nis,” as shown in the entry below:

hosts: nis [NOTFOUND=return] files