The Network Information Service (NIS) environment requires adjustments from time to time. In large or complex networks, the NIS environment may change many times a day. This section discusses how to perform various maintenance tasks.
All the tasks discussed in this section assume that NIS is installed and configured on your network. See "Configuring NIS".
For detailed information on NIS and Network File System (NFS) security, see "Secure NFS".
Both the ypserv and the ypxfrd use the /var/yp/securenets file and, if present, only respond to Internet Protocol (IP) addresses in the range given. This file is read only when the daemons (both ypserv and ypxfrd) start. To get a change in /var/yp/securenets to take effect, you must kill and restart the daemons. The format of the file is:
netmask netaddr e.g. 255.255.0.0 128.30.0.0 255.255.255.0 128.311.10.0
The second line the netmask address is 255.255.255.0 and the network address is 128.311.10.0. This setup will only allow the ypserv daemon to respond to those IP addresses within the subnet 128.311.10.0 range.
Changing the NIS maps to reflect updated system information can be a common occurrence in your daily maintenance tasks. System information, such as a new user account or a changed password, can require constant updating. Whenever you need to modify an NIS map, you should do so on the master server, and then propagate the changes to the slave servers. Modifying maps on slave servers can break the NIS service algorithm, which can result in unreliable map data. The only exception to this rule is when users change their password with the yppasswd command. (See "Changing NIS Passwords" for more information.)
To change an NIS map, use the Web-based System Manager fast path, wsm network, on the master server. Alternatively, you can use one of the following procedures on the master server.
smit mkmapsSpecify the map you changed in the MAPS that are to be built field.
The map is now changed, and the master server has requested that all the slave servers update their maps.
cd /var/yp make mapwhere map specifies the map to be updated, for example hosts or services.
Notes:
- If you have modified several text files and want to confirm that all NIS maps are updated, issue the make command without parameters to automatically evaluate every input file on the NIS master server. If the file has been modified since the latest NIS map for that file was built, the NIS map is automatically rebuilt.
- If the file /var/yp/securenets exists, the server only provides NIS services to hosts within the IP range specified.
Users can change their password using any of three methods. If the user is logged onto the master server, and you use the /etc/passwd file on the master server to build the passwd map, the user can:
All of these methods change the user's entry in the /etc/passwd file. Then, you will have to rebuild the passwd map manually (see "Changing an NIS Map"). If the yppasswdd daemon is running on the master server, users can change their password from any host in the domain by entering the command:
yppasswd
This command changes the user's password in the passwd map itself as well as the /etc/passwd file, and thus requires no intervention by the system administrator. (For more information on the yppasswdd daemon, see "Configuring the NIS Master Server").
If your network configuration grows or changes, you may want to add additional slave servers to support the new configuration. Adding a new slave server involves modifying the ypservers map. The procedure for modifying the ypservers map differs from other maps because no text file is used as input for this map. Instead, the makedbm utility is used to create the modified ypservers maps. To add a new slave server to your network, do the following on the master server:
cd /var/yp
Note: If the file /var/yp/securenets exists, the server only provides NIS services to hosts within the IP range specified.
(makedbm -u domain/ypservers ; echo new_server) | makedbm - tmpserverswhere domain specifies the name of this NIS domain, and new_server specifies the name of the slaver server host that you are adding to the ypservers map. This command lists the contents of the current ypservers map, and appends the name of the new slave server, and then creates a new map called tmpservers.
makedbm -u tmpservers
mv tmpservers.pag domain/ypservers.pag mv tmpservers.dir domain/ypservers.dirwhere domain specifies the name of this NIS domain.
To add a new NIS user, use the Web-based System Manager fast path, wsm user, on the master server. Alternatively, you can use one of the following procedures on the master server.
smit mkuserEnter the new NIS user's name in the User NAME field. This will add an entry to the /etc/passwd file for the new user.
smit mkmapsSpecify passwd in the MAPS that are to be built field.
The new NIS user is now added, and the master server has requested that all the slave servers update their maps.
mel::1295:325:Mel Smith:/u/mel:/bin/ksh
cd /var/yp make passwd
As discussed in "NIS Maps", maps are databases that have a special format. The default, or standard, maps are built out of standard system text files. However, NIS maps are very flexible. You can build into a map any information that has a key and a value. This article discusses in detail an example of how you can build such a map.
This example shows how to create a nonstandard map called udir.nam that lists the home directories of users in this domain. You will use the /etc/passwd file as input file for the udir.nam map. (If you use a different file to create the passwd map, use that file instead of /etc/passwd.) The keys for the map are the user names, and their home directories are the corresponding values. To create this new map, enter the following two commands on the master server:
cd /var/yp awk '{FS=":" ; OFS="\t" ; print $1,$6}' /etc/passwd | \ makedbm - domain/udir.nam
where domain specifies this NIS domain, and ' is the single forward quote. The awk command extracts from the /etc/passwd file the first and sixth fields. Then, it passes this information to the makedbm command that builds the udir.nam map. You can now propagate and use this map just like any other map. For example, enter the command:
ypcat udir.nam
You should see a list of all the home directories specified in the /etc/passwd file.
The above example used the awk command to filter out the unwanted fields from the /etc/passwd file. However, you can use any system utility or programming language you want to create the map input. In fact, you can create the map input manually if you want. For example, to create the udir.nam map, you could have entered the command:
makedbm - domain/udir.nam john /u/john mary /u/mary sam /u/sam <Ctrl^D>
Or, suppose you used your favorite system utility or programming language to create the file temp.input. Then, you could have entered the command:
makedbm - domain/udir.nam < temp.input
Whatever method you use to create the map input file, you will probably want to update the map periodically. To do so, you can add stanzas to the /var/yp/Makefile file so that your nonstandard map can be updated as any other map (see "Changing an NIS Map"). For detailed information on customizing the /var/yp/Makefile, see the "make Command Overview" in AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs.
Note: When you add a new map after the initial set of maps have been pushed to a slave server, you must make the new maps with the NOPUSH option set to 1. For example, use the command:make NOPUSH=1 newmapto make newmap map. If you do not use the NOPUSH option, the make command will hang. (This only applies if the new map does not already exist on the slave server.) Next, use the ypxfr command on each slave server for each new map you created (see "Propagating an NIS Map").
The NIS slave servers must be authorized to copy files remotely (using the rcp remote copy command) from the NIS master server.
To propagate NIS maps from the master server to slave servers, use the Web-based System Manager fast path, wsm network, or use one of the following procedures.
smit ypxfr
and specify a map name in the Name of the MAP to be transferred field. This will retrieve the specified map from the master server.
ypxfr mapname
All of these methods use the yppush command, which uses the ypserver database to generate a list of slave servers in your domain. It then sends a transfer database request to the ypserv daemon on each of the slave servers. The ypserv daemon on the slave server executes a copy of the ypxfr -C command and then passes a summary of the information it needs to identify the database and call back the initiating yppush command.
You may need to propagate some maps more frequently than others. For example, the passwd map can change many times a day and must be propagated more frequently than the protocols or services maps, which may not change for months at a time. Rather than propagate each map manually, you may want to automate the propagation of maps with the cron daemon. To do so, follow the instructions below. (You will need to perform these instructions on each slave server.)
/usr/sbin/ypxfr_1perhour /usr/sbin/ypxfr_2perday /usr/sbin/ypxfr_1perdayFor example, the /usr/sbin/ypxfr_1perhour shell script contains ypxfr commands for several maps that change frequently and should, therefore, be propagated frequently. The other two shell scripts are for maps that change less frequently. Use an editor to modify these shell scripts to meet the needs of your network.
Next, configure the cron daemon to execute these scripts at the appropriate times. The following steps lead you through this process.
crontab -l > cron.tmpThis command records the current crontab settings in the file cron.tmp.
00 * * * * /usr/sbin/ypxfr_1perhour # run every hour 00 00 * * * /usr/sbin/ypxfr_2perday # run at midnight 00 12 * * * /usr/sbin/ypxfr_2perday # run at noon 00 1 * * * /usr/sbin/ypxfr_1perday # run at 1 A.M.To minimize the performance impact on the master server, alter the exact time of execution of the shell scripts on each server. For example, if the first slave server has the above entries, the second slave server might run its shell scripts five minutes later by having the entries:
5 * * * * /usr/sbin/ypxfr_1perhour # run every hour 5 00 * * * /usr/sbin/ypxfr_2perday # run at 12:05 A.M. 5 12 * * * /usr/sbin/ypxfr_2perday # run at 12:05 P.M. 5 1 * * * /usr/sbin/ypxfr_1perday # run at 1:05 A.M.Save the file and exit the editor.
crontab cron.tmpThis command defines the crontab settings to what the cron.tmp file contains. (For more information on defining crontab settings, see the crontab command.)
Transfers, and transfer attempts, are logged in the /var/yp/ypxfr.log file on slave servers. If the file exists, logging results are appended to it. To start logging, enter the command:
touch /var/yp/ypxfr.log
To stop logging, enter the command:
mv /var/yp/ypxfr.log /var/yp/ypxfr.log.old
rm /var/yp/ypxfr.log
Once you have NIS configured on your network, your security, performance, or other needs may change. To accommodate the change, you may want to move the master server configuration to a different host, perhaps one that is more secure or offers greater performance. To do so, use the Web-based System Manager fast path, wsm network, or use the following procedure.
cd /var/yp
makedbm -u domain/ypservers > tmpserverswhere domain specifies the name of this NIS domain. This command sends the contents of the current ypservers map to a file called tmpservers.
YP_MASTER_NAME old_masterchange this line to:
YP_MASTER_NAME new_masterSave the file and exit the editor.
cd /var/ypThen, enter the commands:
makedbm - tmpservers < tmpservers mv tmpservers.pag domain/ypservers.pag mv tmpservers.dir domain/ypservers.dir
smit ypxfrSpecify ypservers in the Name of the MAP to be transferred field, and specify the hostname of the new master server host in the HOSTNAME of the master server field.