Managing NFS and NIS, 2nd Edition - Mike Eisler [37]
NIS domains
"Domain" is another term that we have used loosely; now we'll define domains more precisely. Groups of hosts that use the same set of maps form an NIS domain. All of the machines in an NIS domain will share the same password, hosts, and group file information. Technically, the maps themselves are grouped together to form a domain, and hosts join one or more of these NIS domains. For all practical purposes, though, an NIS domain includes both a set of maps and the machines using information in those map files.
NIS domains define spheres of system management. A domain is a name applied to a group of NIS maps. The hosts that need to look up information in the maps bind themselves to the domain, which involves finding an NIS server that has the maps comprising the domain. It's easy to refer to the hosts that share a set of maps and the set of maps themselves interchangeably as a domain. The important point is that NIS domains are not just defined as a group of hosts; NIS domains are defined around a set of maps and the hosts that use these map files. Think of setting up NIS domains as building a set of database definitions. You need to define both the contents of the database and the users or hosts that can access the data in it. When defining NIS domains, you must decide if the data in the NIS maps applies to all hosts in the domain. If not, you may need to define multiple domains. This is equivalent to deciding that you really need two or more groups of databases to meet the requirements of different groups of users and hosts.
As we've seen, the default domain name for a host is set using the domainname command:
nisclient# domainname nesales
This usually appears in the boot scripts as:
/usr/bin/domainname `cat /etc/defaultdomain`
Only the superuser can set or change the default domain. Without an argument, domainname prints the currently set domain name. Library calls that use NIS always request maps from the default domain, so setting the domain name must be the first step in NIS startup. It is possible for an application to request map information from more than one domain, but assume for now that all requests refer to maps in the current default domain.
Despite the long introduction, a domain is implemented as nothing more than a subdirectory of the top-level NIS directory, /var/yp. Nothing special is required to create a new domain — you simply assign it a name and then put maps into it using the server initialization procedures described later. The map files for a domain are placed in its subdirectory:
/var/yp/domainname/mapname
You can create multiple domains by repeating the initialization using different NIS domain names. Each new domain initialization creates a new subdirectory in the NIS map directory /var/yp. An NIS server provides service for every domain represented by a subdirectory in /var/yp. If multiple subdirectories exist, the NIS server answers binding requests for all of them. You do not have to tell NIS which domains to serve explicitly — it figures this out by looking at the structure of its map directory.
It's possible to treat NIS as another administrative tool. However, it's more flexible than a simple configuration file management system. NIS resembles a database management system with multiple tables. As long as the NIS server can locate map information with well-known file naming and key lookup conventions, the contents of the map files are immaterial to the server. A relational database system such as Oracle provides the framework of schemas and views, but it doesn't care what the schemas look like or what data is in the tables. Similarly, the NIS system provides a framework for locating information