This chapter explains how to maintain NIS after it is in service. It contains procedures for adding new users to NIS, changing passwords, using netgroups, creating a nonstandard NIS map, modifying existing maps, new maps, adding an NIS slave server, changing the NIS master server, and increasing the security of ypset(1M).
This chapter contains these sections:
To add a new user to a system that is an NIS client, perform these steps:
On the NIS master server, add a password entry for the new user to the NIS password file (/etc/passwd by default). (See passwd(4), the Personal System Administration Guide, or the IRIX Advanced Site and Server Administration Guide for more information.)
On the NIS master server, update the NIS passwd map on that system by entering:
# cd /var/yp # ./ypmake passwd |
If this user is to be a member of any netgroups, modify /etc/netgroups on the NIS master server (see “Using Netgroups” in this chapter).
On the new user's system, modify /etc/passwd in one of these ways:
Add the same password entry as you added in instruction 1 in this section. Duplicating the entry enables the user to log in when the network is down.
Add this password entry:
+userid |
userid is the login name of the new user. When this type of entry is used, all /etc/password information for this user is supplied by NIS.
Use the Users tool of System Manager to add the new user. Choose NIS rather than Local for each item. All /etc/password information for this user is supplied by NIS.
Add this password entry:
+ |
When this type of entry is used, all /etc/password information for all users is supplied by NIS. Every user in the NIS password database can log in to this system, assuming that the home directory exists.
Make a home directory for the new user on the user's system:
# cd parentdir # mkdir userid # chown uid userid # chgrp group userid |
The variables are:
| parentdir | The parent directory of the home directory you are creating. | |
| userid | The login name of the user (the first field in the password entry). | |
| uid | The unique user ID number for this user (the third field in the password entry). userid can be used instead of uid if the local /etc/password entry duplicates the NIS password entry or if NIS maps have been propagated to this system (it takes about 15 minutes after instruction 2 for updates to propagate). | |
| group | The group number for this user (the fourth field in the password entry). |
Finish adding the new user by setting up the user's login environment (create .login and .cshrc files, for example), adding him or her to groups in /etc/group, and doing other setup tasks that are usually done at your site.
Have the user add a password to his or her account using yppasswd(1):
% yppasswd |
yppasswd prompts the user to enter the new password twice.
If you added a complete password entry to /etc/passwd on the user's system (the first option in instruction 4), have the user add his or her password to the local /etc/passwd using passwd(1):
% passwd |
passwd prompts for the password twice.
In general, all NIS accounts should be password protected. This reduces the risk of malicious or accidental data corruption. When you change your password with the passwd command, you change the entry explicitly given in your own local /etc/passwd file. To change your NIS password, use the yppasswd command.
To change the NIS password for the user tim, enter:
% yppasswd tim Changing NIS password for tim on master_name Old password: <response not echoed> |
Enter your old NIS password (if the account is not password protected, press the enter key, <Enter>):
New password: <response not echoed> |
Enter your new NIS password:
Retype new password: <response not echoed> |
Reenter the new password:
NIS passwd changed on master_name |
Your NIS password change has been logged on the master server and will be updated soon. Note that it takes a little while for the change to propagate throughout the domain.
If your local password is not given explicitly but rather is pulled in from NIS with a plus (+) entry, then the passwd command prints the error message:
Not in passwd file |
In this case, you must use yppasswd to change your password.
To enable the yppasswd service, the system administrator must start up the daemon rpc.passwd(1M) server on the system serving as the master server for the NIS password file in your domain.
The /etc/netgroup file on the NIS master server contains a list of network-wide groups of systems and users. These groups are used for administrative purposes. For example, to define a set of users that should be given access to a specific system, you can create a netgroup for those users.
The daemons login(1), mountd(1M), rlogind(1M), and rshd(1M) use netgroups for permission checking. login consults them for user classifications if it encounters netgroup names in /etc/passwd. mountd consults them for system classifications if it encounters netgroup names in /etc/exports. rlogind and rshd consult the netgroup map for both system and user classifications if they encounter netgroup names in hosts.equiv(4) or .rhosts(4).
The NIS master server uses /etc/netgroup to generate three NIS maps: netgroup, netgroup.byuser, and netgroup.byhost. The NIS map netgroup contains the basic information in /etc/netgroup. The two other NIS maps contain a more specific form of the information to speed the lookup of netgroups given the system or user.
Here is a sample /etc/netgroup file. See netgroup(4) for a description of file format and definition of lines and fields.
# Engineering: Everyone but eric has a machine; # he has no machine. # The machine 'testing' is used by all of hardware. # engineering hardware software hardware (mercury,alan,sgi) (venus,beth,sgi) (testing,-,sgi) software (earth,chris,sgi) (mars,deborah,sgi) (-,eric,sgi) # # Marketing: Time-sharing on jupiter # marketing (jupiter,fran,sgi) (jupiter,greg,sgi) # # Others # allusers (-,,sgi) allhosts (,-,sgi) |
Table 5-1 shows the users in each group.
Group | Users |
|---|---|
hardware | alan, beth |
software | chris, deborah, eric |
engineering | alan, beth, chris, deborah, eric |
marketing | fran, greg |
allusers | (every user in the NIS map passwd) |
allhosts | (no users) |
Table 5-2 shows how the systems are classified.
Group | Hosts |
|---|---|
hardware | mercury, venus, testing |
software | earth, mars |
engineering | mercury, venus, earth, mars, testing |
marketing | jupiter |
allusers | (no systems) |
allhosts | (all systems in the NIS map hosts) |
For more details, see these manual pages: yppasswd(1), hosts.equiv(4), export(4), passwd(4), group(4), netgroup(4), and rpc.passwd(1M).
You can use ypinit(1M) and /var/yp/local.make.script (see ypmake(1M)) to do almost everything necessary to create and modify a map, unless you add nonstandard maps to the database or change the set of NIS slave servers after the system is already running. Whether you use /var/yp/local.make.script or some other procedure, the goal is the same: a new pair of well-formed dbm files in the domain directory on the NIS master server.
You can create new maps in two ways: using an existing ASCII file as input or using standard keyboard input. The next two sections demonstrate how to create a simple, nonstandard NIS map called yourmap using each method. yourmap consists of the keys al, bl, cl, and so on (l for left); and one set of values, ar, br, cr, and so on (r for right).
Assume the ASCII file /etc/yourmap has been created with an editor or shell script, and that the map from /etc/yourmap is part of the database for the shapes domain. To create the NIS map for this file, enter these commands:
# cd /var/yp # makedbm /etc/yourmap shapes/yourmap |
This command sequence creates a map called yourmap in the directory /var/yp/shapes.
When no original ASCII file exists, you can create the NIS map described in the previous example from the keyboard with these commands:
# cd /var/yp # makedbm - shapes/yourmap |
Enter these lines:
al ar bl br cl cr <Ctrl-D> |
The makedbm(1M) – switch is used to indicate that input is coming directly from the keyboard. The result of your entries is the same as the previous example: a map called yourmap in the directory /var/yp/shapes.
To change any NIS map, you must change the databases on the master server for the domain. The method you use to modify the map depends on whether you are changing a standard or nonstandard map.
A standard NIS map is any map that has an ASCII file and is included in the /var/yp/make.script file. The procedure for modifying a standard NIS map consists of editing the ASCII file for the map and updating the map with ypmake on the master server. For example, to modify the password database map, edit the ASCII file for the map and run ypmake on the master server. To add the user tom to the password database, perform these steps:
Edit the ASCII file:
# vi /etc/passwd.nis |
Add this line to the password file:
tom::2349:20:Tom Cat:/usr/people/tom:/bin/csh |
Update the password map:
# /var/yp/ypmake passwd |
By default, the ypmake program updates the map on the master server based on information contained in the make script (/var/yp/make.script and /var/yp/local.make.script). It also propagates the updated map to all slave servers listed in the ypservers database map.
Nonstandard NIS maps are databases that are specific to the application of a particular vendor site but are not part of the NFS release. You can manually modify nonstandard databases. You can also manually change databases that are rarely expected to change and databases for which no ASCII form exists.
The general procedure is to use makedbm with a switch to disassemble the map. The disassembled map is in a form you can modify with standard tools such as awk(1), sed(1), or vi(1). You then build a new map from the changed version using makedbm.
Use this procedure to modify a nonstandard database:
Disassemble the map, as shown in this sample command:
# cd /var/yp # makedbm -u shapes/mymap > /var/tmp/mymap.txt |
Edit the text file (/var/tmp/mymap.txt, in this example) with any text editor.
Build the new map, as shown in this sample command:
# makedbm /var/tmp/mymap.txt shapes/mymap |
Remove the temporary ASCII file, as shown in this sample:
# rm /var/tmp/mymap.txt |
This procedure modifies and updates nonstandard maps but does not propagate the map to slave servers.
Preparing for propagating a nonstandard NIS map consists of setting up its dbm files in the domain directory on each NIS server (the transfer mechanism is described in the next section). The files must be set up correctly on the master and each slave server in the domain.
On the NIS master server, create a new file called /var/yp/local.make.script so you can conveniently rebuild the map. This example shows a copy of /var/yp/local.make.script to create and push the maps auto.indirect, auto.direct, auto.master, and auto.home from the files /etc/auto.indirect, /etc/auto.direct, /etc/auto.master, and /etc/auto.home.
#
# auto.indirect indirect automount YP map.
# auto.direct direct automount YP map.
# auto.master main auto.master automount map
# auto.home homedir map for automounter
INDIRECT=auto.indirect
DIRECT=auto.direct
HOME=auto.home
localall: all $(INDIRECT) $(DIRECT) $(HOME) auto.master
auto.master: auto.master.time
$(DIRECT): direct.time
$(HOME): home.time
$(INDIRECT): indirect.time
indirect.time: $(DIR)/$(INDIRECT)
-@if [ -f $(DIR)/$(INDIRECT) ]; then \
sed -e '/^#/d' $(DIR)/$(INDIRECT) | \
$(MAKEDBM) - $(YPDBDIR)/$(INDIRECT); \
touch indirect.time; \
echo "Updated $(INDIRECT)"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) $(INDIRECT); \
echo "pushed $(INDIRECT)"; \
else \
: ; \
fi \
else \
echo "couldn't find $(DIR)/$(INDIRECT)";\
fi
direct.time: $(DIR)/$(DIRECT)
-@if [ -f $(DIR)/$(DIRECT) ]; then \
sed -e '/^#/d' $(DIR)/$(DIRECT) | \
$(MAKEDBM) - $(YPDBDIR)/$(DIRECT); \
touch indirect.time; \
echo "Updated $(DIRECT)"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) $(DIRECT); \
echo "pushed $(DIRECT)"; \
else \
: ; \
fi \
else \
echo "couldn't find $(DIR)/$(DIRECT)";\
fi
auto.master.time: $(DIR)/auto.master
-@if [ -f $(DIR)/auto.master ]; then \
sed -e '/^#/d' $(DIR)/auto.master | \
$(MAKEDBM) - $(YPDBDIR)/auto.master; \
touch auto.master.time; \
echo "Updated auto.master"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) auto.master; \
echo "pushed auto.master"; \
else \
: ; \
fi \
else \
echo "couldn't find $(DIR)/auto.master";\
fi
home.time: $(DIR)/$(HOME)
-@if [ -f $(DIR)/$(HOME) ]; then \
sed -e '/^#/d' $(DIR)/$(HOME) | \
$(MAKEDBM) - $(YPDBDIR)/$(HOME); \
touch home.time; \
echo "Updated $(HOME)"; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) $(HOME); \
echo "pushed $(HOME)"; \
else \
: ; \
fi \
else \
echo "couldn't find $(DIR)/$(HOME)";\
fi
|
Typically, /var/yp/local.make.script filters each readable ASCII file for which a map is to be built (such as /etc/auto.master) through awk, sed, and/or grep(1) to make two databases suitable for input to makedbm. For example, the databases might be stored as /var/yp/circles/auto.master.pag and /var/yp/circles/auto.master.dir.
To create a customized make script, /var/yp/local.make.script, use the existing /var/yp/make.script as a source of programming examples. Make use of mechanisms already in place in /var/yp/make.script when deciding how to create dependencies that make(1) recognizes; specifically, using .time files allows you to see when the script was last run for the map.
If new maps are to propagate properly on slave servers, ypxfr(1M) shell scripts must contain the appropriate entries. To get an initial copy of the map, run ypxfr manually on each slave server. A map must be available on all servers before clients begin to access it. If a map is unavailable on some NIS servers, client programs may behave unpredictably.
During slave server setup, ypinit calls ypxfr to transfer maps from the master to the new slave server. Once the slave server is operating, maps can be transferred in two ways: by running ypxfr periodically from crontab(1M) or by executing ypmake, ypxfr, or yppush(1M) from a command line.
The standard root crontab, /var/spool/cron/crontabs/root, has entries to run ypxfr periodically from shell scripts at a suggested rate for the standard maps in your NIS database. The crontab entries test whether the system is configured as a slave server; if the test succeeds, the ypxfr scripts are executed. If your NIS database has only standard maps, the default entries in root's crontab ensures that the maps are kept reasonably up-to-date. The shell scripts, by default, are run on each NIS slave server in the domain to ensure database consistency throughout the domain. The cron(1M) shell script entries for ypxfr look similar to the following example. Note that each entry in the crontab file must be seen as one line. For documentation purposes, line wraps are indicated with a backslash (\).
# If this machine is running NIS and it's a slave server, the following
# commands keep the NIS databases up-to-date.
#
13 9 * * * if /etc/chkconfig yp; then find \
/var/yp -type f -name 'xfr.*' -mtime +1 -exec rm -f '{}' ';' ; fi
15 * * * * if test -x /var/yp/ypxfr_1ph;\
then /var/yp/ypxfr_1ph; fi
17 9,15 * * * if test -x /var/yp/ypxfr_2pd;\
then /var/yp/ypxfr_2pd; fi
19 9 * * * if test -x /var/yp/ypxfr_1pd;\
then /var/yp/ypxfr_1pd; fi
|
The ypxfr shell scripts reside in /var/yp. Three standard scripts are included with the NFS release: ypxfr_1phr, ypxfr_1pd, and ypxfr_2pd. These scripts transfer specified maps once per hour, once per day, and twice per day, respectively. If the rates of change are inappropriate for your environment, you can modify the root crontab to suit your needs.
Also, you should alter the crontab entries so that the exact time of the ypxfr shell executions varies from one server to another to prevent the transfers from slowing down the master server, the network, or both.
Typically, changes to the ypxfr shell scripts are required in these cases:
To reflect required map update schedules for your site
To add nonstandard maps
If you want to transfer a map from a server other than the master (use ypxfr's –h option)
For more information on how to use crontab, see crontab(1).
The next three sections describe three methods of manually propagating NIS maps.
NIS maps on the master server can be manually propagated using the ypmake command. This command looks at the /var/yp/make.script and/or /var/yp/local.make.script to determine which maps to make. The make script calls makedbm, which updates the maps and calls yppush. yppush reads the ypservers map to determine which slave servers to contact; then, it proceeds to contact ypserv on the selected slave servers and requests ypxfr service. The slave server can now transfer the maps with ypxfr.
Use ypmake to update and propagate maps throughout your domain when you want the change to take place immediately and don't want to wait for cron. These are some usage examples for ypmake:
To update all out-of-date maps, enter:
# /var/yp/ypmake |
To update and propagate an out-of-date hosts.byname and hosts.byaddr map, enter:
# /var/yp/ypmake hosts |
To force the creation and propagation of a new passwd.byname and passwd.byuid map, out-of-date or not, enter:
# /var/yp/ypmake -u passwd |
To rebuild all of the maps, but not push them to other servers, enter:
# /var/yp/ypmake -u NOPUSH=1 |
The ypmake program is also automatically called for in root's crontab, /var/spool/cron/crontabs/root. The entry in crontab tests whether the system is configured to run NIS and whether it is configured as the master. If the test succeeds, cron periodically executes the ypmake command to update and propagate maps to the appropriate slave servers. The crontab entry looks similar to the following. Note that each entry in the crontab file must be seen as one line. For documentation purposes, line wraps are indicated with a backslash (\).
# If this machine is a NIS master, ypmake will rotate the # log file and ensure that the databases are pushed out with # some regularity. # 1,16,31,46 * * * * if /etc/chkconfig \ ypmaster && /etc/chkconfig yp && \ test -x /var/yp/ypmake; then \ /var/yp/ypmake; fi |
You can run ypxfr as a command on slave servers to transfer a specified map from the master or other stable server to the requesting slave server. Typically, you run ypxfr only in exceptional situations. For example, ypxfr is used when setting up a temporary NIS server to create a test environment, or when an NIS slave server has been out of service and must quickly be made consistent with the other servers.
ypxfr, as a command, has options that force map transfer and specify alternate domains and servers from which to obtain the map. Some examples of ypxfr command usage are:
To transfer the hosts.byaddr map from the master server for the map, enter:
# /var/yp/ypxfr hosts |
To force the transfer of the passwd.byname map from the slave server purple within the domain colors, enter:
# /var/yp/ypxfr -f -h purple -d colors |
While yppush is usually called by ypmake, it can also be run manually. You must run yppush on the NIS master server. The syntax for using yppush is:
To force a copy of the map myworld with verbose messages, enter:
# yppush -v myworld |
To force a copy of the map yourmap in the domain yourworld, enter:
# yppush -d yourworld yourmap |
Use yppush to force a copy of an updated version of a specified map from the master server to the slave servers. It can be used to move an infrequently changed, nonstandard map from the master server to slave servers.
In any of the cases mentioned above, you can capture ypxfr's transfer attempts and the results in a log file. If /var/yp/ypxfr.log exists, ypxfr appends results to it. No attempt is made to limit the log file; you are in charge of that. To turn off logging, remove the log file. In addition, the file /var/yp/ypmake.log records ypmake transactions. This file can also be useful for troubleshooting propagation problems.
To add a new NIS slave server, you must first modify an NIS server map on the NIS master server. If the new server has not been an NIS slave server before, you must add the new server's name to the map ypservers in the default domain.
This procedure explains how to add a new server to an NIS configuration:
On the master server, change to the /var/yp directory:
# cd /var/yp |
Create a new hosts map, if needed.
The new server's host name and address must be in the hosts map. If the NIS slave server you are adding is not included in the hosts map, edit /etc/hosts and save your changes. Then, create a new hosts map:
# vi /etc/hosts |
Enter and save your changes.
# ./ypmake hosts |
Edit the /usr/etc/yp/ypservers file and add the new server's host name:
# vi ypservers |
Propagate the map with ypmake:
# ./ypmake ypservers |
Transfer the database from the master server.
Remotely log in to the new NIS slave server. Use ypinit to transfer the database from the NIS master server to the new slave server:
# /var/yp/ypinit -s mastername |
Perform the steps described in “Building the Duplicate Maps” in Chapter 4. The new slave server is ready for service after you build the duplicate maps.
To switch the master server to a different system, you must rebuild all maps to reflect the name of the new master server and distribute the new maps to all slave servers.
To change the master server, perform these steps:
Set up the system that is to be the new master server as if it is to be a slave server. See “Setting Up NIS Slave Servers” in Chapter 4 and follow the directions in the sections “Setting the Slave Server's Domain Name,” “Binding to Another NIS Server,” and “Building the Duplicate Maps.”
Copy the map source files from the old master server to the new master server. The source files are listed in Table 3-1.
Rebuild all of the maps on the new master server, but don't push them to other servers:
newmaster# /var/yp/ypmake -u NOPUSH=1 |
Use ypxfr on the old master server to transfer each of the new maps from the new master server to the old master server. Give this command for each of the maps listed in Table 2-2:
oldmaster# ypxfr -h newmaster -f mapname |
newmaster is the host name of the new master server and mapname is a map name from Table 2-2. ypxfr is used for this step rather than yppush because of a security feature of yppush. When a map is pushed to a server, that server consults its own copy of the map to verify that the map is coming from the master server. Since the old master server still believes that it is the master server, it won't accept maps from the new master server.
On the old master server, transfer copies of the new maps to all slave servers by giving this command for each of the maps listed in Table 2-2:
oldmaster# yppush mapname |
Maps are pushed from the old master server to the slave servers because the slave servers' maps still contain the old master server. The new maps contain the name of the new master server.
The ypset tool allows the root user on NIS clients to change the binding association for the client. By default, the file /etc/config/ypbind.options contains the –ypsetme option that enables ypset. Normally, the –ypsetme option should be present when creating an NIS master since, if is not present, ypmake displays error messages when building an NIS master. In secure installation sites, however, the –ypsetme option should be removed.
The ypset tool was designed for debugging and not for casual use. As with any network tool that bases security on IP address checking, ypset can compromise security on networks where packets may be introduced to the network by nontrusted individuals.