This chapter provides a brief overview of Network Information Service Plus (NIS+), lists the tasks you need to perform before setting up NIS+, identifies the minimum requirements of an NIS+ namespace, then describes the two methods of NIS+ setup.
NIS+ is a network name service similar to NIS but with more features. NIS+ is not an extension of NIS; it is a new software program.
NIS+ enables you to store information such as workstation addresses, security information, mail information, information about Ethernet interfaces, and network services in central locations where all workstations on a network can access it. This configuration of network information is referred to as the NIS+ namespace.
The NIS+ namespace is hierarchical, and is similar in structure to the UNIXTM file system. The hierarchical structure allows a NIS+ namespace to be configured to conform to the logical hierarchy of an organization. The namespace's layout of information is unrelated to its physical arrangement. Thus, a NIS+ namespace can be divided into multiple domains that can be administered autonomously. Clients are allowed access to information in domains other than their own if they have the appropriate permissions.
NIS+ uses a client-server model to store and have access to the information contained in an NIS+ namespace. Each domain is supported by a set of servers. The principal server is called the master server and the backup servers are called replicas. The network information is stored in 16 standard NIS+ tables in an internal NIS+ database. Both master and replica servers run NIS+ server software and both maintain copies of NIS+ tables. Changes made to the NIS+ data on the master server are incrementally and automatically propogated to the replicas.
NIS+ includes a sophisticated security system to protect the structure of the namespace and its information. It uses authentication and authorization to verify whether a client's request for information should be fulfilled. Authentication determines whether the information requestor is a valid user on the network. Authorization determines whether a particular user is allowed to have or modify the information requested.
Solaris clients use the name service switch (the /etc/nsswitch.conf file) to determine from where a workstation will retrieve network information. Such information may be stored in local /etc files, NIS, DNS, or NIS+. You can specify different sources for different types of information in the name service switch.
For a more thorough description of NIS+, see the Solaris Naming Administration Guide.
Before configuring your NIS+ namespace, you must:
Install properly configured nsswitch.conf files on all the machines that use NIS+. See Chapter 1, Setting Up the Name Service Switch for details.
Plan your NIS+ layout. This includes:
Planning your namespace. What will your domain name be? Will you have subdomains, and if so how will they be organized? Which machines will be in which domain? Will your domain be connected to a higher domain or to the Internet?
Determining your server requirements. How many replica servers will be needed for each domain? What type of server, processor speed, and memory is required? How much server disk space is needed?
See the NIS+ Transition Guide for a detailed description of these and other planning issues, and recommended guidelines.
Prepare your existing namespace (if any). See "Preparing the Existing Namespace".
Choose a root server machine.
Make sure that you have at least one system already running at your site that can be used as your root master server. This machine must contain at least one user (root) in the system information files, such as /etc/passwd. (Machines usually come with root in the system files, so this should not be a problem.)
If an NIS domain already exists at your site, you can use the same flat domain structure for your NIS+ namespace. (You can change it later to a hierarchical structure.) Read the NIS+ Transition Guide before you start your transition from NIS to NIS+ for important planning and preparation information. The NIS+ scripts enable you to start NIS+ with data from NIS maps. Chapter 4, Configuring NIS+ With Scripts shows you how to use the NIS+ scripts to create a NIS+ namespace from either system files or NIS maps.
In order for the scripts to run smoothly, however, you must prepare your existing namespace (if you have one) for conversion to NIS+. These preparations are described fully in NIS+ Transition Guide.
For your reference, key preparations are summarized below:
Domain and host names. Domains and hosts must not have the same name. For example, if you have a sales domain you cannot have a machine named sales. Similarly, if you have a machine named home, do not create a domain named home. This caution also applies to subdomains; for example, if you have a machine named west, you don't want to create a sales.west.myco.com subdirectory.
No dots in host names. Because NIS+ uses dots (periods) to delimit between machine names and domains and between parent and subdomains, you cannot have a machine name containing a dot. Before converting to NIS+ (before running the scripts) you must eliminate any dots in your host names. You should convert host name dots to hyphens. For example, you cannot have a machine named sales.alpha. You can convert that name to sales-alpha.
Root server must be running. The machine that is designated to be the root server must be up and running and you must have superuser access to it.
View any existing local /etc files or NIS maps that you will load data from. Make sure that there are no spurious or incorrect entries. Make sure that the right data is in the correct place and format. Remove any outdated, invalid, or corrupt entries. You should also remove any incomplete or partial entries. You can always add individual entries after configuration is completed. That is easier than trying to load incomplete or damaged entries.
In Solaris 2.4 and earlier, the /var/nis directory contained two files named hostname.dict and hostname.log. It also contained a subdirectory named /var/nis/hostname. When you install NIS+ for Solaris 2.5, the two files are named trans.log and data.dict, and the subdirectory is named /var/nis/data. In Solaris 2.5, the content of the files has also been changed and they are not backward compatible with Solaris 2.4 or earlier. Thus, if you rename either the directories or the files to match the Solaris 2.4 patterns, the files will not work with either the Solaris 2.4 or the Solaris 2.5 version of rpc.nisd. Therefore, you should rename neither the directories nor the files.
The rest of this part of the manual describes two different methods of configuring an NIS+ namespace:
With the setup (configuration) scripts. Chapters 2 and 3 describe how to configure NIS+ using the three NIS+ scripts: nisserver, nispopulate, and nisclient. This is the easiest, as well as recommended, method.
With the NIS+ command set. Chapters 4 through 9 describe how to configure NIS+ using the NIS+ command set. While this method gives you more flexibility than the scripts method, it is more difficult. This method should be used only by experienced NIS+ administrators who need to configure a namespace with characteristics significantly different than those provided by the configuration scripts.
If you use the NIS+ command set, you must also make sure that each machine using NIS+ for its name service has the correct nsswitch.conf file in its /etc directory as described in Chapter 1, Setting Up the Name Service Switch. If you use the NIS+ configuration scripts on a given machine, this step is performed for you.
See Solaris Naming Administration Guide for information on how to remove an NIS+ directory or domain, an NIS+ server, or the NIS+ namespace.