Chapter 5. Maintaining NIS

This chapter describes, and provides procedures for, NIS maintenance as indicated in the titles of the following sections:

Adding a New User to a System

To add a new user to a system that is an NIS client, perform these steps:

  1. On the NIS master server, add an entry for the new user to the NIS password file (/etc/passwd by default). (For more information, see the passwd(4) man page, the Personal System Administration Guide, or the book IRIX Admin: System Configuration and Operation.)

  2. On the NIS master server, update the NIS passwd map on that system by entering:

    # cd /var/yp
    # ./ypmake passwd

  3. 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).

  4. On the new user's system, modify /etc/passwd in one of these ways:

    • Add the same entry as you added in step 1 in this section. Duplicating the entry enables the user to log in when the network is down.

    • Add this entry:


      Where userid is the login name of the new user. When this type of entry is used, all /etc/passwd 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/passwd information for this user is supplied by NIS.

    • Add this entry:


      When this type of entry is used, all /etc/passwd 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. For alternative NIS entries, see the passwd(4) man page.

  5. 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:


    The parent directory of the home directory you are creating.


    The login name of the user (the first field in the password entry).


    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/passwd entry duplicates the NIS password entry or if NIS maps have been propagated to this system (it takes about 15 minutes after step 2 for updates to propagate).


    The group number for this user (the fourth field in the password entry).

  6. 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.

  7. Have the user add a password to his or her account using yppasswd:

    % yppasswd 

    yppasswd prompts the user to enter the new password twice.

  8. If you added a complete password entry to /etc/passwd on the user's system (the first option in step 4), have the user add his or her password to the local /etc/passwd file, using passwd:

    % passwd 

    passwd prompts for the password twice.

Changing NIS Passwords

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.

  1. 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>

  2. Enter your old NIS password (if the account is not password protected, press Enter.)

    New password: <response not echoed>

  3. Enter your new NIS password:

    Retype new password: <response not echoed>

  4. 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. You can update the information more quickly by using the ypmake command on the NIS master to push the data back to all slave servers after updating its own databases. For more information, see the crontab entries on the NIS master server and see “Propagating an NIS Map”.

If your local password is not given explicitly but rather is pulled in from NIS with a plus (+) entry, then the passwd command prints this 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 server on the system serving as the master server for the NIS password file in your domain.

Using Netgroups

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, mountd, rlogind, and rshd  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 or .rhosts.

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.

Below is a sample /etc/netgroup file. (See the netgroup(4) man page 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)

Note: IRIX (as well as most other UNIX operating systems) supports only 1,024 bytes per line/entry in the netgroup file.

Table 5-1 shows the users in each group.

Table 5-1. Sample User Groups




alan, beth


chris, deborah, eric


alan, beth, chris, deborah, eric


fran, greg


(every user in the NIS map passwd)


(no users)

Table 5-2 shows how the systems are classified.

Table 5-2. Sample Host Groups




mercury, venus, testing


earth, mars


mercury, venus, earth, mars, testing




(no systems)


(all systems in the NIS map hosts)

For more details, see these man pages: yppasswd(1), hosts.equiv(4), export(4), passwd(4), group(4), netgroup(4), and rpc.passwd(1M).

Creating a Nonstandard NIS Map Manually: Pre-IRIX 6.5

You can use ypinit  and /var/yp/local.make.script (see the ypmake(1M) man page) 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 well-formed mdbm file 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).

ASCII File Input

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

# makemdbm /etc/yourmap /var/ns/domains/shapes/yourmap.m

This command sequence creates a map called yourmap in the directory /var/ns/domains/shapes.

Standard Keyboard Input

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/ns/domains
# makemdbm - /var/ns/domains/shapes/yourmap.m

Enter these lines:

al ar 
bl br 
cl cr 

The makemdbm 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/ns/domains/shapes.

Adding the New NIS Map

Add an entry for the new NIS map in the /var/ns/domains/<domainname>/nsswitch.conf file with these commands:

# cd /var/ns/domains 
# cat >> shapes/nsswitch.conf 
yourmap: nisserv 

The nsswitch.conf file now contains the name of the map followed by the protocol to be used. For more information, see the nsswitch.conf(4) man page.

Finally, you must send the nsd daemon a SIGHUP signal for the change to take effect. Enter this command:

# killall -HUP nsd 

Creating a Nonstandard NIS Map Manually: IRIX 6.5 and Later

The IRIX operating system is shipped without default NIS server settings for some common NIS maps, such as auto.master and auto.home. This remains true for IRIX 6.5 and subsequent releases. However, because of the advent of Unified Name Services, NSD, and the demise of the ypserv process, a new procedure is required to serve these maps under IRIX 6.5.

The following steps describe how to serve these maps under IRIX 6.5 and later. Use this procedure if your system has been upgraded to IRIX 6.5 or a subsequent release and was formerly an NIS master server:

  1. Rename your current (that is, earlier than IRIX 6.5) /var/yp/local.make file.

    Caution: If you do not rename this file, make.script will try to run the old local.make.script file (see step 6) and will fail.

    When you create a new script to make and push the maps, you can edit your pre-IRIX 6.5 /var/yp/local.make.script file to conform to the changes that are made to the local.make.script file (see step 6).

  2. Make sure that check configuration is on for yp, ypmaster, and ypserv, and that NIS services are running on the system.

  3. Execute the ypwhich -m command. This command should produce the following output:

    bootparams master
    capability.byname master
    ethers.byname master
    group.byname master
    group.bygid master
    group.bymember master
    hosts.byaddr master
    hosts.byname master
    mail.aliases master
    mail.byaddr master
    netgroup master
    netgroup.byuser master
    netgroup.byhost master
    netid.byname master
    networks.myaddr master
    networks.byname master
    passwd.byname master
    passwd.byuid master
    protocols.bynumber master
    protocols.byname master
    rpc.bynumber master
    rpc.byname master
    services master
    services.byname master
    ypservers master

  4. Make sure that the NIS server is fully functional and that the default maps are updated and pushed properly.

  5. Add the following line to the /var/ns/domains/<yourdomain>/nsswitch.conf and /var/ns/nsswitch.conf.nisserv files to add a new map, called This file is based on a file named /etc/          nisserv

    Note: You must edit both files. This is because /var/ns/nsswitch.conf.nisserv is a prototype file copied to the /var/ns/domain/yourdomain/nsswitch.conf file when the ypinit -m command executes. This enables a single host to serve more than one NIS domain.

  6. Make a copy of the old local.make.script file that you renamed in step 1. Then, edit this file to conform to the syntax and to account for the following major differences between the NIS server for IRIX 6.5 and previous versions:

    • The IRIX 6.5 NIS server uses mdbm instead of dbm.

    • The location and names of most files, including the database file, are different.

    • There may be differences in the behavior of the make command.

    • The ypmake command is an sh script that runs mdbm_parse, local.mdbm_parse, and make make.script, in that order.

      The mdbm_parse program is a Perl program that is used to maintain the default maps. A local mdbm_parse program can be used by any type of program, although Perl is preferred. make.script is still provided, but it is a null script that has no effect on the default yp maps. It is only used in the event that it contains an sinclude call to call a legacy local.make.script.

      The following script is an example of a local.make.script file for the map modified to work under IRIX 6.5.

      Note: Do not substitute spaces for tabs in this script.

      #Makedbm distributed with IRIX that builds maps for
      #audofsd/automount correctly
      O_MAKEMDBM =     /usr/sbin/makemdbm
      localall: all $(AUTO_MASTER)
      #master map for autofsd:
           date “+$(UPDATEFMT) $(AUTO_MASTER) $(DATEFMT)”
           if [ ! $(NOPUSH) ]; then \
                $(YPPUSH) $(AUTO_MASTER); \
                date “+$(PUSHFMT) $(AUTO_MASTER) $(DATEFMT)”;\

  7. Execute the ypmake command.

  8. Once the local.make.script creates the mdbm file, and the local script is working, execute nsadmin restart to restart NSD with the new database.

  9. Execute the ypwhich -m command to ensure that the new map is being served by the NIS server.

  10. Edit the /etc/nsswitch.conf file to add the map to all IRIX 6.5 clients, including the NFS servers.

Additional Tips for Creating Nonstandard Maps Under IRIX 6.5

Observe the following when you create nonstandard maps under IRIX 6.5 and later:

  • Each time you execute the ypinit -m command, you must repeat the previous procedure as shown. This is because the ypinit -m command removes the /var/ns/domain/yourdomain directory.

  • For NIS clients running versions of IRIX prior to 6.5.1, you should assume that host and domain names are case-sensitive.

  • When a problem occurs, the following commands can be helpful: nsadmin restart, nsadmin cat, killall -USR2 nsd, and so forth. See also the nsadmin(1M) man page for related information.

  • The makemdbm command treats the first word or symbol of a line, up to the first white space, as the key. This includes comments. Because comments in the input file are all likely to begin with a # (pound sign), makemdbm puts the first comment line that it encounters into the database with a key of “#”, and ignores subsequent comments.

    To ensure that NIS clients do not misinterpret comments as valid records, you should pass the input file through a regular expression that removes the comment lines.

Modifying NIS Maps After NIS Installation

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.

Modifying a Standard NIS Map

A standard NIS map is any map that has an ASCII file and is included in the /var/yp/mdbm_parse 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:

  1. Edit the ASCII file:

    # vi /etc/passwd.nis

  2. Add this line to the password file:

    tom::2349:20:Tom Cat:/usr/people/tom:/bin/csh 

  3. 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/mdbm_parse and /var/yp/local.make.script). It also propagates the updated map to all slave servers listed in the ypservers database map.

Modifying a Nonstandard NIS Map

Nonstandard or custom 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 custom maps. You can also manually change maps that are not expected to change and maps for which no ASCII form exists.

The general procedure is to use makemdbm with a switch to disassemble the map. The disassembled map is in a form you can modify with standard tools such as awk, sed, or vi. You then build a new map from the changed version using makemdbm.

Use this procedure to modify a nonstandard NIS map:

  1. Disassemble the map, as shown in this sample command:

    # cd /var/yp 
    # makemdbm -u /var/ns/domains/shapes/mymap.m > /var/tmp/mymap.txt

  2. Edit the text file (/var/tmp/mymap.txt, in this example) with any text editor.

  3. Build the new map, as shown in this sample command:

    # makemdbm /var/tmp/mymap.txt /var/ns/domains/shapes/mymap.m

  4. Remove the temporary ASCII file, as shown in this sample:

    # rm /var/tmp/mymap.txt

This procedure modifies and updates custom maps but does not propagate the map to slave servers.

Preparing to Propagate Nonstandard Maps

Preparing to propagate a nonstandard NIS map consists of setting up its mdbm 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.test,, auto_master, and auto.home from the files /etc/auto.test, /etc/, /etc/auto_master (used by the autofsd daemon), and /etc/auto.home.


O_MAKEMDBM =    /usr/sbin/makemdbm

localall: all $(AUTO_MASTER) $(DIRECT) $(INDIRECT) $(HOME)

# master map for autofsd:
        date “+$(UPDATEFMT) $(AUTO_MASTER) $(DATEFMT)”
        if [ ! $(NOPUSH) ]; then \
                $(YPPUSH)  -v $(AUTO_MASTER); \
                date “+$(PUSHFMT) $(AUTO_MASTER) $(DATEFMT)”;\
# DIRECT map:
        date “+$(UPDATEFMT) $(DIRECT) $(DATEFMT)”
        if [ ! $(NOPUSH) ]; then \
                $(YPPUSH) -v $(DIRECT); \
                date “+$(PUSHFMT) $(DIRECT) $(DATEFMT)”;\

        date “+$(UPDATEFMT) $(INDIRECT) $(DATEFMT)”
        if [ ! $(NOPUSH) ]; then \
                $(YPPUSH) $(INDIRECT); \
                date “+$(PUSHFMT) $(INDIRECT) $(DATEFMT)”;\

# HOME map:
$(HOME):        $(DIR)/$(HOME)
        date “+$(UPDATEFMT) $(HOME) $(DATEFMT)”
        $(O_MAKEMDBM) $(DIR)/$(HOME) $(YPDBDIR)/$(HOME).m
        if [ ! $(NOPUSH) ]; then \
                $(YPPUSH) $(HOME); \
                date “+$(PUSHFMT) $(HOME) $(DATEFMT)”;\

Also, add the following lines in the server's /var/ns/nsswitch.conf.nisserv file (or /var/ns/domains/domainname/nsswitch.conf) so client systems can query the maps:

auto_master:            nisserv            nisserv 
auto.home:              nisserv 
auto.test:              nisserv 

Send the NSD daemon a SIGHUP signal for the change to take effect and restart nsadmin:

# killall -HUP nsd
# nsadmin restart 

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 to make two databases suitable for input to makemdbm. For example, the database might be stored as /var/ns/domains/circles/auto.master.m.

To create a customized make script, /var/yp/local.make.script, use the existing /var/yp/local make.script.demo as a source of programming examples. Make use of mechanisms already in place in /var/yp/localmake.script.demo when deciding how to create dependencies that the make command 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 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. For details on the use of these commands, refer to the make(1) and ypxfr(1M) man pages.

Propagating an NIS Map

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 or by executing ypmake, ypxfr, or yppush from a command line.

Periodic Propagation: crontab

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 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 the –h option on the ypxfr command)

For more information on how to use crontab, see the crontab(1) man page.

Interactive Map Propagation

The next three sections describe three methods of manually propagating NIS maps.

Using ypmake

NIS maps on the master server can be manually propagated using the ypmake command. This command looks at the /var/yp/mdbm_parse and/or /var/yp/local.make.script to determine which maps to make. The make script calls makemdbm, which updates the maps and calls yppush . The yppush command 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 by using ypxfr.

Use ypmake to update and propagate maps throughout your domain when you want the change to take place immediately and do not 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 -f passwd

  • To rebuild all of the maps, but not push them to other servers, enter:

    # /var/yp/ypmake UPDATE=1 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

Using ypxfr

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.

The ypxfr command has options that force map transfer and specify alternate domains and servers from which to obtain the map. Below are examples of ypxfr command usage:

  • 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

Using yppush

Although 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 explained below:

  • 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 the transfer attempts of ypxfr 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.

Adding an NIS Slave Server

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:

  1. On the master server, change to the /var/yp directory:

    # cd /var/yp

  2. 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 

  3. Edit the /var/ns/domains/domainname/ypservers file and add the new server's host name:

    # vi ypservers

  4. Propagate the map with ypmake:

    # ./ypmake ypservers

  5. 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

  6. 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.

Changing the Master Server

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:

  1. 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 ” in Chapter 4“ Binding to Another NIS Server ” in Chapter 4, and “ Building the Duplicate Maps” in Chapter 4.

  2. Copy the map source files from the old master server to the new master server. The source files are listed in Table 3-1.

  3. Rebuild all of the maps on the new master server, but do not push them to other servers:

    newmaster# /var/yp/ypmake UPDATE=1 NOPUSH=1

  4. 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 “Standard and Nonstandard Maps” in Chapter 2:

    oldmaster# ypxfr -h newmaster -f mapname

    newmaster is the host name of the new master server and mapname is a map name from “Standard and Nonstandard Maps” in Chapter 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 will not accept maps from the new master server.

  5. 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 “Standard and Nonstandard Maps” in Chapter 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.

Using Secure ypset 

The ypset tool allows the root user on NIS clients to change the binding association for the client. By default, ypset is now an attribute, and to obtain the functionality equivalent to the previous ypserv command the function is set in this manner:


To enable changing the binding association in the domain shapes, first verify the domain name, then set ypset with these commands:

# domainname
# nsd -a (nis_security)

To enable changing the binding association at the server level, edit the server password file so that it reads:

passwd (nis_security)

To enable changing the binding association at the local level, edit the /etc/nsswitch.conf to include this line:


If you desire to mimic the previous behavior of ypsetme, replace


in the previous examples with either of the following:


The result is equivalent to the previous ypsetme.

Previously the file /etc/config/ypbind.options contained the –ypsetme option that enabled ypset. Normally, the –ypsetme option should be present when creating an NIS master because, if it 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.