Netgroups
NIS netgroups are groups (sets) of users or machines that you define for your administrative purposes. For example, you can create netgroups that do the following
Define a set of users who can access a specific machine
Define a set of NFS client machines to be given some specific file system access
Define a set of users who are to have administrator privileges on all the machines in a particular NIS domain
Each netgroup is given a netgroup name. Netgroups do not directly set permissions or access rights. Instead, the netgroup names are used by other NIS maps in places where a user name or machine name would normally be used. For example, suppose you created a netgroup of network administrators called netadmins. To grant all members of the netadmins group access to a given machine, you need only add a netadmin entry to that machine's /etc/passwd file. Netgroup names can also be added to the /etc/netgroup file and propagated to the NIS netgroup map. See netgroup(4) for more detailed information on using netgroups.
On a network using NIS, the netgroup input file on the master NIS server is used for generating three maps: netgroup, netgroup.byuser, and netgroup.byhost. The netgroup map contains the basic information in the netgroup input file. The two other NIS maps contain information in a format that speeds lookups of netgroup information, given the machine or user.
Entries in the netgroup input file are in the format: name ID, where name is the name you give to a netgroup, and ID identifies a machine or user who belongs to the netgroup. You can specify as many IDs (members) to a netgroup as you want, separated by commas. For example, to create a netgroup with three members, the netgroup input file entry would be in the format: name ID, ID, ID. The member IDs in a netgroup input file entry are in the following format.
([-|machine], [-|user], [domain]) |
Where machine is a machine name, user is a user ID, and domain is the machine or user's NIS domain. The domain element is optional and should only be used to identify machines or users in some other NIS domain. The machine and user element of each member's entry are required, but a dash (-) is used to denote a null. There is no necessary relationship between the machine and user elements in an entry.
The following are two sample netgroup input file entries, each of which create a netgroup named admins composed of the users hauri and juanita who is in the remote domain sales and the machines altair and sirius.
admins (altair, hauri), (sirius,juanita,sales) |
admins (altair,-), (sirius,-), (-,hauri), (-,juanita,sales) |
Various programs use the netgroup NIS maps for permission checking during login, remote mount, remote login, and remote shell creation. These programs include mountd, login, rlogin, and rsh. The login command consults the netgroup maps for user classifications if it encounters netgroup names in the passwd database. The mountd daemon consults the netgroup maps for machine classifications if it encounters netgroup names in the /etc/dfs/dfstab file. rlogin and rsh In fact, any program that uses the ruserok interface consults the netgroup maps for both machine and user classifications if they encounter netgroup names in the /etc/hosts.equiv or .rhosts files.
If you add a new NIS user or machine to your network, be sure to add them to appropriate netgroups in the netgroup input file. Then use the make and yppush commands to create the netgroup maps and push them to all of your NIS servers. See netgroup(4) for detailed information on using netgroups and netgroup input file syntax.
Working With NIS Maps
Obtaining Map Information
Users can obtain information from and about the maps at any time by using the ypcat, ypwhich, and ypmatch commands. In the examples that follow, mapname refers both to the official name of a map and to its nickname, if any.
To list all the values in a map, type the following.
% ypcat mapname
To list both the keys and the values (if any) in a map, type the following.
% ypcat -k mapname
To list all the map nicknames, type any of the following commands.
%ypcat --x
% ypwhich --x
% ypmatch --x
To list all the available maps and their master(s), type the following.
% ypwhich --m
To list the master server for a particular map, type the following.
% ypwhich -m mapname
To match a key with an entry in a map, type the following.
% ypmatch key mapname
If the item you are looking for is not a key in a map, type the following.
% ypcat mapname | grep item
where item is the information for which you are searching. To obtain information about other domains, use the -d domainname options of these commands.
If the machine requesting information for a domain other than its default does not have a binding for the requested domain, ypbindconsults the /var/yp/binding/domainname/ypservers file for a list of servers for that domain. If this file does not exist it issues an RPC broadcast for a server. In this case, there must be a server for the requested domain on the same subnet as the requesting machine.
Changing a Map's Master Server
To change the master server for a selected map, you first have to build the map on the new NIS master. Since the old master server name occurs as a key-value pair in the existing map (this pair is inserted automatically by makedbm), copying the map to the new master or transferring a copy to the new master with ypxfr is insufficient. You have to reassociate the key with the new master server name. If the map has an ASCII source file, you should copy this file to the new master.
How to Change a Map's Master Server
Become superuser.
Log in to the new master as superuser and type the following.
newmaster# cd /var/yp
The Makefile must have an entry for the new map before you specify the map to make. If this is not the case, edit the Makefile now, using a map called sites.byname.
To update or remake the map, type the following.
newmaster# make sites.byname
If the old master remains an NIS server, remote log in (rlogin) to the old master and edit Makefile. Make sure you comment out the section of the Makefile that made sites.byname so that it is no longer made there.
If sites.byname only exists as an ndbm file, remake it on the new master by disassembling a copy from any NIS server, then running the disassembled version through makedbm.
newmaster# cd /var/yp
newmaster# ypcat sites.byname | makedbm -domain/sites.byname
After making the map on the new master, you must send a copy of the new map to the other slave servers. Do not use yppush, because the other slaves will try to get new copies from the old master, rather than the new one. A typical method for circumventing this is to transfer a copy of the map from the new master back to the old master. To do this, become superuser on the old master server and type the following.
oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster sites.byname
Now it is safe to run yppush. Any remaining slave servers still believe that the old master is the current master and will attempt to get the current version of the map from the old master. When clients do so, they will get the new map, which names the new master as the current master.
If this method fails, you can log in as root on each NIS server and execute the ypxfr command shown above.
Modifying Configuration Files
NIS intelligently parses the setup files. Although this makes NIS administration easier, it does make the behavior of NIS more sensitive to changes in the setup and configuration files.
Use the procedures in this section when modifying any of the following.
Adding or deleting /etc/resolv.conf to allow or deny DNS forwarding
Adding or deleting $PWDIR/security/passwd.adjunct to allow or deny C2 security. ($PWDIR is defined in /var/yp/Makefile.)