UNIX System Administration Handbook - Evi Nemeth [310]
In the traditional NIS implementation, you must place at least one NIS server on every physical network. Clients use IP broadcasting to locate servers, and broadcast packets are not forwarded by routers and gateways. The ypset command can be used to point a client at a particular server; however, at the first hint of trouble, the client will attempt to locate a new server by using broadcasting. Unless there is a server on the client’s network, this sequence of events may cause the client to hang.
Solaris and Red Hat Linux both let you reliably circumvent the traditional broadcast method of locating NIS servers. See page 529 for instructions.
Netgroups
NIS introduced a popular abstraction known as netgroups. Netgroups name sets of users, machines, and nets for easy reference in other system files. They are defined in /etc/netgroup and are also shared as an NIS map.
The format of a netgroup entry is
groupname list-of-members
Members are separated by whitespace. A member is either a netgroup name or a triplet of the form
(hostname, username, nisdomainname)
Any empty field in a triplet is a wild card; thus the entry (boulder,,) refers to all users in all domains on the host boulder (or to the host boulder itself, depending on the context in which the netgroup is used). A dash in a field indicates negation, so the entry (boulder,-,) refers to the machine boulder and no users. Netgroup definitions can nest.
Here’s a simple example of an /etc/netgroup file:
bobcats (snake,,) (headrest,,)
servers (anchor,,) (moet,,) (piper,,) (kirk,,)
anchorclients (xx,,) (watneys,,) (molson,,)
beers (anchor,,) (anchor-gateway,,) anchorclients
allhosts beers bobcats servers
These netgroups are all defined in terms of hosts; that’s typical for real-world use.
See Chapter 17 for more information about NFS.
Netgroups can be used in several system files that define permissions. The most common application these days is for configuring NFS exports. Netgroups can be mentioned in the /etc/exports file or in share commands (under Solaris) to specify groups of hosts that are allowed to mount each filesystem. This feature is very handy when you are exporting to a lot of hosts, particularly on systems that require fully qualified domain names and that limit lines in the exports file to 1,024 characters.
Netgroups are a nice idea. They simplify system files, making them more understandable. They also add a layer of indirection that permits the status of a user or machine to be changed in one file rather than fifteen.
Prioritizing sources of administrative information
Most systems allow configuration information to be distributed in several ways. Every system understands flat files; most also understand NIS and know how to use DNS to look up hostnames and Internet addresses. Since there may be several potential sources for a given piece of information, vendors usually provide a way for you to specify sources that are to be checked and the order in which the checks are made.
In the original NIS implementation, some configuration files (the /etc/passwd and /etc/group files in particular) had to be configured to “invite in” the contents of the corresponding NIS maps. The invitation was extended by including special incantations in the files themselves. A lone “+” at the beginning of a line would include the entire NIS map, “+@netgroup” would include only entries relevant to a given netgroup, and “+name” would include a single entry.
This approach was never very well liked, and in most systems it has been superseded by a central config file, /etc/nsswitch.conf, that allows an explicit search path to be specified for each type of administrative information.