[Image] NIS+ Frequently Asked Questions This document is archived at: http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html Date: July 30, 1999 Items with + indicate new items. * indicate changed items. 1.0 : About NIS+ __1.1 : An Explanation of the Basic NIS+ Objects 2.0 : Debugging NIS+ __2.1 : Authentication Problems __2.2 : Examining NIS+ Tables __2.3 : Using snoop __2.4 : Performance Problems 3.0 : How Tos __3.1 : How to Prepare Your Site for NIS+ __3.2 : How to Set Up a Root NIS+ Master __*3.3 : How to Set Up a NIS+ Client __3.4 : How to Set Up a Root NIS+ Replica __3.5 : How to Set Up a Subdomain NIS+ Master __3.6 : How to Set Up a Subdomain NIS+ Replica __*3.7 : How to Configure the Root Server for an IP Address Change __3.8 : How to Add a User to the Admin Group __3.9 : How to Change a NIS+ user passwd __3.10 : How to Change a NIS+ root passwd __3.11 : How to Administer NIS+ Credentials __3.12 : How to Administer NIS+ Groups __3.13 : How to Administer NIS+ Tables __3.14 : How to Examine NIS+ tables __3.15 : How to Modify NIS+ Tables __3.16 : How to Regularly Administer NIS+ __3.17 : How to Remove NIS+ __3.18 : How to define the printer table __3.19 : How to fix NIS+ server breaks with Unable to Authenticate NIS+ server __3.20 : How to promote a NIS+ root replica server to a root master server __3.21 : How to dump the cred table __+3.22 : How do I backup/recover NIS+ directory objects. 4.0 : Common problems. __4.1 : Miscellaneous Questions __4.2 : NIS+ Setup Problems __4.3 : User Login Problems __4.4 : NIS+ Lookup Problems 5.0 : Patches __5.1 : Solaris 2.3 NIS+ Patches __5.2 : Solaris 2.4 NIS+ Patches __5.3 : Solaris 2.5(.1) NIS+ Patches __5.4 : Solaris 2.6 NIS+ Patches __*5.5 : Solaris 7 NIS+ Patches 6.0 : References __*6.1 : Important Man Pages __*6.2 : Sunsolve Documents __6.3 : Sun Educational Services __*6.4 : Solaris Documentation __6.5 : Third Party Documentation __6.6 : RFCs ------------------------------------------------------------------------ 1.0: About NIS+ NIS+ stands for Network Information Service Plus. It was designed to replace NIS, and is a default naming service for Solaris. NIS+ can provide limited support to NIS clients via a YP-compatibility mode. NIS+ was mainly designed to address problems that NIS cannot address. One important thing to note is that there is no relation between NIS+ and NIS. The commands and the overall structure of NIS+ are different from NIS. In addition, some command syntax in NIS+ is different from the NIS commands. NIS+ was designed from scratch. NIS+ increases security by using an additional authentication method. Users will still have their standard LOGIN PASSWORD, will will give them access to the system. They will also have a SECURE RPC PASSWORD or NETWORK PASSWORD. This new password is necessary to actually access NIS+, and is what provides the new security. Usually, a user's LOGIN PASSWORD and NETWORK PASSWORD will be the same, and a user will automatically have access to all NIS+ functionality when they login with their login password. However, if they are different, a user will have to KEYLOGIN and type his network password to get access to NIS+. There are a huge number of programs related to NIS+. The most important ones are explained elsewhere in this document. All are listed in Section 7.1 you should consult the man pages for any additional information. Of special notes are the NIS+ daemons: RPC.NISD and NIS_CACHEMGR are the standard NIS+ daemons. You should see them running on every NIS+ server and client. 1.1: An Explanation of the Basic NIS+ Objects NIS+ objects are structural elements used to build and define the NIS+ namespace. There are 5 basic NIS+ objects. Objects are always seperated by dots. DIRECTORY OBJECTS: Similar to a UNIX system directory, in that it can contain one or more objects such as: table objects, group objects, entry objects or link objects. Directory objects form an inverted tree-like structure, with the root domain at the top and the subdomains branching downwards. They are used to divide namespace into the different parts. Each main directory object will contain that domain's org_dir and groups_dir directory objects. The org_dir directory objects contain table objects for that domain. The groups_dir directory objects contain NIS+ administrative group objects. Example of DIRECTORY OBJECTS: Sun.Com. org_dir.Sun.Com. groups_dir.Sun.Com. TABLE OBJECTS: Similar to NIS maps. They store a variety of network information. Tables may contain zero or more ENTRY OBJECTS. There are a total 17 predefined table objects. Tables can be administered with nistbladm or nisaddent command. Table entry objects form a row in the table and each row stores one record. Example of TABLE OBJECTS: Passwd.org_dir.Sun.Com. Hosts.org_dir.Sun.Com. Example of ENTRY OBJECTS: [name=user1],passwd.org_dir.Sun.Com. GROUP OBJECTS: These are NIS+ namespace administrative user groups. They permit controlled access rights to namespace modification on a group basis. They are administered with the nisgrpadm command. Example of GROUP OBJECTS: admin.groups_dir.Sun.Com. LINK OBJECTS: These are pointers to other objects. They are similar to symbolic links. They typically point to table or object entrys. Administered with the nisln command. 2.0 Debugging NISplus 2.0: Debugging NIS+ Before trying to debug a NIS+ problem, you should always make sure that you have the recommended patches installed on the system. In particular, the kernel patch should be at the current patch level, and all the systems have the same patch rev. 2.1: Authentication Problems Most of the problems in NIS+ are authentication related problems. Assuming that you are running rpc.nisd at security level 2 on your master server, you can use niscat to determine if a user is authenticated: %% niscat passwd.org_dir If the user can see the encrypted passwds, then the user is authenticated. If the user sees *NP* in place of encrypted passwds, then he does not have permission to read the passwd column. In this case, you could run 'keylogin' to try and reauthenticate the user. If that works, the user might need to run 'chkey' to sync his login and network passwords. If keylogin still does not authenticate the user, it is likely that his credentials have not been set up correctly. You can check that someone actually has credentials by examining the cred table: %% niscat cred.org_dir You can create credentials for a user with nisclient: %% nisclient -c username When having credential problems, also consider that it might be a problem with the credentials of the workstation as well. If known-good users fail on a specific workstation, you will probably want to try and set the workstation back up, as described in Section 3.3. 2.2: Examining NIS+ Tables Some NIS+ problems will be related to information missing from tables. You can examine the contents of tables with a variety of commands. niscat will output the entire contents of a table for you: %% niscat passwd.org_dir You can also examine the object properties of a table: %% niscat -o passwd.org_dir This can be very helpful, because it will show you if a table has weird permissions which may be restricting access. nismatch can also be used to find things in a table: %% nismatch -h joe passwd.org_dir niscat and nismatch both directly access the NIS+ tables. getent, on the other hand, will look up tables in the order defined in the /etc/nsswitch.conf. A typical getent command would be the following: %% getent passwd joe This would look up the user joe in passwd. In a typical environment, it would access files first, and then NIS+. If you find that getent and nismatch give you different answers, you should look at your nsswitch.conf. Perhaps a naming service that is listed earlier in your nsswitch.conf has different info. Alternatively, maybe NIS+ is not listed at all in your nsswitch.conf. 2.3: Using Snoop If you are having intermittent problems, snoop is often useful to debug them. To use snoop correctly, you must run it from an uninvolved machine. For example, if you have a client that is having intermittent problems with NIS+, you should run snoop on a machine on the same subnet as the problem client, but the machine must be neither the client nor any of the NIS+ servers: unrelated-machine# snoop problem-machine This will tell you about all of the packets going in and out of the problem-machine. You should look for NIS+ packets, taking careful notes of errors. If you are getting some type of intermittent errors, it is useful to see which Server your Client was talking with at the time of your problem. Possibly one of your Servers has bad or old information? 2.4: Performance Problems Some NIS+ problems may be related to performance. You might find NIS+ servers overloaded. You might get "NIS+ Server Unreachable" errors because your network is overloaded. The commands 'snoop' and 'netstat' may be used to examine such problems further, but Performance Tuning is beyond the scope of the help that SunService can provide. Sections 8.0 and 9.0 explain other places you can get help from within Sun. 3.0 How Tos 3.1: How to Prepare Your Site for NIS+ Before configuring NIS+ namespace you need to do initial planning including: verifying hardware and software requirements, deciding the name of the domain, determining security level and planning your domain hierarchy. In general you need a solaris 2.3 or higher Operating system. 32 to 64 MB of memory and about 128 MB of swap space is recommended for a medium to large domain. The size of /var/nis is recommended to be about 20 MB. All of these requirements can be found in the Administering Name Services Manual (see Section 7.4). The domainname for the root server should be at least two labels long. This means that the domain name "xyz." is not supported, but the domainname "xyz.com." is a correct domain name. Another thing to think about is security level. The default security level is 2. If you want a secure enviroment, then you should run NIS+ at security level 2. If you have SunOS client machines on the network, which are going to get served by the NIS+ server, then you need to run NIS+ in YP compatibility mode. You should also decide about the access rights you want to give to users and administrative group. Lastly, you should learn about imporatant NIS+ concepts such as the difference between the login passwd and the network passwd. It's very important to know this difference while troubleshooting authentication related problems. Once you are ready to begin configuring your domain, it is recommended that you use the quick startup scripts to configure NIS+ namespace. For example, to configure the root server use the nisserver script to configure clients use the nisclient script. These scripts are easy to use and reduce chances for errors. The following Sections outline the use of thse scripts. 3.2: How to Set Up a Root NIS+ Master To set up a root server, become the superuser on the root master, and use the nisserver script to build the root domain: root-server# nisserver -v -r -d domain_name (where domain_name is your NIS+ domain.) Afterwards, you will want to populate the NIS+ tables from a set of ASCII files. It is a good idea to create a seperate directory and then edit the files required to populate the tables there. For example, create a directory /var/tmp/nisfiles and copy the files from the /etc directory to /var/tmp/nisfiles, and then edit the files. You may wish to edit the passwd file, for example, because you only need the entries for the normal users in the NIS+ passwd table. Following is the list of standard NIS+ tables, which you may wish to include when you populate your maps (although it is not required that they all be included): aliases auto_home auto_master bootparams cred group hosts netgroups netmasks networks passwd protocols rpc services timezone To populate the tables, change to the directory where the edited files are, and then run the nispopulate script: root-master# cd /var/tmp/nisfiles root-master# nispopulate -v -F One important thing to note is the network passwd created in the credential table for all the users is "nisplus". This should be changed to something more secure. For normal users, every user needs to run keylogin and then do the chkey command and enter a new network passwd. It is highly recommended that login passwd and the network passwd be the same. In the NIS+ enviroment, login explicitly runs keylogin and so, if the network passwd is same as the login passwd, users don't have to do a seperate keylogin to authenticate. When the nispopulate is done, you should reboot your server. When it comes back up, you can verify that NIS+ is working correctly by running the standard NIS+ commands: root-master%% nisls root-master%% niscat passwd.org_dir *3.3: How to Set Up a NIS+ Client To set up a NIS+ client, first become root on the master server, and verify that NIS+ host table has an entry for the client. If it does not, use admintool to add it. Afterwards, run the nisclient script to create credentials for the client machine: root-master# nisclient -v -d domain_name -c client_machine (where domain_name is your NIS+ domain, and client_machine is the name of your new client.) Do not worry if nisclient tells you that the credentials already exist for your client_machine. Next, login to your client machine as root, and run nisclient to initialize it: client# nisclient -v -i -h master_machine -a master_ip -d domain_name (where master_machine is the name of your NIS+ master, master_ip is the IP address of your NIS+ master and domain_name is the name of your NIS+ domain.) client# cp /etc/nsswitch.nisplus /etc/nsswitch.conf (You may need to make a change to the hosts line in nsswitch.conf if you use DNS.) 3.4: How to Set Up a Root NIS+ Replica After your root replica has been set up as a client system (see Section 3.3), start the NIS+ server daemon: root-replica# rpc.nisd Then, you can execute the nisserver command on the root-master: root-master# nisserver -v -R -d domain_name -h replica_machine (where domain_name is your NIS+ domain and replica_machine is the name of your root-replica.) Finally, run nisping on the master server to propagate the tables to the replica server: root-master# nisping domain_name. root-master# nisping org_dir.domain_name. root-master# nisping groups_dir.domain_name. (where domain_name is your NIS+ domain.) 3.5: How to Set Up a Subdomain NIS+ Master The subdomain server must already be setup as a client of the domain above it (see Section 3.3). This may be the root domain, or some subdomain. After it is, you should start rpc.nisd: subdomain-master# rpc.nisd Then, you should login to the master of the domain above your current domain, and execute nisserver (root-master is used in this example, but this could also be some higher subdomain-master): root-master# nisserver -v -M -d subdomain_name -h subdomain_master (where subdomain_name is the name of your new NIS+ subdomain, and subdomain_master is the name of your Subdomain master.) You will then want to populate the NIS+ tables for your new Subdomain. This is done on your subdomain master, in a similar manner to that described in Section 3.2: subdomain-master# cd /var/tmp/nisfiles subdomain-master# nispopulate -v -F Afterwards, reboot your new subdomain master. 3.6: How to Set Up a Subdomain NIS+ Replica The same procedure as is described in Section 3.4, should be used to set up a Subdomain Replica. However, the commands will be run on the subdomain-master, not the root-master. *3.7: How to Configure the Root Server for an IP Address Change The assumptions here are: - Your NIS+ root domain is called "root.dom". - The root server is called "master" and has an address of 1.2.3.4. - You want to change the IP address of the root server to 4.3.2.1. - You have one replica called "replica", with an address of 1.2.3.5 - You want to change the IP address of the replica to 4.3.2.2 Follow these steps: 1. For all the NIS+ servers, add entries for their new IP addresses. The following commands add the master's and replica's new IP addresses. nistbladm -a addr=4.3.2.1 name='"master"' cname='"master"' hosts.org_dir nistbladm -a addr=4.3.2.2 name='"replica"' cname='"replica"' hosts.org_dir 2. Use nisupdkeys to update the IP addresses in the directory objects with these commands: (You must have nisplus first for the hosts line in /etc/nsswitch.conf) /usr/lib/nis/nisupdkeys -a groups_dir.root.dom. /usr/lib/nis/nisupdkeys -a org_dir.root.dom. /usr/lib/nis/nisupdkeys -a root.dom. Note: You will need to do this for any other directory object hosted on the machine. 3. Start up a second logical interface on each NIS+ server with the new IP address. On the master, run this command: ifconfig le0:1 4.3.2.1 netmask + broadcast + -trailers up On the replica, run this command: ifconfig le0:1 4.3.2.2 netmask + broadcast + -trailers up 4. Push the new directory objects to all the replica servers with this command: /usr/lib/nis/nisping root.dom. /usr/lib/nis/nisping groups_dir.root.dom. /usr/lib/nis/nisping org_dir.root.dom. 5. Wait for the time-to-live of all the directory objects to expire. This is REALLY important. Do not skip this step. Typically the time-to-live is 12 hours, so wait for 12 hours. You can check time-to-live with the command: niscat -o root.dom. groups_dir.root.dom. org_dir.root.dom. You can change the time-to-live on the directory objects to speed the process up. To change the time-to-live of an object to 1 hour use the command nischttl. nischttl 1h root.dom. nischttl 1h groups_dir.root.dom. nischttl 1h org_dir.root.dom. If you are going to adjust the time-to-live for the object you will need to wait for 12 hours to propagate the new time-to-live. 6. To keep a completely transparent service, set up one ormore systems to act as a gateway between the two logical networks. To do this on one system, follow these steps: 7. For each client, follow these steps: a. Edit the hosts.org_dir table entry to reflect the new IP address. b. Edit the /etc/hosts file. c. Reboot the client. 8. Remove the old IP address entries for the NIS+ root servers from the hosts map, so that only the new IP entries remain by following these steps: a. Update the IP addresses in the directory objects with these commands: /usr/lib/nis/nisupdkeys -a groups_dir.root.dom. /usr/lib/nis/nisupdkeys -a org_dir.root.dom. /usr/lib/nis/nispupkeys -a root.dom. b. Propagate the changes to all replicas with these commands: /usr/lib/nis/nisping groups_dir.root.dom. /usr/lib/nis/nisping org_dir.root.dom. /usr/lib/nis/nisping root.dom. c. Wait for the time-to-live to expire (usually 12 hours) so that the old server IP address information is cleared from client caches. 9. Once all the clients are done, follow these steps: a. ifconfig the old (logical) interfaces on the NIS+ servers down by running, for example: ifconfig le0 down. b. Remove the old entries from the host table. c. Edit the /etc/hosts files. d. On the system on which you started the in.routed, turn it off again and reset ip_forwarding to its old value. 3.8: How to Add a User to the Admin Group In your default setup, only root on your master machine will be able to make modifications to most of your NIS+ maps. You will probably want to extend these permissions to all of the system administrators. This is typically done by putting all of the system administrators into the admin group: # nisgrpadm -a admin.domain_name. joe # nisgrpadm -a admin.domain_name. liz The above command will give joe and liz the ability to modify most NIS+ tables from their own accounts. This can give considerable privilege, so you should make sure that joe and liz are trusted, and also that their accounts are secure. 3.9: How to Change a NIS+ user passwd The passwd for a normal user can be changed by them running the nispasswd command: %% nispasswd This updates the passwd in the passwd table, and also updates the credential table. Root can change passwds for users by running: # nispasswd user_name However, this procedure should NEVER be used for changing the root passwd. 3.10: How to Change a NIS+ root passwd To change a root passwd, you MUST use the following procedure. First, issue the passwd command, and supply new passwd: # passwd This will change the passwd in the local /etc/passwd file. Then, run chkey -p and enter the new network passwd: # chkey -p Finally, do keylogin -r to update /etc/.rootkey file with the new private key for the server: # keylogin -r This changes the private key for the server, while the public key remains the same. This is necessary because clients use server's public key for authentication. If you use any other method for updating your root passwd, you can totally mess up your NIS+ domain. 3.11: How to Administer NIS+ Credentials The nisaddcred command can be used to create, update and remove LOCAL and DES credentials. To create or update credentials for another NIS+ principal: %% nisaddcred -p uid -P principal-name local %% nisaddcred -p rpc-netname -P principal-name des The rpc-netname is unix.uid@domain_name for a user, and unix.hostname@domain_name for the root user on a host. Note that these domainnames do NOT contain a trailing dot, unlike most NIS+ commands. The principal-name is name.domain_name., where name can be user name or a hostname. For example, joe (uid 555) in the example.com domain has the following names: principal-name: joe.example.com. rpc-netname: unix.555@example.com While root on the machine testhas the following names: principal-name: test.example.com. rpc-netname: unix.test@example.com A few caveats: you can only create DES credentials for a client workstation. DES credentials may only be created in the client's home domain. However, you can create LOCAL credentials for a client user in other domains. To remove credentials: %% nisaddcred -r principal-name 3.12: How to Administer NIS+ Groups The following commands may all be used to administer NIS+ groups. Be aware that NIS+ groups are not the same thing as normal UNIX groups. You can list the object properties of a group with niscat: %% niscat -o group-name.groups_dir.domain_name. The nisgrpadm command creates, delets and performs miscellaneous administartion operations on the nis+ groups. To create a group: %% nisgrpadm -c group-name.domain_name. The group you cretae will inherit all the object properties specified in the NIS_DEFAULTS variable. You can view the defaults using the nisdefaults command: root-master# nisdefaults prinicipal name : master.domain_name domain name : domain_name Host Name : master.domain_name Group Name: Access Rights : ----rmcdr---r--- Time to live :12:0:0 Search Patch : domain-name To delete a group: %% nisgrpadm -d group-name.domain_name. To list the group members: %% nisgrpadm -l group-name.domain_name. To add members to a NIS+ group: %% nisgrpadm -a group-name member To remove members from a NIS+ group: %% nisgrpadm -r group-name member To determine if a member belongs to a NIS+ group: %% nisgrpadm -t group-name member 3.13: How to Administer NIS+ Tables The nistbladm command is the primary NIS+ table administration utility. With this command, you can create, modify or delete tables and table entries. To create a table you must have create rights to the directory under which you will create. To delete a table you must have a destroy rights to the directory. To modify a table, or to add, change or delete the entries you must have modify rights to the table or the entries. Table column can have following characteristics: S Searchable I case insensitive C encrypted To create a table: %% nistbladm -c table-type column-spec .... table-name For example, to create a table of type 'computers' and of name 'computers.example.com.', with two columns, 'name' and 'model', which are both searchable, you would use the following command: %% nistbladm -c computers name=S model=S computers.example.com. (assuming your domain_name is example.com) To delete a table: %% nistbladm -d table-name For example, to delete your computers table, you would use the following command: %% nistbladm -d computers.example.com. For more info about adding entries or modifying entires, refer to the nistbladm man page. 3.14: How to Examine NIS+ tables The niscat command displays the contents of NIS+ tables. To display the object properties of a table: %% niscat -o table-name Or: %% niscat -o entry To display the contents of a table: %% niscat -h table-name 3.15: How to Modify NIS+ Tables NIS+ tables may be modified in a number of ways. One note for all of these mesthods is that a NIS+ principal must be a member of the admin NIS+ group for them to make modifications to most tables (see Section 3.8). The best method is to use the admintool GUI to modify them. The only downsides to this approach are: admintool requires X to be running not all the standard tables are available through admintool and new tables will never be available through admintool. If you can not use admintool to modify a table, nisaddent is the best alternative. The nisaddent command loads information from text files or from NIS maps into NIS+ tables. It can also dump the contents of the NIS+ tables back to text files. The following options are used along with the nisaddent command: -a append: add the contents of the source to the table -r replace: substitute contents of the source for the contents of the table -m merge: merge the contents of the source with the contents of the table. -d dump : dump the contents of the table to stdout (With no -a, -r or -m options, the default is REPLACE) You can put new entries into a file, and then merge those changes in: %% nisaddent -m -f filename table-type For example: %% nisaddent -m -f /etc/passwd passwd Or, you could dump a table, make changes and then replace the copy of the table in NIS+ For example: %% nisaddent -d passwd > /tmp/passwd %% vi /tmp/passwd %% nisaddent -r -f /etc/passwd passwd If you do not want to use nisaddent, your final option is to use nistbladm to directly modify the table. This can be fairly complex. Examine the nistbladm man page for more information on how to do so. 3.16: How to Regularly Administer NIS+ Depending on the updates one performs in the namespace, it is a good idea to frequently perform nisping -C so that log files gets written to the disk. You may wish to put this into a cron tab on your root-master server, to make sure that it is executed daily. Another important NIS+ administration task is to regularly backup /var/nis, to make sure that you can recover in the case of a massive failure. 3.17: How to Remove NIS+ If you wish to remove NIS+, you should run the following commands on all of your NIS+ machines: # cp /etc/nsswitch.files /etc/nsswitch.conf # /etc/init.d/rpc stop # rm -f /etc/.rootkey # rm -rf /var/nis/* # /etc/init.d/rpc start It is suggested that you start with the clients, and do the servers last. 3.18: How to define the printer table in NIS+ Run the following command, as root, to set up the NIS+ printers table definition: # nistbladm -c -D access=n+r,o+rmcd,g+rmcd,w+r printers \ printer_name=S,o+rmcd,g+r,w+r printer_host=S,o+rmcd,g+r,w+r \ description=,o+rmcd,g+r,w+r printers.org_dir.`domainname`. Once you have set up this definition, you can confirm the permissions are set properly: # niscat -o printers.org_dir Object Name : printers Owner : ppp.hans.com. Group : admin.hans.com. Domain : org_dir.hans.com. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Object Type : TABLE Table Type : printers Number of Columns : 3 Character Separator : Search Path : Columns : [0] Name : printer_name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ----rmcdr---r--- [1] Name : printer_host Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ----rmcdr---r--- [2] Name : description Attributes : (TEXTUAL DATA) Access Rights : ----rmcdr---r--- After this, Admintool or the nisaddent command can be used to populate the printers table. 3.19: How to fix NIS+ server breaks with Unable to Authenticate NIS+ server Kill and restart rpc.nisd at security level 0: ps -ef | grep rpc.nisd kill /usr/sbin/rpc.nisd -r -S 0 Use keylogout to remove roots key: keylogout -f Add root's key and push it into the directories: nisaddcred des ps -ef | grep keyserv kill nisupdkeys `nisdefaults -d` nisupdkeys org_dir.`nisdefaults -d` nisupdkeys groups_dir.`nisdefaults -d` /usr/sbin/keyserv Make sure the changes have been propagate: /usr/lib/nis/nisping `nisdefaults -d` /usr/lib/nis/nisping org_dir.`nisdefaults -d` /usr/lib/nis/nisping groups_dir.`nisdefaults -d` Apply /usr/lib/nis/nisping to any other directories that you may have created. Kill & restart NIS at security level 2: ps -ef | grep rpc.nisd kill /usr/sbin/rpc.nisd -S 2 3.20: How to promote a NIS+ root replica server to a root master server NOTE: In the following examples, indicates the name of the old master server, indicates the name of the old replica server, and `domainname` indicates the domainname. Items such as indicate the pid for the given process, obtained with the following command: ps -ef | grep All other punctuation should be typed as written. 1 - Create master's objects for replica: On Master machine: # nsmkdir -m groups_dir.`domainname`. # nsmkdir -m org_dir.`domainname`. # nsmkdir -m `domainname`. 2 - Copy root.object of master On Replica machine: # rcp :/var/nis/root.object /var/nis/ or for greater than Solaris 2.5 # rcp :/var/nis/root.object /var/nis/ Move root.object from master /var/nis/[|data] directory to somewhere else (don't delete it as you may need to reverse the process if it goes wrong) 3 - Kill rpc.nisd and nis_cachemgr on both master and replica: # kill 4 - Restart rpc.nisd and nis_cachemgr on the new replica server: On new replica machine: # /usr/sbin/rpc.nisd -S 0 # /usr/sbin/nis_cachemgr -i 5 - Access the domainname directory and verify that the old replica is now the master: On new master machine: # nisshowcache -v # niscat -o groups_dir.`domainname`. # niscat -o org_dir.`domainname`. # niscat -o `domainname`. 6 - If the contents of the cache still shows the old master server to be the old master, do the following on the new master: # nsmkdir -m groups_dir.`domainname`. # nsmkdir -m org_dir.`domainname`. 7 - Change the ownership of the directories # nischown groups_dir.`domainname`. # nischown org_dir.`domainname`. 8 - Change the ownership of all the tables within the directories # for tables in `nisls org_dir | grep -v org_dir` > do > nischown $tables.org_dir > done # for tables in `nisls groups_dir | grep -v groups_dir` > do > nischown $tables.groups_dir > done 9 - Check the tables and directory structures are owned by the correct newmaster # niscat -o org_dir # niscat -o hosts.org_dir etc... 10 - Remove the old replica from replicating the directory structures # nisrmdir -s groups_dir.`domainname`. # nisrmdir -s org_dir.`domainname`. # nisrmdir -s `domainname`. 11 - Checkpoint the domain # nisping -C groups_dir.`domainname`. # nisping -C org_dir.`domainname`. # nisping -C `domainname`. 12 - If they are all now owned and replicated by the correct machine, stop and restart rpc.nisd in security level 2 # kill # /usr/sbin/rpc.nisd # /usr/sbin/nis_cachemgr -i 13 - Check as users and root that all is well. 14 - On the old master, clear out the old info and make it a client of the domain Remove everything from /var/nis except NIS_COLD_START and NIS_SHARED_DIRCACHE. Put the name and IP number of the new master in the /etc/hosts file. # nisinit -c -H 15 - Make the old master a replica of the domain On the new replica, start rpc.nisd. On the master # nismkdir -s groups_dir.`domainname`. # nismkdir -s org_dir.`domainname`. # nismkdir -s `domainname`. # nisping -C groups_dir.`domainname`. (note: server busy messages are # nisping -C org_dir.`domainname`. (generated because the previous # nisping -C `domainname`. (command has not finished. 16 - On each client, kill nis_cachemgr # kill 17 - On each client, get a new coldstart file from the new master server # nisinit -c -H 18 - On each client, restart nis_cachemgr # kill # /usr/sbin/nis_cachemgr -i 3.21: How to dump the cred table You need to dump the cred table in two parts. 1 - To dump the DES creds: nisaddent -d -t cred.org_dir publickey > des_cred_table 2 - To dump the local creds: nisaddent -d -t cred.org_dir netid > local_cred_table +3.22: How do I backup/recover NIS+ directory objects. Starting with Solaris 2.6 there are two new commands. nisbackup and nisrestores. These two command are used to backup NIS+ directory objects on a NIS+ master server. nisbackup will backup the directory objects passed to it to a directory. This will backup the directory objects listed to /nisbackups nisbackup /nisbackups root.dom. org_dir.root.dom. groups_dir.root.dom. This will restore all directory objects in /nisbackups nisrestore -a /nisbackups 4.0 Common Problems 4.1: Miscellaneous Questions Q1: What are the main features of NIS+? Q2: What new functionality does NIS+ have? Q3: What are the differences between NIS and NIS+? A: NIS name space is a flat namespace, which means that it does not support subdomains. Under NIS, only one domain is accesible from a given host. In NIS+, the namespace is hierarchical. This hierarchical structure is similar to the UNIX filesystem structure. Since the NIS+ namespace is hierarchical, it can be configured to conform with the logical hierarchy of the organization. This means that you can create subdomains for different levels of organizations. In NIS, even for a small change in the map, the master server needs to push the whole map to the slave servers. Whereas, in NIS+, the database updates are incremental. This means that only changes in the map are replicated to replica servers. Therefore, NIS+ database updates are more efficient and less time consuming. Another important difference between NIS and NIS+ is server binding. In NIS, clients are hard bound to a specific server. During the bootup time, the ypbind process on the client side binds to a specific server. However, the NIS+ client library is not a seperate process. In NIS, the ypwhich command can tell you to which specific server the client is bound to, but that is not possible in NIS+. In other words, the binding in nis+ is soft binding. NIS maps can be searched by only one predefined searchable column. NIS+ tables allow more than one searchable columns. NIS supports UNIX groups and netgroups. NIS+ also supports the concept of NIS+ group. One or more NIS+ users can be grouped together into a NIS+ group. Multiple NIS+ groups can be defined, each with different access and modification rights to the NIS+ namespace. NIS+ also has much improved security: NIS does not support authentication, authorization and secure RPC, whereas NIS+ supports authentication, authorization and secure RPC. Q: What is my network passwd? A: In most cases, your network passwd should be the same as your login passwd. When NIS+ is just getting setup, network passwds are often set to 'nisplus'. Q: Why can't I have machines and users with the same name? A: All machines and users must have credentials created for them. If you have a machine and a user with the same name, only one of them will be able to have credentials. In case of a naming conflict of this sort, you should change the machine's name you may have to recreate credentials for the user and machine afterwards: %% nisclient -c user %% nisclient -c machine 4.2: NIS+ Setup Problems Q: Why does nisserver fail when I run it, as described in Section 3.4? A: If for some reason the nisserver script fails, check the error message. It will give some ideas about the failure. Another option is to do the configuration manually using nisinit, and nissetup, as is described in the Name Services Administration Guide. This will give an idea about which step the script is failing in. This can help to diagnose the problem better. If the nisinit -r step hangs, then check if you are running DNI. The DNI installation modifies /etc/netconfig file with this line: nsp tpi_cots_ord - decnet nsp /dev/nsp /usr/lib/straddr.so If you comment this line out and then run the script again, it will work correctly. 4.3: User Login Problems Q: Why do I get the following error on login: "Password does not decrypt secret key for ..." A: This means that the user's login password and network password do not match. After login, the user must run keylogin to get their NIS+ credentials: %% keylogin They will have to type their NIS+ network password at the keylogin prompt. This may very well be 'nisplus' if the user is logging in for the first time. Afterwards, the user should run chkey, to synch his login and network passwds: %% chkey Q: Why do I get the following error on login: "/usr/bin/passwd: does not exist" "Connection closed by foreign host." A1: This can be the result of selecting "cleared until first login" in admintool, when you initially create a user. You should instead select a normal password for a user when you create his account. A2: If you are trying to use password aging, you must install the password agin point patch, as noted in Section 5.0. Q: Why can't I log in via xdm? A: This is a known bug. Sections 5.3 and 5.4 list the patches for this problem. 4.4: NIS+ Lookup Problems Q: Why do I get inconsistant results when I do certain NIS+ lookups? A: In NIS+, the server binding is a soft binding. That is, every query may be accessing a different server. Therefore, if a replica is not in sync with the master, clients will get inconsistant information for every query. When you get inconsistant information for queries run the snoop command (see Section 2.3) to find out which server is providing the incorrect information. 5.0 Patches 5.0: Patches The following is the list of all of the NIS+ patches for 5.3 and 5.4. If you are having NIS+ problems, installing the patches is a good place to start, especially if you recognize the general symptoms noted below. In order for a machine to be stable, all of the recommended patches should be installed as well. The list of recommended patches for your operating system is available from sunsolve1.sun.com. 5.1: Solaris 2.3 NIS+ Patches 101318 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd) 101384 SunOS 5.3: Admintool Jumbo patch 101582 SunOS 5.3: POINT PATCH: Password aging & NIS+ don't work (together) 101736 SunOS 5.3: nisplus patch 102447 OpenWindows 3.3: xdm cannot be used on NIS+ networks 103269 SunOS 5.3: nissetup default permissions not secure enough 5.2: Solaris 2.4 NIS+ Patches 101945 SunOS 5.4: jumbo patch for kernel 102294 OpenWindows 3.4: xdm cannot be used on NIS+ networks 102336 SunOS 5.4: POINT PATCH: 1091205 - Password aging & NIS+ don't work 103270 SunOS 5.4: nissetup default permissions not secure enough 101974 SunOS 5.4_x86: libnsl, nistbladm & ypbind fixes 5.3: Solaris 2.5(.1) NIS+ Patches 103066 SunOS 5.5: rpc.nisd hangs in write(2) 103187 SunOS 5.5: libc, libnsl, libucb, nis_cachemgr and rpc.nisd 103188 SunOS 5.5_x86: libc, libnsl, libucb, nis_cachemgr and rpc.nisd patch 103266 SunOS 5.5: nissetup default permissions for password table not secure 104968 SunOS 5.5.1: chkey and newkey patch 103612 SunOS 5.5.1: libc libnsl libucb nis_cachemgr and rpc.nisd patch 103613 SunOS 5.5.1_x86: libc, libnsl, libucb, nis_cachemgr andrpc.nisd patch 104969 SunOS 5.5.1_x86: chkey and newkey patch 5.3: Solaris 2.6 NIS+ Patches 105562 SunOS 5.6: chkey and keylogin patch 105563 SunOS 5.6_x86: chkey and keylogin patch 105564 SunOS 5.6: /kernel/misc/rpcsec patch 105565 SunOS 5.6_x86: /kernel/misc/rpcsec patch 105401 SunOS 5.6: libnsl and NIS+ commands patch 105402 SunOS 5.6_x86: libnsl and NIS+ commands patch 5.4: Solaris 7 Patches 107215 SunOS 5.7: /usr/sbin/rpc.nisd patch 6.0 References 6.1: Important Man Pages chkey keylogin newkey nis nis_cachemgr nisaddcred niscat nisaddent nischgrp nischown nischttl nisclient nisdefaults nisgrep nisgrpadm nisinit nislog nisls nismatch nismkdir nisping nispopulate nisrm nisrmdir nisserver nistbladm nisudpkeys rpc.nisd nisbackup nisrestore 6.2: Sunsolve Documents There are a number of Sunsolve documents concerning NIS+ To access these documents you must have a sunsolve id. 6.2.1: FAQs 1012 NIS+ questions 6.2.2: Infodocs 2216 NIS+ questions 11742 How to convert a NIS+ root replica server to a root master 17749Procedure to change the root users password on NIS+ machines 6.2.3: SRDBs 5816 fully qualified hostnames with NIS+ 5874 nis+ database recovery 6285 change of root passwd on NIS+ server breaks authenticat 6487 differences between NIS and NIS+ 6640 why does NIS+ require passwords 6616 is it possible to revert to NIS 7202 cannot change NIS passwords served by NIS+ servers 10448 Changing the NIS+ master server. 10941 NIS+ error messages 10951 NIS+ servers unreachable 11728 Changing a NIS+ server's IP address. 11742 How to convert a NIS+ root replica server to a root master server 14994 Changed root master's IP address in AdminSuite, nis+ credentials are now bad. 18603 NIS+ master and replica are out of sync now what? 19155 Rebuilding NIS+ root master credentials 6.3: Sun Educational Services NIS+ concepts and administration offered by SUNED (contact 1-800 number to get more information) *Solaris 2.X NIS+ Administration with Workshop 6.4: Solaris Documentation Name Services Administration Guide, part #801-6633-10 Name Services Configuration Guide, part #801-6635-10 Online docs for NIS+ are availble via docs.sun.com 6.5: Third Party Documentation All About Administering NIS+, by Rick Ramsey, Prentice Hall ISBN 0-13-309576-2 6.6: RFCs There are no RFCs on NIS+. ------------------------------------------------------------------------ Send additions/corrections to: Ray W. Hiltbrand (Ray.W.Hiltbrand@Eng.Auburn.EDU) This document is archived at: http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html This was generated by a perl filter. Filtered by: Ray W. Hiltbrand