Now that the client machines have been initialized, you can change any of them to NIS+ servers of the following types:
To be root replicas – to contain copies of the NIS+ tables that reside on the root master server
To be master servers of subdomains of the root domain
To be replicas of master servers of subdomains of the root domain
You can have only one NIS+ master root server. Root NIS+ servers are a special type of NIS+ server. This section does not describe how to configure a root master server; see Setting Up NIS+ Root Servers for more information.
You can configure servers any of these different ways:
Without NIS compatibility
With NIS compatibility
With NIS compatibility and DNS forwarding – you only need to set DNS forwarding if you are going to have SunOS 4 clients in your NIS+ namespace
Servers and their replicas should have the same NIS-compatibility settings. If they do not have the same settings, a client that needs NIS compatibility set to receive network information may not be able to receive it if either the server or replica it needs is unavailable.
Perform any of the following to alternate procedures to configure a client as a server. These procedures create a directory with the same name as the server and create the server's initialization files which are placed in /var/nis.
All servers in the same domain must have the same NIS-compatibility setting. For example, if the master server is NIS compatible, then its replicas should also be NIS compatible.
You need to be superuser or establish an equivalent role to perform this procedure.
You need the superuser password of the client that you will convert into a server before you can start the NIS+ service by using the svcadm command.
Before you start the NIS+ service from the command line by using svcadm, be sure the following prerequisites have been met.
The domain must have already been configured and its master server must be running.
The master server of the domain's tables must be populated. (At a minimum, the hosts table must have an entry for the new client machine.)
You must have initialized the client machine in the domain.
You must be logged in as root on the client machine. In this example, the client machine is named client1.
Optionally, if using DES authentication, the client machine must use the same Diffie-Hellman key configuration as that used on the master server.
View the /lib/svc/method/nisplus file to verify that the -Y option does not appear.
See NIS+ and the Service Management Facility for more information.
Start the NIS+ service.
You need to be superuser or establish an equivalent role to perform this step.
client1# svcadm enable /network/rpc/nisplus:default |
Now this server is ready to be designated a master or replica of a domain.
You need to be superuser or establish an equivalent role to perform this procedure.
Edit the /lib/svc/method/nisplus file on the server to add the -Y option.
See NIS+ and the Service Management Facility for more information.
Start the NIS+ service.
You need to be superuser or establish an equivalent role to perform this step.
client1# svcadm enable /network/rpc/nisplus |
Now this server is ready to be designated a master or replica of a domain.
This procedure configures an NIS+ server with both DNS forwarding and NIS compatibility. Both of these features are needed to support SunOS 4 clients.
You need to be superuser or establish an equivalent role to perform this procedure.
Edit the /lib/svc/method/nisplus file on the server to add the -Y and -B options.
See NIS+ and the Service Management Facility for more information.
Start the NIS+ service.
You need to be superuse,r or establish an equivalent role, to perform this step.
client1# svcadm enable /network/rpc/nisplus:default |
Repeat the preceding client-to-server conversion procedure on as many client machines as you like.
The sample NIS+ domain described in this chapter assumes that you will convert three clients to servers. You will then configure one of the servers as a root replica, another as a master of a new subdomain, and the third as a replica of the master of the new subdomain.