[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]

Network Information Services (NIS and NIS+) Guide

Implementing the Transition

At this point, verify that all your pretransition tasks have been completed and that your site's users are aware of your plans.

If you will be running NIS+ domains alongside DNS domains, you will 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 properly, you can set up the other NIS+ namespaces in parallel.

The major implementation phases are as follows:

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 Using NIS+ Setup Scripts to set up your namespace. See Chapter 4, NIS+ Namespace and Structure for more explanation of NIS+ structure and concepts. Then perform the following steps:

  1. Set up the root domain.

    If you are going to run the root domain in NIS-compatibility mode, use nisserver -Y. (If you choose not to use the setup scripts, see Setting Up the Root Domain.)

  2. Populate the root domain tables.

    You can use nispopulate to transfer information from NIS maps or text files. You can also create entries one at a time with nistbladm or nisaddent.

  3. Set up clients of the root domain.

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

  4. Create or convert site-specific NIS+ tables.

    If the new NIS+ root domain will require custom, site-specific NIS+ tables, create them, with nistbladm and transfer the NIS data into them with nisaddent.

  5. Add administrators to root domain groups.

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

  6. Update the sendmailvars table, if necessary.

    If your e-mail environment has changed as a result of the new domain structure, populate the root domain's sendmailvars table with the new entries.

  7. Set up root domain replicas.

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

  8. Test the root domain's operation.

    Develop a set of installation-specific test routines to verify a client is functioning after the switch to NIS+. You should operate this test domain for about a week before you begin converting other users to NIS+.

  9. Set up the remainder of the namespace.

    Do not convert any more clients to NIS+, but 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.

  10. 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.

  11. Customize the security configuration of the NIS+ domains.

    This may not be necessary if everything is working properly. If, however, you want to protect some information from unauthorized access, you can change the default permissions of NIS+ tables so that even NIS clients would be unable to access them. You could also rearrange the membership of NIS+ groups and the permissions of NIS+ structural objects to align with administrative responsibilities.

Phase II--Connect the NIS+ Namespace to Other Namespaces

  1. [Optional] Connect the root domain to the DNS namespace.

    Workstations, if they are also DNS clients, can have their information retrieval system configuration (/etc/irs.conf) files set to search for information in DNS zone files, in addition to NIS+ tables or NIS maps.

    Configure each client's /etc/resolv.conf file properly. The /etc/resolv.conf lists the IP addresses of the client's DNS servers.

  2. Test the joint operation of NIS+ with DNS.

    Verify that requests for information can pass between the namespaces without difficulty.

  3. If operating NIS+ in parallel with NIS, test the transfer of information.

    Use the nispopulate script to transfer information from NIS to NIS+. To transfer data from NIS+ to NIS, run:

    # nisaddent -d -t hosts.org_dir > hosts 
    # makedbm -b hosts hosts.byname

    Establish policies for keeping tables synchronized, particularly the hosts and passwd tables. Test the tools used to maintain consistency between the NIS and NIS+ environments. Decide when to make the NIS+ tables the actual source of information.

  4. Test operation of NIS+ with both DNS and NIS.

    Test all three namespaces together to make sure the added links do not create problems.

Phase III--Make the NIS+ Namespace Fully Operational

  1. Convert clients to NIS+.

    Convert clients one workgroup at a time, and convert all workgroups in a subnet before starting on those of another subnet. That way, when you convert all the clients in a subnet, you can eliminate the NIS service on that subnet.

    Use the nisclient script to convert NIS clients to NIS+ clients. If you need to modify the clients' DNS configuration, you will have to write your own scripts to automate that process. You will also need to edit the /etc/security/user file to specify NISPLUS authentication for users. For example:

            admin = false
            login = true
            su = true
            daemon = true
            rlogin = true
            sugroups = ALL
            admgroups =
            ttys = ALL
            auth1 = SYSTEM
            auth2 = NONE
            tpath = nosak
            umask = 022
            expires = 0
            SYSTEM = NISPLUS
            logintimes =
            pwdwarntime = 0
            account_locked = false
            loginretries = 0
            histexpire = 0
            histsize = 0
            minage = 0
            maxage = 0
            maxexpired = -1
            minalpha = 0
            minother = 0
            minlen = 0
            mindiff = 0
            maxrepeats = 8
            dictionlist =
            pwdchecks =

    You can also save time if your site has a shared, mounted central directory similar to /usr/local. You could put the script in the central directory and, on the day of conversion, send an e-mail message to clients asking them to run the script as superuser.

  2. Edit the /etc/security/login.cfg, /usr/lib/security/methods.cfg, and /usr/lib/security/methods.cfg configuration files. (Add them, if they do not exist.) The following lines must exist (and not be commented) in each file:

  3. Monitor the status of the transition as clients are being converted.

    Track progress against your plan and all serious complications not anticipated in the planning stages. Communicate your status to interested parties.

  4. Decommission NIS servers.

    When all the clients on a subnet are converted to NIS+, decommission the NIS servers. If a particular subnet has some clients that require NIS service, use the NIS-compatibility feature of the NIS+ servers, but do not retain the NIS servers.

  5. Evaluate NIS+ performance.

    Once the implementation is complete, test to see that NIS+ is working correctly.

  6. Optimize the NIS+ environment.

    Based on the results of your performance evaluation, modify the NIS+ environment as needed. These improvements could be as simple as adding selected replicas in domains with high loads or as involved as rearranging the storage of NIS+ information for a group of domains.

  7. Clean up new domains.

    If you did not change old domain names during the transition for the sake of simplicity, upgrade them now to the new NIS+ naming scheme. For example, if you left some domains with geographic labels while you converted to an organizational hierarchy, you would change the geographic names to their organizational versions.

Phase IV--Upgrade NIS-Compatible Domains

  1. Convert the last NIS clients to NIS+.

    As soon as you can, eliminate the need for NIS-compatible NIS+ domains. Upgrading the last NIS clients to NIS+ allows you to take advantage of NIS+ security features.

  2. Adjust your security configuration.

    Once you have deleted all NIS clients, you can restart the NIS+ servers in standard mode and run nischmod on the NIS+ tables to change permission levels to eliminate the security hole caused by NIS compatibility. If you did not create credentials for NIS+ principals before, you must do that now. Restrict the access of unauthenticated principals.

  3. Establish miscellaneous evaluation and improvement programs.

    Evaluate operational procedures to determine which ones can be improved, particularly procedures used to recover from problems. Plan for new NIS+ releases and possible functional enhancements. Track the development of operating system components that might require new NIS+ tables. Look for automated tools that enable you to perform NIS+ administration functions more efficiently.

[ Previous | Next | Table of Contents | Index | Library Home | Legal | Search ]