Solaris Naming Services Architecture

• By Tom Bialaski and Michael Haines
• Dec 6, 2001
• Sample Chapter is provided courtesy of Prentice Hall

This chapter is from the book
Solaris and LDAP Naming Services: Deploying LDAP in the Enterprise

NIS Maps

NIS uses a flat namespace where a series of maps reside. Each NIS domain contains its own set of maps. There is no relationship between maps or between NIS domains. The maps contain a pair of entries: the first is the keyword and the second is the value retrieved. TABLE 2-1 and TABLE 2-2 show examples of two different NIS maps.

TABLE 2-1 hosts.byname

TABLE 2-2 hosts.byaddr

In the preceding examples, the two maps contain the same information, but in different order. This ordering is necessary so a search can be performed both on a host name and an IP address. So that the two maps do not get out of sync, they are automatically created together whenever the map data is updated.

Creating NIS Maps

NIS maps are converted from text files to a binary dbm file by the makedbm command as shown in FIGURE 2-3.

FIGURE 2-3 Creation of NIS Maps

In FIGURE 2-3 the source, or master, for the NIS maps is contained in text files shown on the left. The best practice is to create a copy of one of these files and only edit the copy. These files should be stored in a secure area and backed up frequently.

Once the source files have been created, the makedbm command is used to generate the new maps. To make things easier to administer a default, Makefile, is provided to perform the makedbm operation for the standard NIS maps.

Although it is possible to have NIS maps owned by different masters within a domain, joint ownership is not advisable. In this scenario, an NIS server could act as a master to some maps and as a slave to others. Keeping track of which server is master to which maps could be an administrative nightmare, so it is best to make one server master of all the maps.