4.4. Managing multiple domains

A single NIS server may be a slave of more than one master server, if it is providing service to multiple domains. In addition, a server may be a master for one domain and a slave of another. Multimaster relationships are set up when NIS is installed on each of the master servers. In the course of building the ypservers map, the slave servers handling multiple domains are named in the ypservers map for each domain.

When multiple domains are used with independent NIS servers (each serving only one domain), it is sometimes necessary to keep one or more of the maps in these domains in perfect synchronization. Domains with different password and group files, for example, might still want to share global alias and host maps to simplify administration. Adding a new user to either domain would make the user's mail aliases appear in the global alias file, to be shared by both domains. Figure 4-1 shows three NIS domains that share some maps and keep private copies of others.

Figure 4-1. Map sharing in multiple domains

The hosts and aliases maps are shared between the NIS domains so that any changes to them are reflected on all NIS clients in all domains. The passwd and group files are managed on a per-domain basis so that new users or groups in one domain do not automatically appear in the other domains. This gives the system administrators fine control over user access to machines and files in each NIS domain.

A much simpler case is the argument for having a single /etc/rpc file and an /etc/services file across all domains in an organization. As locally developed or third-party software that relies on these additional services is distributed to new networks, the required configuration changes will be in place. This scenario is most common when multiple NIS domains are run on a single network with less than one system administrator per domain.

Sharing maps across domains involves setting up a master/slave relationship between the two NIS master servers. The map transfer can be done periodically out of cron on the "slave" master server, or the true master server for the map can push the modified source file to the secondary master after each modification. The latter method offers the advantages of keeping the map source files synchronized and keeping the NIS maps current as soon as changes are made, but it requires that the superuser have remote execution permissions on the secondary NIS master server.

To force a source file to be pushed to another domain, modify the NIS Makefile to copy the source file to the secondary master server, and rebuild the map there:

hosts.time:       
        .... 
        rebuild hosts.byname and hosts.byaddr 
        @touch hosts.time;  
        @echo "updated hosts";  
        @if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) hosts.byname; fi 
        @if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) hosts.byaddr; fi 
        @if [ ! $(NOPUSH) ]; then echo "pushed hosts"; fi 
        @echo "copying hosts file to NIS server ono" 
        @rcp /etc/hosts ono:/etc/hosts 
        @echo "updating NIS maps on ono" 
        @rsh ono "( cd /var/yp; make hosts )"

The commands in the Makefile are preceded by at signs (@) to suppress command echo when make is executing them. rcp moves the file over to the secondary master server, and the script invoked by rsh rebuilds the maps on server ono.

Superuser privileges are not always extended from one NIS server to another, and this scheme works only if the rsh and rcp commands can be executed. In order to get the maps copied to the secondary master server, you need to be able to access that server as root. You might justifiably be concerned about the security implications, since the rcp and rsh commands work without password prompts. One alternative is to leave the source files out-of-date and simply move the map file to the secondary master and have it distributed to slave servers in the second domain. Another alternative is to use Kerberos V5 versions of rcp and rsh or to use the secure shell (ssh). Kerberos V5 and ssh are available as free software or in commercial form. Your vendor might even provide one or both. For Solaris 2.6 and upward, you can get the Sun Enterprise Authentication Mechanism (SEAM) product from Sun, which has Kerberos V5, including rcp and rsh using Kerberos V5 security (see Section 12.5.5.2, "SEAM: Kerberos V5 for Solaris"). If you use SEAM, you'll want to prefix rcp and rsh in the Makefile with /usr/krb5/bin/.

The following script can be run out of cron on the secondary master server to pick up the host maps from NIS server mahimahi, the master server for domain nesales:

#! /bin/sh 
/usr/lib/netsvc/yp/ypxfr -h mahimahi -s nesales hosts.byname 
/usr/lib/netsvc/yp/ypxfr -h mahimahi -s nesales hosts.byaddr 
/usr/lib/netsvc/yp/yppush -d `domainname` hosts.byname 
/usr/lib/netsvc/yp/yppush -d `domainname` hosts.byaddr

The ypxfr commands get the maps from the primary master server, and then the yppush commands distribute them in the local, secondary NIS domain. The -h option to ypxfr specifies the hostname from which to initiate the transfer, and overrides the map's master record. The -s option indicates the domain from which the map is to be taken. Note that in this approach, the hosts map points to mahimahi as the master in both domains. If the rcp-based transfer is used, then the hosts map in each domain points to the master server in that domain. The master server record in the map always indicates the host containing a source file from which the map can be rebuilt.

---