Managing NFS and NIS, 2nd Edition - Mike Eisler [47]
&& echo ` rpc.yppasswdd\c`
fi
...
fi
The host making a password map change locates the master server by asking for the master of the NIS passwd map, and the yppasswdd daemon acts as a gateway between the user's host and a passwd-like utility on the master server. The location of the master server's password file and options to build a new map after each update are given as command-line arguments to yppasswdd, as shown in the previous example.
The -D argument specifies the name of the master server's source for the password map; it may be the default /etc/passwd or it may point to an alternative password file.[1] The -m option specifies that make is to be performed in the NIS directory on the master server. You can optionally specify arguments after -m that are passed to make. With a default set up, the fragment in ypstart would cause yppasswdd to invoke make as:
# ( cd /var/yp; make )
after each change to the master's password source file. Since it is likely only the password file will have changed, only the password maps get rebuilt and pushed. You can ensure that only the password maps get pushed changing the yppaswdd line in ypstart to:
$YPDIR/rpc.yppasswdd $PWDIR -m passwd \
&& echo ` rpc.yppasswdd\c`
Source code control for map files
With multiple system administrators and a single point of administration, it is possible for conflicting or unexplained changes to NIS maps to wreak havoc with the network. The best way to control modifications to maps and to track the change history of map source files is to put them under a source code control system such as SCCS.
Source code files usually contain the SCCS headers in a comment or in a global string that gets compiled into an executable. Putting SCCS keywords into comments in the /etc/hosts and /etc/aliases files allows you to track the last version and date of edit:
header to be added to file:
# /etc/hosts header
# %M% %I% %H% %T%
# %W%
keywords filled in after getting file from SCCS:
# /etc/hosts header
# hosts 1.32 12/29/90 16:37:52
# @(#)hosts 1.32
Once the headers have been added to the map source files, put them under SCCS administration:
nismaster# cd /etc
nismaster# mkdir SCCS
nismaster# /usr/ccs/bin/sccs admin -ialiases aliases
nismaster# /usr/ccs/bin/sccs admin -ihosts hosts
nismaster# /usr/ccs/bin/sccs get aliases hosts
The copies of the files that are checked out of SCCS control are read-only. Someone making a casual change to a map is forced to go and check it out of SCCS properly before doing so. Using SCCS, each change to a file is documented before the file gets put back under SCCS control. If you always return a file to SCCS before it is converted into an NIS map, the SCCS control file forms an audit trail for configuration changes:
nismaster# cd /etc
nismaster# sccs prs hosts
D 1.31 00/05/22 08:52:35 root 31 30 00001/00001/00117
MRs:
COMMENTS:
added new host for info-center group
D 1.30 00/06/04 07:19:04 root 30 29 00001/00001/00117
MRs:
COMMENTS:
changed bosox-fddi to jetstar-fddi
D 1.29 90/11/08 11:03:47 root 29 28 00011/00011/00107
MRs:
COMMENTS:
commented out the porting lab systems.
If any change to the hosts or aliases file breaks, SCCS can be used to find the exact lines that were changed and the time the change was made (for confirmation that the modification caused the network problems).
The two disadvantages to using SCCS for NIS maps are that all changes must be made as root and that it won't work for the password file. The superuser must perform all file checkouts and modifications, unless the underlying file permissions are changed to make the files writable by nonprivileged users. If all changes are made by root, then the SCCS logs do not contain information about the user making the change. The password file falls outside of SCCS control because its contents will be modified by users changing their passwords, without being able to check the file out of SCCS first. Also, some files, such as /etc/group, have no comment lines, so you cannot use SCCS keywords in them.
Using alternate