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:
Set up the namespace with full DES authentication, even if the domains will operate in NIS-compatibility mode. Use the NIS+ scripts described in NIS+ Setup Scripts to set up your namespace. See NIS+ Namespace and Structure for more explanation of NIS+ structure and concepts. Then perform the following steps:
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.)
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.
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.
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.
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.
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.
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.
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+.
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.
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.
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.
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.
Verify that requests for information can pass between the namespaces without difficulty.
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.
Test all three namespaces together to make sure the added links do not create problems.
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.
NISPLUS program=/usr/lib/security/NISPLUS
Track progress against your plan and all serious complications not anticipated in the planning stages. Communicate your status to interested parties.
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.
Once the implementation is complete, test to see that NIS+ is working correctly.
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.
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.
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.
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.
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 AIX components that might require new NIS+ tables. Look for automated tools that enable you to perform NIS+ administration functions more efficiently.