Configuring the Network Information Service (NIS)

Modifying the list of NIS servers

At times you may need to add or remove a slave or copy-only server from NIS service.

For example, if you need to remove from the network a machine that was an NIS server, you must remove the machine from NIS service before removing it from the network.

If the machine removed was a slave server, you would probably want to add a slave server to replace it.

Circumstances may also require removing from the network the machine serving as the NIS master server. In this case, you would need to change the NIS master server.

Adding an NIS server to the server list

After you initialize NIS, follow this procedure to add servers to your NIS network at any time:

Log into the master server in multiuser mode.
Edit the ypservers map to add the name of the new server(s) and propagate it to other servers as described in ``Modifying existing maps''. The ASCII file for the ypservers map is located at /etc/yp/ypservers.
Log into the new server in system maintenance mode. If the SCO NIS package is not yet installed, you must first install it using the Software Manager; refer to ``Installing and managing software components'' for more information.
Initialize NIS on the new server following the instructions in ``Enabling an NIS server''. When you bring the new server to multiuser mode, it automatically requests that all current maps be transferred to itself.

Removing an NIS server from the server list

To remove a slave or copy-only server from an NIS domain:

Remove the NIS package from the server using the Software Manager.
Edit the ypservers map on the master server and propagate it to other servers.

CAUTION: Do not use the following procedure to remove a master server. If you do, you must reconfigure your NIS network. Rather, refer to ``Changing the master NIS server''.

When SCO NIS is removed from a system, the /etc/passwd.local file is removed. The /etc/passwd file, which under NIS included both distributed and local accounts, becomes the authoritative password file. This means that distributed NIS accounts become regular user accounts when NIS is removed. If you want to restrict users with distributed NIS accounts from using the old server, you must remove their accounts before returning the old server to multiuser mode.

NOTE: Although you can prevent NIS maps from reaching a server by killing its NIS daemon processes, the master still attempts to reach the server during map propagation, adding an unnecessary burden to the system. For this reason, you should remove NIS from the server.

Follow these steps to remove a server:

Log into the old server in system maintenance mode.
Run the Software Manager (or custom) to remove the Base Network Information System (NIS) package. You can expose this package by expanding the following selections:

SCO OpenServer Enterprise System
SCO OpenServer Enterprise System Connectivity
SCO NFS
If necessary, modify or retire previously distributed accounts; refer to ``Adding and modifying user accounts'' or ``Removing or retiring a user account'' for more information.
If necessary, remove root's crontab entries for NIS map transfers.
Reboot the system and return to multiuser mode. If kernel parameters were adjusted when NIS was removed, you are also prompted to relink the kernel.
Log into the master server in multiuser mode.
Edit the ypservers map to remove the old server's name and propagate the changed map to other servers. See ``Modifying existing maps'' for the procedure for editing and propagating an existing map. The ASCII file for the ypservers map is located at /etc/yp/ypservers.

Changing the master NIS server

You may need to change your master server, for example, if you rearrange server configuration or the master server host is removed from service. Any server in the NIS domain can become the new master server because each one has all active maps. However, because the old NIS master's name is contained in the existing map, you can neither use an existing copy at the new master nor send a copy there with ypxfr. Rather, you must re-create these maps by running ypmake (or make) on the new master server to associate the new server listing with each map.

The old master server must be running NIS to complete this procedure. This is because nonmaster servers consult their own copies of maps, which include the name of the old master server, when they receive a map transfer request originating from yppush on the master. New maps with the new master server listing must come from the old master server for the maps to be incorporated on slave and copy-only servers. Therefore, if the old master is not available when you change master servers, you must rebuild your entire NIS system from scratch.

CAUTION: Changing master servers is a major reconfiguration of your network and should not be undertaken unless absolutely necessary. Make sure you understand the procedure thoroughly and back up your network configuration files before you begin.

The procedures described here assume that the new master is running SCO NIS. Other implementations of NIS configure servers in a different way; consult the documentation for your version of NIS before changing master servers.

To change NIS master servers, follow these steps:

Log into the new master server in multiuser mode.
Copy the /etc/passwd.yp file from the old master. If this file is not available, you must re-create distributed accounts manually. If you have modified the /etc/yp/ypmake or /etc/yp/Makefile file, you must also copy it from the old master.
Run the following commands to rebuild the maps:

cd /etc/yp
rm *.time
ypmake NOPUSH=1
By removing the timestamp files, you force the maps to be rebuilt regardless of prior modifications. The NOPUSH option to ypmake prevents maps from being pushed to other servers until you have completed this entire procedure.
If the map only exists as a ndbm database, you can remake it on the new master by unassembling an existing copy from any NIS server and running the unassembled version back through makedbm. For example, enter:

cd /etc/yp
ypcat -k mymap | ./makedbm - domain_name/mymap
Log into the old master server.
Copy the new maps from the new master server with the following command:

/etc/yp/ypxfr -h new_master -f mapname
This command must be run on the old master for every current NIS map. The -h option forces ypxfr to transfer the map from the new master; the -f option forces the transfer even if the contents of the old and new maps are the same.
Propagate the new maps from the old master server by running the following command on the old master server:

/etc/yp/yppush mapname
This command must be run on the old master for every current NIS map. When this is completed, all nonmaster servers will have received maps that include the new master listing.
If you are removing the old master server from NIS service, edit the ypservers map on the new master server following the instructions in ``Removing an NIS server from the server list''.

You can automate the map transfer procedure on the old master server using shell scripts and other tools. For example, the following shell script automatically completes steps 6 and 7:

   \:
   MAPS=`oawk '{print $1 ; }' /etc/yp/YP_MAP_X_LATE`
   for map in $MAPS; do
   echo moving $map
   ypxfr -h new_master -f $map
   yppush $map
   done

Make sure your /etc/yp/YP_MAP_X_LATE file is current before running this command; for more information, refer to ``NIS maps''.