Chapter 5. Maintaining NIS
Prev |  | Next

## 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 ”

- “Changing NIS Passwords”

- “Using Netgroups ”

- “Creating a Nonstandard NIS Map Manually: Pre-IRIX 6.5 ”

- “Creating a Nonstandard NIS Map Manually: IRIX 6.5 and Later”

- “ Modifying NIS Maps After NIS Installation”

- “ Preparing to Propagate Nonstandard Maps”

- “Propagating an NIS Map”

- “ Adding an NIS Slave Server”

- “ Changing the Master Server”

- “ Using Secure ypset ”

## 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:

         +userid

     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:

   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/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).
   group |  | 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

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.

Table 5-2. Sample Host Groups

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 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
    Ctrl-D

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
    Ctrl-D

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 `auto.foo`. This file is based on a file named `/etc/auto.foo`:

       auto.foo:          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 `auto.foo` map modified to work under IRIX 6.5.

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

         AUTO_MASTER=auto_master

         #Makedbm distributed with IRIX that builds maps for
         #audofsd/automount correctly

         O_MAKEMDBM =     /usr/sbin/makemdbm

         localall: all $(AUTO_MASTER)

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

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.direct`,`auto_master`, and `auto.home` from the files`/etc/auto.test`, `/etc/auto.direct`, `/etc/auto_master` (used by the `autofsd` daemon), and `/etc/auto.home`.

    AUTO_MASTER=auto_master
    DIRECT=auto.direct
    INDIRECT=auto.test
    HOME=auto.home

    O_MAKEMDBM =    /usr/sbin/makemdbm

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

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

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

    # 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)”;\
            fi

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
    auto.direct:            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:

    (nis_security=true)

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

    # domainname
    shapes
    # 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:

    (nis_security=true)

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

    (nis_security=true)

in the previous examples with either of the following:

    (nis_security=false)
    (nis_security=local)

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.

Prev | Table of Contents | Next
Chapter 4. Setting Up and Testing NIS |  | Chapter 6. Troubleshooting NIS