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

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.

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.

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-2 shows how the systems are classified.

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

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

# cd /var/yp

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

# cd /var/ns/domains
# makemdbm - /var/ns/domains/shapes/yourmap.m

al ar 
bl br 
cl cr 
Ctrl-D

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

# killall -HUP nsd 

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:

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.

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.

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.

# 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

# 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

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:

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:

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.