Configuring NIS+ Servers
This chapter provides step-by-step procedures for using the NIS+ commands to set up NIS+ servers (except the root master) and add replica servers to existing NIS+ domains.
Note - NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see Part V). For more information, visit http://www.sun.com/directory/nisplus/transition.html.
Setting Up an NIS+ Server
It is much easier to perform this task with the NIS+ installation scripts than with the NIS+ command set described here. The methods described in this chapter should be used only by those administrators who are very familiar with NIS+ and who require some nonstandard features or configurations not provided by the installation scripts.
Standard Versus NIS-Compatible Configuration Procedures
The differences between setting up an NIS-compatible and a standard NIS+ server are the same as the differences between setting up standard and NIS-compatible root master servers (see "Standard Versus NIS-Compatible Configuration Procedures"). The NIS+ daemon for an NIS-compatible server must be started with the -Y option (and the -B option for DNS forwarding), which allows the server to answer requests from NIS clients. This is described in Step 2 (the equivalent step for standard NIS+ servers is Step 3).
Note - Whenever rpc.nisd is started with either the -Y or -B option, a secondary daemon named rpc.nisd_resolv is spawned to provide name resolution. This secondary daemon must be separately killed whenever you kill the primary rpc.nisd daemon.
Here is a summary of the entire configuration process:
Log in as superuser to the new replica server.
[NIS-Compatibility Only] Start the NIS+ daemon with -Y.
[Standard NIS+ Only] Start the NIS+ daemon.
Security Considerations
Note - The NIS+ security system is complex. If you are not familiar with NIS+ security, you might want to reviewChapter 11, NIS+ Security Overview before starting to configure your NIS+ environment.
The security level at which you start the server determines the credentials that its clients must have. For instance, if the server is configured with security level 2 (the default), the clients in the domain it supports must have DES credentials. If you have configured the client according to the instructions in this book, the client has DES credentials in the proper domain, and you can start the server with security level 2.
Note - Security level 0 is for administrator configuration and testing purposes only. Security level 1 is not supported. Do not use level 0 or 1 in any environment where ordinary users are doing their normal work. Operating networks should always be run at security level 2.
Prerequisites
The root domain must already be configured (see Chapter 5, Setting Up the Root Domain).
The server must have already been initialized as an NIS+ client (see Chapter 6, Configuring NIS+ Clients).
To configure a server you must be logged in as superuser on that machine.
For the server to run in NIS-compatibility mode and support DNS forwarding, it must have a properly configured /etc/resolv.conf file (described in"DNS Administrtaion (Reference)" in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)).
Information You Need
You need the superuser password of the client that you will convert into a server.
How to Configure an NIS+ Server
While it is possible to have a master or replica server serving more than one domain, doing so is not recommended.
Log in as superuser to the new replica server.
The following steps assume that you rebooted the machine after you set it up as an NIS+ client, as instructed in "Configuring the Client". Rebooting starts the cache manager, which is a recommended prerequisite to the following step. If you did not reboot the machine, restart the cache manager now, using nis_cachemgr.
[NIS-Compatibility Only] Start the NIS+ daemon with -Y.
Perform this step only if you are setting up the server in NIS-compatibility mode; if setting up a standard NIS+ server, perform Step 3 instead. This step also includes instructions for supporting the DNS forwarding capabilities of NIS clients.
This step has two parts. The first part starts the NIS+ daemon in NIS-compatibility mode. The second part makes sure that when the server is rebooted, the NIS+ daemon restarts in NIS-compatibility mode.
Run rpc.nisd with the -Y and -B flags.
compatserver# rpc.nisd -Y -B
The -Y option invokes an interface that answers NIS requests in addition to NIS+ requests. The -B option supports DNS forwarding.
Edit the /etc/init.d/rpc file.
Search for the string EMULYP=-Y in the /etc/init.d/rpc file and uncomment that line.
To retain DNS forwarding capabilities, add a -B flag to the EMULYP=-Y line. (If you don't need to retain DNS forwarding capabilities, uncomment the line, but don't add the -B flag.)
This step creates a directory called /var/nis/data and a transaction log file called trans.log, which is placed in /var/nis.
compatserver# ls -F /var/nis NIS_COLD_START data/ trans.log data.dict
The trans.log file is a transaction log. You can examine the contents of the transaction log by using the nislog command, described in "The nislog Command".
Caution - Do not move or rename the /var/nis or /var/nis/data directories. Do not move or rename the /var/nis/trans.log or /var/nis/data.dict files.
If you are upgrading from Solaris Release 2.4 or earlier, the older /hostname subdirectory is automatically converted to /var/nis/data and the relevant files are converted as necessary.
Do not change these new names after the conversion has
occurred. Now this server is ready to be designated a master or replica of a domain, as described in Chapter 8, Configuring a Non-Root Domain. This step completes this task. A task summary is provided on "Server Configuration Summary".
[Standard NIS+ Only] Start the NIS+ daemon.
Run the rpc.nisd command.
server# rpc.nisd
To verify that the NIS+ daemon is indeed running, use the ps command.
server# ps -ef | grep rpc.nisd root 1081 1 16:43:33 ? 0:01 rpc.nisd root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd
This step creates a directory called /var/nis/data and a transaction log file called trans.log which is placed in /var/nis.
compatserver# ls -F /var/nis NIS_COLD_START data/ trans.log data.dict
The compatserver.log file is a transaction log. You can examine the contents of the transaction log by using the nislog command, described in Chapter 18, Administering NIS+ Directories.
Caution - Do not move or rename the /var/nis or /var/nis/data directories. Do not move or rename the /var/nis/trans.log or /var/nis/data.dict files.
If you are upgrading from Solaris Release 2.4 or earlier, the older /hostname subdirectory will be automatically converted to /var/nis/data and the relevant files will also be converted as
necessary. Do not change these new names after the conversion
has occurred.Now this server is ready to be designated a master or replica of a domain, as described in Chapter 8, Configuring a Non-Root Domain. This step completes this task. A task summary is provided on "Server Configuration Summary".
Adding a Replica to an Existing Domain
To have regularly available NIS+ service, you should always create one or more replica servers for each domain. Having replicas can also speed network-request resolution because multiple servers are available to handle requests.
For performance reasons, you should have no more than a few replicas per domain. If your network includes multiple subnets or different sites connected by a Wide Area Network (WAN), you might need additional replicas:
Subnets. If you have a domain that spans multiple subnets, it is a good idea to have at least one replica server within each subnet so that, if the connection between nets is temporarily out of service, each subnet can continue to function until the connection is restored.
Remote sites. If you have a domain spanning multiple sites linked over a WAN, it is a good idea to have at least one replica server on each side of the WAN link. For example, it may make sense from an organizational point of view to have two physically distant sites in the same NIS+ domain. If the domain's master server and all of its replicas are at the first site, there will be much NIS+ network traffic between the first and second sites. Creating an additional replica at the second site should reduce network traffic.
See "Determining Server Requirements" for more information on replica distribution and on how to determine the optimum number of replicas. To add a replica to an existing domain you must first configure the new replica, then load the NIS+ data set for your namespace.
The two ways to configure and load a new replica server are:
Scripts. You can use the nisserver script, as described in "Creating a Root Replica Server". This method automatically performs a full re-sync to load the NIS+ data set on to the new replica server. This is the preferred method because it is easiest, but it might be slower than using the NIS+ command set and backup/restore.
NIS+ command set. You can use the NIS+ command set to configure a replica, as described in "Using NIS+ Commands to Configure a Replica Server". This requires more knowledge of NIS+ than using nisserver. One advantage of this method is that it gives you the maximum amount of control and monitoring. Another advantage is that you can bring up a replica by manually creating the domain directories, then loading the NIS+ data set using nisbackup and nisrestore. Using the NIS+ backup and restore capability loads data faster than that used by nisserver.
The two ways to load the NIS+ data set on to the newly configured replica server are:
nisping. When you configure a new replica server with either the nisserver script or the NIS+ command set, the master server automatically begins to load the namespace data set on to the new replica over the network using nisping. If your namespace is large, this could take a long time, during which requests for naming information could be delayed. See " Using nisping to Load Data on to a Replica Server" for details.
Backup and restore. You can interrupt the transfer of data via nisping, and use the NIS+ backup and restore capabilities to load your namespace data on to a newly configured replica server, as described in "Using nisrestore to Load Data on to a Replica Server". This is the preferred method because the replica's data set is downloaded on to the replica, which is much faster than having the master transfer the data set to the replica over the network.