Examine All Information Source Files

Check all /etc files and NIS maps for empty fields or corrupted data before configuring NIS+. The NIS+ table-populating scripts and commands might not succeed if the data source files contain empty fields or extraneous characters. Fill blank fields or fix the data before you start. It is better to delete questionable users or machines from the /etc files or NIS maps before running NIS+ scripts, then add them back later after NIS+ is installed, than to proceed with the scripts and possibly corrupt data.

Remove the "." from Host Names

Because NIS+ uses dots (periods) to delimit between machine names and domains and between parent and sub-domains, you cannot have a machine (host) name containing a dot. Before converting to NIS+ you must eliminate any dots in your hostnames. You can convert hostname dots to hyphens (-). For example, you cannot have a machine named sales.alpha. You can convert that name to sales-alpha. (See the hosts man page for detailed information on allowable hostnames.)

Remove the "." from NIS Map Names

As described in "Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model", NIS+ automounter tables have replaced the "." (dot) in the table name with an underscore. You also need to make this change to the names of NIS maps that you will use during the transition. If you do not, NIS+ will confuse the dot in the name with the periods that distinguish domain levels in object names.

Note - Be sure to convert the dot to underscores for all NIS maps, not just those of the automounter. Be aware, however, that changing the names of nonstandard NIS maps from dots to underscores may cause applications that use those nonstandard maps to fail unless you also modify the applications to recognize NIS+ syntax.

Document Your Current NIS Namespace

Documenting your current configuration will give you a clear point of departure for the transition. Make a list of the following items:

Name and location of all current NIS domains and networks
Host name and location of all current NIS servers, both master and slave
Configuration of all current NIS servers, including:
- Host name
- CPU type
- Memory size
- Disk space available
- Name of administrators with root access
Nonstandard NIS maps

Correlate the list of your NIS clients with their eventual NIS+ domains. They must be upgraded to the current Solaris operating environment.

Create a Conversion Plan for Your NIS Servers

Take stock of your NIS servers. Although you can recycle them after the transition is complete, keep in mind that you will go through a stage in which you will need servers for both services. Therefore, you cannot simply plan to satisfy all your NIS+ server needs with your existing NIS servers.

You might find it helpful to create a detailed conversion plan for NIS servers, identifying which NIS servers will be used for NIS+ and when they will be converted. Do not use the NIS servers as NIS+ servers during the first stages of NIS-to-NIS+ transition. As described in " Implementing NIS+: An Introduction", the implementation is most stable when you check the operation of the entire namespace as a whole before you convert any clients to NIS+.

Assign NIS servers to NIS+ domains and identify each server's role (master or replica). When you have identified the servers you plan to convert to NIS+ service, upgrade them to NIS+ requirements (see "Server Memory Requirements").

Implementing NIS+: An Introduction

After you have performed the tasks described in the previous sections, most of the hard work is done. Now all you have to do is set up the namespace you designed and add the clients to it. This chapter describes how to do that. Before performing these steps, verify that all pre-transition tasks have been completed and that users at your site are aware of your plans.

If you plan to run NIS+ domains alongside DNS domains, you must set up one NIS+ sub-domain with each DNS domain. After you have set up a complete NIS+ namespace along with the first DNS domain and have verified that everything is working right, then you can set up the other NIS+ namespaces in parallel.

Phase I-Set Up the NIS+ Namespace

Set up the namespace with full DES authentication, even if the domains will operate in NIS-compatibility mode. Use the NIS+ scripts described in Chapter 4, Configuring NIS+ With Scripts for more explanation of NIS+ structure and concepts. Then perform the following steps:

Set up the root domain.
If you are going to run the root domain in NIS-compatibility mode, use nisserver. (If you choose not to use the setup scripts, use the -Y flag of rpc.nisd and nissetup.)

Populate the root domain tables.
You can use nispopulate to transfer information from NIS maps or text files. Of course, you can also create entries one at a time with nistbladm or nisaddent.

Set up clients of the root domain.
Set up a few clients in the root domain so that you can properly test its operation. Use full DES authentication. Some of these client machines will later be converted to root replica servers and some will serve as machines for the administrators who support the root domain. NIS+ servers should never be an individual's machine.

Create or convert site-specific NIS+ tables.
If the new NIS+ root domain requires custom, site-specific NIS+ tables, create them, with nistbladm and transfer the NIS data into them with nisaddent.

Add administrators to root domain groups.
Remember, the administrators must have LOCAL and DES credentials (use nisaddcred). Their machines should be root domain clients and their root identities should also be NIS+ clients with DES credentials.

Update the sendmailvars table, if necessary.
If your email environment has changed as a result of the new domain structure, populate the root domain's sendmailvars table with the new entries.

Set up root domain replicas.
First convert the clients into servers (use rpc.nisd with -Y for NIS compatibility and also use -B if you want DNS forwarding), then associate the servers with the root domain by running nisserver -R.

For NIS compatibility, run rpc.nisd with the -Y and edit the /etc/init.d/rpc file to remove the comment symbol (#) from the EMULYP line. For DNS forwarding, use the -B option with rpc.nisd.

Test the root domain's operation.
Develop a set of installation-specific test routines to verify a client's functioning after the switch to NIS+. This will speed the transition work and reduce complaints. You should operate this domain for about a week before you begin converting other users to NIS+.

Set up the remainder of the namespace.
Do not convert any more clients to NIS+, but go ahead and set up all the other domains beneath the root domain. This includes setting up their master and replica servers. Test each new domain as thoroughly as you tested the root domain until you are sure your configurations and scripts work properly.

Test the operation of the namespace.
Test all operational procedures for maintenance, backup, recovery, and other scenarios. Test the information-sharing process between all domains in the namespace. Do not proceed to Phase II until the entire NIS+ operational environment has been verified.

Customize the security configuration of the NIS+ domains.
This may not be necessary if everything is working well; but if you want to protect some information from unauthorized access, you can change the default permissions of NIS+ tables so that even NIS clients are unable to access them. You can also rearrange the membership of NIS+ groups and the permissions of NIS+ structural objects to align with administrative responsibilities.


26. Transitioning from NIS to NIS+ Resolve Conflicts Between Login Names and Host Names


	Examine All Information Source Files Check all `/etc` files and NIS maps for empty fields or corrupted data before configuring NIS+. The NIS+ table-populating scripts and commands might not succeed if the data source files contain empty fields or extraneous characters. Fill blank fields or fix the data before you start. It is better to delete questionable users or machines from the `/etc` files or NIS maps before running NIS+ scripts, then add them back later after NIS+ is installed, than to proceed with the scripts and possibly corrupt data. Remove the "." from Host Names Because NIS+ uses dots (periods) to delimit between machine names and domains and between parent and sub-domains, you cannot have a machine (host) name containing a dot. Before converting to NIS+ you must eliminate any dots in your hostnames. You can convert hostname dots to hyphens (`-`). For example, you cannot have a machine named `sales.alpha`. You can convert that name to `sales-alpha`. (See the `hosts` man page for detailed information on allowable hostnames.) Remove the "." from NIS Map Names As described in "Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model", NIS+ automounter tables have replaced the "." (dot) in the table name with an underscore. You also need to make this change to the names of NIS maps that you will use during the transition. If you do not, NIS+ will confuse the dot in the name with the periods that distinguish domain levels in object names. Note - Be sure to convert the dot to underscores for all NIS maps, not just those of the automounter. Be aware, however, that changing the names of nonstandard NIS maps from dots to underscores may cause applications that use those nonstandard maps to fail unless you also modify the applications to recognize NIS+ syntax. Document Your Current NIS Namespace Documenting your current configuration will give you a clear point of departure for the transition. Make a list of the following items: Name and location of all current NIS domains and networks Host name and location of all current NIS servers, both master and slave Configuration of all current NIS servers, including: Host name CPU type Memory size Disk space available Name of administrators with root access Nonstandard NIS maps Correlate the list of your NIS clients with their eventual NIS+ domains. They must be upgraded to the current Solaris operating environment. Create a Conversion Plan for Your NIS Servers Take stock of your NIS servers. Although you can recycle them after the transition is complete, keep in mind that you will go through a stage in which you will need servers for both services. Therefore, you cannot simply plan to satisfy all your NIS+ server needs with your existing NIS servers. You might find it helpful to create a detailed conversion plan for NIS servers, identifying which NIS servers will be used for NIS+ and when they will be converted. Do not use the NIS servers as NIS+ servers during the first stages of NIS-to-NIS+ transition. As described in " Implementing NIS+: An Introduction", the implementation is most stable when you check the operation of the entire namespace as a whole before you convert any clients to NIS+. Assign NIS servers to NIS+ domains and identify each server's role (master or replica). When you have identified the servers you plan to convert to NIS+ service, upgrade them to NIS+ requirements (see "Server Memory Requirements"). Implementing NIS+: An Introduction After you have performed the tasks described in the previous sections, most of the hard work is done. Now all you have to do is set up the namespace you designed and add the clients to it. This chapter describes how to do that. Before performing these steps, verify that all pre-transition tasks have been completed and that users at your site are aware of your plans. If you plan to run NIS+ domains alongside DNS domains, you must set up one NIS+ sub-domain with each DNS domain. After you have set up a complete NIS+ namespace along with the first DNS domain and have verified that everything is working right, then you can set up the other NIS+ namespaces in parallel. Phase I-Set Up the NIS+ Namespace Set up the namespace with full DES authentication, even if the domains will operate in NIS-compatibility mode. Use the NIS+ scripts described in Chapter 4, Configuring NIS+ With Scripts for more explanation of NIS+ structure and concepts. Then perform the following steps: Set up the root domain. If you are going to run the root domain in NIS-compatibility mode, use `nisserver`. (If you choose not to use the setup scripts, use the `-Y` flag of `rpc.nisd` and `nissetup`.) Populate the root domain tables. You can use `nispopulate` to transfer information from NIS maps or text files. Of course, you can also create entries one at a time with `nistbladm` or `nisaddent`. Set up clients of the root domain. Set up a few clients in the root domain so that you can properly test its operation. Use full DES authentication. Some of these client machines will later be converted to root replica servers and some will serve as machines for the administrators who support the root domain. NIS+ servers should never be an individual's machine. Create or convert site-specific NIS+ tables. If the new NIS+ root domain requires custom, site-specific NIS+ tables, create them, with `nistbladm` and transfer the NIS data into them with `nisaddent`. Add administrators to root domain groups. Remember, the administrators must have LOCAL and DES credentials (use `nisaddcred`). Their machines should be root domain clients and their root identities should also be NIS+ clients with DES credentials. Update the sendmailvars table, if necessary. If your email environment has changed as a result of the new domain structure, populate the root domain's `sendmailvars` table with the new entries. Set up root domain replicas. First convert the clients into servers (use `rpc.nisd` with `-Y` for NIS compatibility and also use `-B` if you want DNS forwarding), then associate the servers with the root domain by running `nisserver` `-R`. For NIS compatibility, run `rpc.nisd` with the `-Y` and edit the `/etc/init.d/rpc` file to remove the comment symbol (`#`) from the `EMULYP` line. For DNS forwarding, use the `-B` option with `rpc.nisd`. Test the root domain's operation. Develop a set of installation-specific test routines to verify a client's functioning after the switch to NIS+. This will speed the transition work and reduce complaints. You should operate this domain for about a week before you begin converting other users to NIS+. Set up the remainder of the namespace. Do not convert any more clients to NIS+, but go ahead and set up all the other domains beneath the root domain. This includes setting up their master and replica servers. Test each new domain as thoroughly as you tested the root domain until you are sure your configurations and scripts work properly. Test the operation of the namespace. Test all operational procedures for maintenance, backup, recovery, and other scenarios. Test the information-sharing process between all domains in the namespace. Do not proceed to Phase II until the entire NIS+ operational environment has been verified. Customize the security configuration of the NIS+ domains. This may not be necessary if everything is working well; but if you want to protect some information from unauthorized access, you can change the default permissions of NIS+ tables so that even NIS clients are unable to access them. You can also rearrange the membership of NIS+ groups and the permissions of NIS+ structural objects to align with administrative responsibilities.