This section shows you how to create the master server of a new non-root domain. The new domain will be a subdomain of the doc.com. domain. The hierarchical structure of NIS+ allows you to create a domain structure that parallels your organizational structure.
This example shows the machine client2 being converted to the master server of a new domain called sub.doc.com.. This procedure uses the NIS+ script nisserver.
Before you can run nisserver to create a master server for a new non-root domain:
The parent domain must already have been configured and its master server must be running.
The parent 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 new client machine in the parent domain.
You must have started rpc.nisd on the client.
You must have adequate permissions to add the new domain. In this case, you must be logged in as root on the parent master server. In this example, the parent master machine is named master1.
You need:
A name for the new non-root domain—the name of the new domain includes the name of the parent domain with this syntax: newdomain.rootdomain.
The client machine name (client2, in this example)
The superuser password for the parent master server
In How to Create a New Non-Root Domain, the new non-root domain is called sub.doc.com..
In Solaris release 2.6 and earlier, any NIS+ client can be converted to an NIS+ master server as long as it is itself in a domain above the domain it is serving. For example, an NIS+ client in domain sales.doc.com. can serve domains below it in the hierarchy, such as west.sales.doc.com. or even alameda.west.sales.doc.com.. This client cannot, however, serve the domain doc.com., because doc.com. is above the domain sales.doc.com. in the hierarchy. Root replicas are the only exception to this rule. They are clients of the domain that they serve.
In Solaris release 7, the domainname of any non-root NIS+ server can be set to the domain it serves. The non-root server behaves as if it lives in its own domain. This allows you to configure applications on the non-root server to use the information provided by the domain above it in the hierarchy.
The non-root server's credentials must still be in the domain above it in the hierarchy. Configure the non-root servers as described in How to Create a New Non-Root Domain. Only after the servers are properly configured, can you change the domainname to that of the domain it serves. See the -k option of nisinit and the -d option of nisserver.
Type the following command as superuser (root) on the NIS+ domain's root master server to create a new non-root domain master server.
The -M option indicates that a master server for a new non-root domain should be created. The -d option specifies the new domain name, sales.doc.com. in this instance. The -h option specifies the client machine, (client2, in this example), that will become the master server of the new domain.
master1# nisserver -M -d sales.doc.com. -h client2 This script sets up a non-root NIS+ master server for domain sales.doc.com. Domain name : sales.doc.com. NIS+ server : client2 NIS+ group : admin.sales.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change) |
Master servers of new non-root domains are created with the same set of default values as root servers. See How to Create a Root Master Server for more information on NIS+ group, NIS compatibility, and security level.
Type y to continue.
Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information for what you need to do if you type n.)
Is this information correct? (type 'y' to accept, 'n' to change) y This script sets up machine “client2” as an NIS+ non-root master server for domain sales.doc.com. Do you want to continue? (type 'y' to continue, 'n' to exit this script) |
Type y to continue.
Typing n safely exits the script. The script exits on its own if rpc.nisd is not running on the client machine.
Do you want to continue? (type 'y' to continue, 'n' to exit this script) y running nissetup ... org_dir.sales.doc.com. created groups_dir.sales.doc.com. created ... ... setting NIS+ group admin.sales.doc.com. ... The system client2 is now configured as a non-root server for domain sales.doc.com. You can now populate the standard NIS+ tables by using the nispopulate or /usr/lib/nis/nisaddent commands. |
The machine client2 is now the master server of the sales.doc.com. domain. The sales.doc.com. domain is a subdomain of the doc.com. domain. The machine client2 is simultaneously still a client of the root domain doc.com., and the master server of the sales.doc.com. domain.
You can now populate the standard NIS+ tables on the new master server of the sales.doc.com. domain.
Repeat the preceding procedure for changing servers to master servers of new non-root domains on as many server machines as you like. Every new master server is a new domain. Plan your domain structure before you start creating an NIS+ namespace. See Structure of the NIS+ Namespace for more information on planning an NIS+ hierarchy.