Managing NFS and NIS, 2nd Edition - Mike Eisler [32]
/etc/group
Append
hosts.byname
hosts
Hostname
/etc/hosts
Replace
hosts.byaddr
IP address
/etc/hosts
Replace
ipnodes.byname
ipnodes
Hostname
/etc/inet/ipnodes
None; only integrated if IPv6 enabled
ipnodes.byaddr
IP address
/etc/inet/ipnodes
None; only integrated if IPv6 enabled
mail.aliases
aliases
Alias name
/etc/aliases
Append
mail.byaddr
Expanded alias
/etc/aliases
Append
netgroup.byhost
Hostname
/etc/netgroup
Replace
netgroup.byuser
Username
/etc/netgroup
Replace
netid.byname
Username
UID & GID info
Replace
netmasks.byaddr
IP address
/etc/netmasks
Replace
networks.byname
Network name
/etc/networks
Replace
networks.byaddr
IP address
/etc/networks
Replace
passwd.byname
passwd
Username
/etc/passwd
/etc/shadow
Append
passwd.byuid
User ID
/etc/passwd
/etc/shadow
Append
publickey.byname
Principal name
/etc/publickey
Replace
protocols.bynumber
protocols
Port number
/etc/protocols
Replace
protocols.byname
Protocol name
/etc/protocols
Replace
rpc.bynumber
RPC number
/etc/rpc
Replace
services.byname
services
Service name
/etc/services
Replace
ypservers
Hostname
NIS server names
Replace
It's now time to face up to some distortions we've been making for the sake of simplicity. We've assumed that there's a one-to-one correspondence between files and maps. In fact, there are usually several maps for each file. A map really corresponds to a particular way of accessing a file: for example, the passwd.byname map looks up data in the password database by username. There's also a passwd.byuid that looks up users according to their user ID number. There could be (but there aren't) additional maps that looked up users on the basis of their group ID number, home directory, or even their choice of login shell. To make things a bit easier, the most commonly used maps have "nicknames," which correspond directly to the name of the original file: for example, the nickname for passwd.byname is simply passwd. Using nicknames as if they were map names rarely causes problems — but it's important to realize that there is a distinction. It's also important to realize that nicknames are recognized by only two NIS utilities: ypmatch and ypcat.
Another distortion: this is the first time we've seen the netid.byname map. On the master NIS server, this map is not based on any single source file, but instead is derived from information in the group, password, and hosts files, via /var/yp/Makefile. It contains one entry for each user in the password file. The data associated with the username is a list of every group to which the user belongs. The netid is used to determine group memberships quickly when a user logs in. Instead of reading the entire group map, searching for the user's name, the login process performs a single map lookup on the netid map. You usually don't have to worry about this map — it will be built for you as needed — but you should be aware that it exists. If NIS is not running, and if an NIS client has an /etc/netid file, then the information will be read from /etc/netid.
Working with the maps
Earlier, we introduced the concept of replaced files and appended files. Now, we'll discuss how to work with these files. First, let's review: these are important concepts, so repetition is helpful. If a map replaces the local file, the file is ignored once NIS is running. Aside from making sure that misplaced optimism doesn't lead you to delete the files that were distributed with your system, there's nothing interesting that you can do with these replaced files. We won't have anything further to say about them.
Conversely, local files that are appended to by NIS maps are always consulted first, even if NIS is running. The password file is a good example of a file augmented by NIS. You may want to give some users access to one or two machines, and not include them in the NIS password map. The solution to this problem is to put these users into the local passwd file, but not into the master passwd file on the