Here is the response from all the managers. Thanks a lot for the responses. -Venkatesh From: Adrian Stovall www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html www.muc.de/~ralfl/nisplus/faq.html or go to www.google.com and type in "NIS+ FAQ" HTH From: Daniel Tate You may have already heard this suggestion. 1: Buy some Tylenol. Extra strength, gelcaps. 2: Expense this book, if you can: http://www.amazon.com/exec/obidos/ASIN/0133095762/qid=998590191/sr=2-1/ref=aps_sr_b_1_1/002-4724014-8248843 I'm not sure anyone on the planet knows everything about NIS+.. IMHO, it's rather sloppy. There are a few NIS+ FAQ's laying around.. http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html http://docs.sun.com/ab2/coll.47.8/NISQSTART/ http://docs.sun.com/ab2/coll.47.8/NETNAME From: gcarr@lanl.gov (Gary Carr) http://docs.sun.com has a full set of Sol 8 documentation. There is NIS+ info scattered throughout the System Administration documentation. I'e found "Solaris Naming Setup and Configuration Guide", and "Solaris Naming Administration Guide" the most useful. http://www.eng.auburn.edu/users/rayh/solaris/NIS+_FAQ.html is an online FAQ for NIS+. http://www.sunsolve.com/ has quite a few "Info Docs" on NIS+. Info Doc 11988, "NIS+ PSD/FAQ" is a good general reference. I don't know if you can get to Info Docs if you cannot login to the site. I think there was a fairly extensive set of notes on NIS+ sent to this mailing list at one time, I've misplaced my copy of it, but you might try the archives. There are, of course, the man pages for all the nis... commands. This has everything !!!!!!! From: "Karl Vogel" --------------------------------------------------------------------------- #!/bin/sh # Cleanly repopulate the hosts and netgroup tables. # Running nispopulate isn't enough if we delete entries from either. PATH=/bin:/usr/sbin:/usr/lib/nis NIS_PATH=org_dir.$:$ export PATH NIS_PATH umask 027 tag=`basename $0` # don't forget the trailing dot domain="YOUR.DOMAIN.GOES.HERE." alltables="hosts netgroups" yes='y y' for table in $alltables do clear="nistbladm -R $table" populate="nispopulate -F -p /etc -d $domain $table" echo "running $clear ..." logger -t $table "$clear" $clear echo "running $populate ..." logger -t $table "$populate" echo "$yes" | $populate done logger -t $tag "checkpointing NIS logs" nisping -C org_dir logger -t $tag "done" exit 0 --------------------------------------------------------------------------- INFODOC ID: 11988 SYNOPSIS: NIS+ PSD/FAQ DETAIL DESCRIPTION: SunService Tip Sheet for SUN NIS+ Revision: 1.3 Date: May 24, 1996 Mail to: support@network.East.Sun.COMMail to: support@network.East.Sun.COM 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: Common 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 4.0: Some Frequently Asked Questions 4.1: Miscellaneous Questions 4.2: NIS+ Setup Problems 4.3: User Login Problems 4.4: NIS+ Lookup Problems 5.0: References 5.1: Important Man Pages 5.2 Sunsolve Documents 5.3 Sun Educational Services 5.4: Solaris Documentation 5.5: Third Party Documentation 5.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 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 separated 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 entries. Administered with the nisln command. 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 passwords, then the user is authenticated. If the user sees *NP* in place of encrypted passwords, 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 Common 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 environment, 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 important 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 these 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 separate 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 netmasks auto_home networks auto_master passwd bootparams protocols cred rpc group services hosts timezone netgroups 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+ environment, login explicitly runs keylogin and so, if the network passwd is same as the login passwd, users don't have to do a separate 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.) 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 Unfortunately, there is no easy way to configure the root server again when the IP address is changed. This is because the clients maintain the server's IP address in their cold start file, and the server has the old IP address in its cache. You must totally reinitialize the Root Server for an IP address change. The best way to do this is first dump the NIS+ tables to ASCII files using the nisaddent command: root-master# cd /var/tmp/nisfiles root-master# nisaddent -d aliases > aliases root-master# nisaddent -d bootparams > bootparams root-master# nisaddent -d ethers > ethers root-master# nisaddent -d group > group root-master# nisaddent -d hosts > hosts root-master# nisaddent -d netgroup > netgroup root-master# nisaddent -d netid > root-master# nisaddent -d netmasks > netmasks root-master# nisaddent -d networks > networks root-master# nisaddent -d passwd > passwd root-master# nisaddent -d protocols > protocols root-master# nisaddent -d publickey > publickey root-master# nisaddent -d rpc > rpc root-master# nisaddent -d services > services root-master# nisaddent -d shadow > shadow root-master# nisaddent -d timezone > timezone root-master# nisaddent -d -t auto_home.org_dir key-value > auto_home root-master# nisaddent -d -t auto_master.org_dir key-value > auto_master Then, you must clean out old NIS+ info: root-master# cp /etc/nsswitch.nisplus /etc/nsswitch.conf root-master# /etc/init.d/rpc stop root-master# rm -f /etc/.rootkey root-master# rm -rf /var/nis/* root-master# /etc/init.d/rpc start And finally, you can reconfigure your NIS+ server, as described in Section 3.2. 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 password in the passwd table, and also updates the credential table. Root can change passwords 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 test has 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, deletes and performs miscellaneous administration operations on the nis+ groups. To create a group: % nisgrpadm -c group-name.domain_name. The group you create will inherit all the object properties specified in the NIS_DEFAULTS variable. You can view the defaults using the nisdefaults command: root-master# nisdefaults principal 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 entries, 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 methods 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/hosts hosts Or, you could dump a table, make changes and then replace the copy of the table in NIS+ For example: % nisaddent -d hosts > /tmp/hosts % vi /tmp/hosts % nisaddent -r -f /etc/hosts hosts There is a special case to modify the password table using nisaddent. Example: % nisaddent -d passwd > /tmp/passwd % nisaddent -d shadow > /tmp/shadow % vi /tmp/passwd % nisaddent -r -f /tmp/passwd passwd % nisaddent -m -f /tmp/shadow -t passwd.org_dir shadow The reason that you must do the passwd table this way is that is you don't reload all the shadow information your passwords will be lost. 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/* # rm -rf /etc/defaultdomain # /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. 4.0 Some Frequently Asked Questions 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 accessible 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 separate 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 passwords 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 synchronize his login and network passwords: % chkey -p They have to again type their NIS+ network password (nisplus) and then their login password (password typed in when logging into system) 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 aging 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 inconsistent 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 inconsistent information for every query. When you get inconsistent information for queries run the snoop command (see Section 2.3) to find out which server is providing the incorrect information. 5.0 References 5.1: Important Man Pages chkey nisgrpadm keylogin nisinit newkey nislog nis nisls nis_cachemgr nismatch nisaddcred nismkdir niscat nisping nisaddent nispopulate nischgrp nisrm nischown nisrmdir nischttl nisserver nisclient nistbladm nisdefaults nisudpkeys nisgrep rpc.nisd 5.2: Sunsolve Documents There are a number of SunSolve documents concerning NIS+ The ones listed below either contain some additional information not in this document, or reference rare problems, or rare how-tos. 5.2.1: FAQs 1012 NIS+ questions 5.2.2: Infodocs 2216 NIS+ questions 11742 How to convert a NIS+ root replica server to a root master 5.2.3: SRDBs 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. --------------------------------------------------------------------------- Date: Thu, 31 Jul 1997 10:21:35 -0700 (PDT) To: sun-managers@ra.mcs.anl.gov Subject: SUMMARY: NIS+ tips Message-ID: From: Stuart Kendrick I've been wrestling with NIS+ for a couple years now, and the sun-managers list has been helpful during the steep parts of my learning curve. Thank you to the many correspondents who have helped me. Here is a compilation of what I know about NIS+; I hope this helps others. This is the document to which I refer whenever I need to refresh my memory about how I've constructed our NIS+ space and how to monitor it, manage it, trouble-shoot it. My understanding is incopmlete, please be advised that my notes may simply be wrong, incorrect, bogus. This is not a clean document, merely notes to myself. Take it all with salt. Corrections, insights, suggestions welcome. Special thanks to Marc Gibian and Martin Trampler for their thorough explanations. --sk Stuart Kendrick Network Services FHCRC NIS+ in CNS Overview Support Building the NIS+ domain from scratch Changing your password under NIS+ Fixing Credential Problems Adding/Modifying Users Netgroups Administering the NIS+ tables Tuning the NIS+ tables Restoring NIS+ after tragedy Maintaining the NIS+ space Troubleshooting Removing a NIS+ client Removing a NIS+ replica Removing the NIS+ space entirely Useful NIS+ scripts Sun NIS+ documents Overview This document is a compilation of notes I made to myself while I learned NIS+. I started working with NIS+ under Solaris 2.3. Under Solaris 2.4. And under Solaris 2.5.1 (I skipped 2.5). I would describe NIS+ as broken until 2.5.1. It is possible that patches delivered since have fixed the brokenness I discovered under 2.3 and 2. 4. At points within this document, I instruct the operator to "wait a few minutes". Alternatively, one can type "nisping org_dir" instead; this command instructs nis_cachemgr to propagate changes immediately. Support Read all the NIS+ FAQs on SunSolve. Subscribe to the sun-managers list. Make extensive use of your Sun Service contract. Building the NIS+ domain from scratch In this example, I assume that the root master is rmaster. Note that in NIS+ the absence or inclusion of a trailing dot is important. Whenever messing with NIS+, keep a separate window to that box open with a "tail -f /var/log/syslog" running. Create the root master On rmaster: -Create a file called /etc/defaultdomain containing the single line "fhcrc.org" -reboot. -nisserver -r -v -d fhcrc.org. -g admin.fhcrc.org. -Edit /etc/nsswitch.conf and modify as necessary: # /etc/nsswitch.conf 7/10/97 --sk # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. # The next two lines enable the use of netgroups passwd: compat passwd_compat: nisplus # This is the standard nsswitch.conf line, which does not support netgroups # Files *must* precede nisplus #passwd: files nisplus # I don't currently include the standard groups in NIS+, so "files" is a # necessary component of this line group: nisplus files # According to Sun, files *must* go first to allow the machine to boot hosts: files nisplus dns # Standard tables services: nisplus files networks: nisplus files protocols: nisplus files rpc: nisplus files ethers: nisplus files netmasks: nisplus files bootparams: nisplus files # These two are pure NIS+ constructs, ergo no mention of files publickey: nisplus netgroup: nisplus # Standard tables. The mail relays must have files before nisplus ... # so all our boxes do, in order to standardize nsswitch.conf automount: files nisplus aliases: files nisplus # At this point, I don't use NIS+ to propagate sendmail variables; rather, # I manually copy sendmail.cf sendmailvars: files - Populate the tables (typically, /opt/local/config/files contains the latest nisdump ... so you won't need to make this directory and copy files to it. But there again, if you are starting entirely from scratch, on a brand-new box, you will.) -mkdir /opt/local/config/files -Copy the following files to /opt/local/config/files: auto_home, auto_master, group, netmasks, networks, protocols, rpc, services, timezone. I skip ethers and bootparams because we don't use them. Leave out hosts and aliases for now. Edit passwd and group and remove all the system accounts (root et al). Leave "sysadmin" in group ... currently "sysadmin" includes four UIDs: dweeb1, dweeb2, dweeb3, dweeb4 - nispopulate -v -F -d fhcrc.org. -l 1124cns5063 -p /opt/local/config/files The ending message will say: "nispopulate failed to populate the following tables: hosts mail_aliases" This is fine. -copy rmaster:/home/hostops/etc/hosts and rmaster:/home/mailops/etc/aliases.nisplus to /opt/local/config/files/hosts and /opt/local/config/files/aliases. Also, copy the passwd and shadow files to /opt/local/config/files -verify that no host name is the same as a username in imported in the nispopulate step above. NIS+ does not like seeing usernames and hostnames the same (both contain entries in cred.org_dir ... and allowing users and hosts to share the same name would introduce ambiguity into this table.) -nisaddent -v -f /opt/local/config/files/hosts hosts -nisaddent -v -f /opt/local/config/files/aliases aliases -nisaddent -v -f /opt/local/config/files/passwd passwd -nisaddent -v -f /opt/local/config/files/shadow shadow [I don't use "nispopulate" to import hosts and aliases into NIS+ because nispopulate adds *credentials* for all hosts and aliases ... and I don't want to add credentials for *everybody*, just for the users in passwd. nisaddent just imports data into tables; it doesn't mess with credentials. I don't include passwd and shadow because nispopulate seems to be broken at the moment when it comes to creating credentials for users ... I do this manually below.] I am having trouble delivering NIS+ credentials and synced NIS+/login passwords. I use the following procedure: I run the following for each username (e.g. dweeb1, dweeb2, dweeb3, dweeb4): nisclient -c -v -d fhcrc.org. -l 1124cns5063 username Each user must then log in and sync their login password (what they type when they log in) with the Secure-RPC password (1124cns5063). The first procedure ought to work ... but doesn't seem to at the moment. The second procedure always works. (a) Type "nisclient -u" (b) Type "keylogin", then "chkey -p" nischmod n+r admin.groups_dir.fhcrc.org. [This fixes a permission problem - the default install doesn't give read permission to group nobody ... yet this is necessary before one can list or modify group admin.] -nisgrpadm -a admin.fhcrc.org. dweeb1.fhcrc.org. dweeb2.fhcrc.org. dweeb3.fhcrc.org. dweeb4.fhcrc.org. [This adds these four users to the NIS+ "admin.fhcrc.org." group. Members of this group are allowed to modify the NIS+ tables. Use "nisgrpadm -l admin.fhcrc.org." to list the members of a group. When a machine is listed, that means that the root UID on that machine is a member of the group.] -nisping -C fhcrc.org. -nislog | more rmaster{root}: nislog | more NIS Log printing facility. NIS Log dump : Log state : STABLE. Number of updates : 3 Current XID : 5258 Size of Log in bytes : 516 *** UPDATES *** @@@@@@@@@@@@@@@@ Transaction @@@@@@@@@@@@@@@@@@ #00000, XID : 5256 Time : Thu Nov 21 14:36:39 1996 Directory : groups_dir.fhcrc.org. Entry type : UPDATE time stamp. Entry timestamp : Thu Nov 21 14:36:39 1996 Principal : rmaster.fhcrc.org. Object name : groups_dir.fhcrc.org. .................. Object ..................... Object Name : Directory : groups_dir.fhcrc.org. Owner : Group : Access Rights : ---------------- Time to Live : 0:0:0 Creation Time : Wed Dec 31 16:00:00 1969 Mod. Time : Wed Dec 31 16:00:00 1969 Object Type : NONE ............................................... @@@@@@@@@@@@@@@@ Transaction @@@@@@@@@@@@@@@@@@ #00001, XID : 5257 Time : Thu Nov 21 14:26:27 1996 Directory : org_dir.fhcrc.org. Entry type : UPDATE time stamp. Entry timestamp : Thu Nov 21 14:26:27 1996 Principal : rmaster.fhcrc.org. Object name : org_dir.fhcrc.org. .................. Object ..................... Object Name : Directory : org_dir.fhcrc.org. Owner : Group : Access Rights : ---------------- Time to Live : 0:0:0 Creation Time : Wed Dec 31 16:00:00 1969 Mod. Time : Wed Dec 31 16:00:00 1969 Object Type : NONE ............................................... @@@@@@@@@@@@@@@@ Transaction @@@@@@@@@@@@@@@@@@ #00002, XID : 5258 Time : Thu Nov 21 14:36:33 1996 Directory : fhcrc.org. Entry type : UPDATE time stamp. Entry timestamp : Thu Nov 21 14:36:33 1996 Principal : rmaster.fhcrc.org. Object name : fhcrc.org. .................. Object ..................... Object Name : Directory : fhcrc.org. Owner : Group : Access Rights : ---------------- Time to Live : 0:0:0 Creation Time : Wed Dec 31 16:00:00 1969 Mod. Time : Wed Dec 31 16:00:00 1969 Object Type : NONE ............................................... This is what the nislog should look like. The key items are in front: ... Log state : STABLE. Number of updates : 3 Current XID : 5258 Size of Log in bytes : 516 ... Log state should be STABLE. If it is something else, either the master is busy performing updates (?) or something is wrong. Number of updates should be "3"; this implies that there are no updates. Size of log in bytes: 516 If these last two parameters are anything else, then the master has updates waiting to be checkpointed (removed) from its logs. "nisping -C" should flush these updates. If it doesn't, then either a replica is unavailable or something is wrong. -Done creating the server Users who would like to authenticate against NIS+ -- typically, dweeb1, dweeb2, dweeb3, and dweeb4, should log on and see whether or not an error message about not decrypting the public key appears. If it appears, run nisclient as below. If it doesn't . .. then the nispopulate process successfully created NIS+ credentials. I don't understand why this works sometimes and not other times. -To create credentials for users -- public/prviate key combinations -- each user needs to run the following. When prompted for the "Secure RPC network password", s/he needs to type "1124cns5063" -nisclient -u Create NIS+ client machines To create a NIS+ client machine ("guru", in this example), do the following: -Log onto any machine in the NIS+ space -nisaddcred -p unix.guru@fhcrc.org -P guru.fhcrc.org. des -Log onto the client-to-be as root -Verify that /etc/inet/hosts contains the line: 140.107.10.102 rmaster -Create a file called /etc/defaultdomain containing the single line "fhcrc.org" -nisclient -i -d fhcrc.org. -h rmaster -Edit /etc/nsswitch.conf as appropriate reboot -/usr/sbin/rpc.nisd [On subsequent reboots, rpc.nisd will load automatically.] Create NIS+ replica machines To convert a NIS+ client into a NIS+ replica server, do the following: Log onto the master -nisserver -R -v -d fhcrc.org. -h client [Client must be the box's node name, e.g. not fully-qualified. This is because we carry only node names in our NIS+ tables, e.g. we don't populate them with the fully-qualified versions of each name.] -On the client, perform the following: -keylogin -r -Back on the master, type the following commands. Pause in between each, watching syslog on both machines. Wait for the nisd messages to stop before continuing with the next command. Semi-reassuring messages which include strings like "Finish handshake" and "1 updates, 0 errors" indicate successful completion of a step. The step which requires the longest to complete is the "nisping org_dir.fhcrc.org" command, which will use messages like "update_directory: 3000 objects, still running" to indicate progress. Do NOT reboot or otherwise kill NIS+ processes during this procedure. Under Solaris 2.4, doing so incurred painful consequences. -nisping fhcrc.org. -nisping groups_dir.fhcrc.org. -nisping org_dir.fhcrc.org. -nisping -C fhcrc.org. Here is a sample of the entire experience, from the master's syslog: {nisping fhcrc.org} Nov 25 13:51:28 rmaster nisd[400]: killing read only child: pid #919 Nov 25 13:55:18 rmaster nisd[1055]: nis_dump_svc: sending full dump of fhcrc.org. to guru.fhcrc.org. Nov 25 13:55:18 rmaster nisd[1055]: nis_dump_svc: good dump of fhcrc.org., 2 totalobjects. Nov 25 13:55:22 rmaster nisd[1055]: nis_dump_svc: Finish handshake returned RPC: Timed out {nisping org_dir.fhcrc.org.} Nov 25 13:55:44 rmaster nisd[1057]: nis_dump_svc: sending full dump of org_dir.fhcrc.org. to guru.fhcrc.org. Nov 25 13:59:05 rmaster nisd[1057]: nis_dump_svc: good dump of org_dir.fhcrc.org.,4924 total objects. Nov 25 13:59:08 rmaster nisd[1057]: nis_dump_svc: Finish handshake returned RPC: Timed out {nisping groups_dir.fhcrc.org.} Nov 25 13:59:34 rmaster nisd[1059]: nis_dump_svc: sending full dump of groups_dir.fhcrc.org. to guru.fhcrc.org. Nov 25 13:59:34 rmaster nisd[1059]: nis_dump_svc: good dump of groups_dir.fhcrc.org., 1 total objects. Nov 25 13:59:37 rmaster nisd[1059]: nis_dump_svc: Finish handshake returned RPC: Timed out {nisping -C fhcrc.org.} Nov 25 14:07:50 rmaster nisd[400]: killing read only child: pid #1061 Changing your password under NIS+. This is a pain in the butt Don't bother with "nispasswd", under Solaris 2.5 and above, "passwd" works just fine. guru% passwd passwd: Changing password for dweeb4 Enter login(NIS+) password: New password: Re-enter new password: NIS+ password information changed for dweeb4 The credential information for dweeb4 will not be changed. User dweeb4 must do the following to update his/her credential information: Use NEW passwd for login and OLD passwd for keylogin. Use "chkey -p" to reencrypt the credentials with the new login passwd. The user must keylogin explicitly after their next login. guru% -Enter your current password when prompted for "Enter login(NIS+) password:" -Log out of *all* sessions to guru -Wait a few minutes -Log back in, use your new password -You will see the message "Password does not decrypt secret key for unix.18602@fhcrc.org." -Use the keylogin procedure to authenticate yourself to NIS+ guru% keylogin Password: guru% -Use your *old* password when challenged by keylogin -Use the "chkey" procedure to sync your login and NIS+ passwords guru% chkey -p Updating nisplus publickey database. Reencrypting key for 'unix.18602@fhcrc.org'. Please enter the Secure-RPC password for dweeb4: Please enter the login password for dweeb4: guru% -Use your *old* password when asked for the "Secure-RPC password". Use your new password when asked for "login password". -Wait a few minutes Fixing Credential Problems For reasons I don't understand, users sometimes don't have NIS+ credentials. Or the ones they have don't work. -nisaddcred -rp unix.123456@fhcrc.org -P name.fhcrc.org. -wait a few minutes -nisaddcred -p unix.123456@fhcrc.org -P name.fhcrc.org. DES where 123456 is the user's UID and "name" is the user's login name. The second "nisaddcred" command will ask for the user's login password. If you don't have the user's login password, use any string ... and tell the user that string ... they will need to perform the keylogin/chkey routine above in order to sync their NIS+ password (the string you typed) and their login password. Adding/Modifying Users The GUI tool is the easiest method. Run "solstice" and choose "Users" from the resulting display. This creates a user with NIS+ credentials (both LOCAL and DES credentials). Also, check out the /opt/SUNWadm/bin command-line utilities, notably admuseradd and admusermod. For best results, run these only from the NIS+ master. (e.g if you run admusermod from anything but the NIS+ master, all sorts of grotestque things happen to /export/home on the user's home machine. Notably, "chown -R username /export/home/*; chgrp -R username /export/home/*". Not what you intended. I think this is a bug.) There are several approaches to using the command-line utilities. Add the users to /etc/passwd using the "useradd" command. Use the "passwd" command to add them to /etc/shadow. Extract the entries to pseudo-passwd and pseudo-shadow files, place them in a temporary directory, say, /junk. nispopulate -v -F -p /junk -d fhcrc.org. -S 0 or nisaddent -v -f /junk/passwd -d fhcrc.org. passwd nisaddent -v -f /junk/shadow -d fhcrc.org. shadow Either of these will add users to the NIS+ space ... but will *not* create NIS+ credentials for them. nispopulate -v -F -p /junk -d fhcrc.org. -l 1124cns5063 This will add users to the NIS+ space and will create NIS+ credentials for them. Or, acquire a copy of a password and a shadow file and edit them. Use "nisaddent -avf filename1 passwd; nisaddent -avf filename2 shadow" to add new users. If you have a canonical passwd and shadow file (from /opt/local/config/files, for instance), then you can use "nisaddent -mvf passwd passwd; nisaddent -mvf shadow shadow". Notice how easy it is to mangle the passwd table in NIS+ when using these commands. Net groups I use these to implement access control. /etc/passwd ... +@unix-admin:x::::: /etc/shadow ... +@unix-admin::9933:::::: "+" means allow members of this group, "-" means disallow members of this group. The second field in the passwd file, "x", in this example, says that the actual password is stored in the shadow file. The second field in the shadow file, empty in this example, normally holds the users encrypted password. If this field is empty, for a netgroup, then members of that group can log on. If the field contains an "x", then members of that group *cannot* logon ... even though the "+@" syntax in the passwd field would seem to imply otherwise. After creating a new netgroup (using nisaddent or solstice GUI), I add the appropriate entry to /etc/passwd. Then I run "pwconv" to add the appropriate entry to /etc/shadow. By default, pwconv disables login for members of that netgroup, e.g. it puts an "x" in the second field of /etc/shadow. Administering the NIS+ tables The NIS+ group "admin" controls who can modify NIS+ tables. Any member of "admin" can modify the NIS+ tables in any way. To list the members of "admin": rmaster{dweeb4}41: nisgrpadm -l admin.fhcrc.org. Group entry for "admin.fhcrc.org." group: Explicit members: guru.fhcrc.org. rmaster.fhcrc.org. dweeb1.fhcrc.org. dweeb4.fhcrc.org. dweeb2.fhcrc.org. dweeb3.fhcrc.org. No implicit members No recursive members No explicit nonmembers No implicit nonmembers No recursive nonmembers rmaster{dweeb4}42: Note that the "root" ID on a box is represented by that box's name, rather than by the string "root". Thus, the users who can modify the NIS+ tables in the NIS+ domain fhcrc.org. are: root on rmaster, root on guru, dweeb1, dweeb4, dweeb2, and dweeb3. If I wanted to prevent root on guru from modifying the NIS+ tables, I could: nisgrpadm -r admin.fhcrc.org. guru.fhcrc.org. e.g. "remove root on guru from the admin group" I don't do this on rmaster because I want to run the /home/nisops/bin/nisupdate cron job, which imports /home/hostops/etc/hosts and /home/mailops/etc/aliases.master into the NIS+ space. Only a member of the NIS+ group "admin" (admin.fhcrc.org.) can do th is. Only the root ID can run NIS+ authenticated cron jobs ... because root's credential is written to disk /etc/.rootkey. No other user can run NIS+ authenticated cron jobs ... unless you play with some hack to "keylogin" at the beginning of the cron jo b ... but then you would have to put that user's password in clear text in the cron job script. (Actually, removing root on rmaster from the admin group would have catstrophic effects on the NIS+ domain.) Another way to grant access to a table is to use the nischown command. nischown hostops hosts.org_dir would change owernship of the hosts table from rmaster (root) to hostops. This would allow hostops to modify the hosts table, without being a member of the admin group. nischmod could be used to refine these privileges, e.g. hostops might be allowed to create new entries but not allowed to delete current entries, given the appropriate nischmod command. To look at the NIS+ database files, look in /var/nis/data. This is a quick way to identify the names of the NIS+ tables, also. (Note, for instance, that the aliases table is not aliases.org_dir.fhcrc.org., as one might think, but rather mail_aliases.org_dir.fhcrc.org. Barf!) Permissions and the NIS+ tables 3-12-97 I typed: nischmod n-r x.org_dir for x in (auto_master, auto_home, bootparams, ethers, group, hosts, mail_aliases, netgroup, passwd, sendmailvars, netmasks, networks, protocols, rpc, services, timezone) This removed the "read" permission from the group "nobody", meaning that non-NIS+ authenticated users cannot look at most of the tables. I figured this was good for security. The only users we maintain which don't have NIS+ credentials are the backdoor account and the operations accounts (hostops, mailops, netops, etc.) Unauthenticated users thus no longer have access to the services table ... which means they can't perform outbound telnet or ftp ... To disallow authenticated NIS+ users from looking at the tables, I typed: nischmod w-r x.org_dir except for cred.org_dir. Before doing this, I added all NIS+ client machines to group admin. nisgrpadm -a admin.fhcrc.org snap.fhcrc.org. spitbug.fhcrc.org. To allow pseudo-users like netops to write to syslog, I allow read access to the syslog entry in the services table. nischmod n+r '[cname=syslog],services.org_dir' I noticed that the encrypted password field in passwd.org_dir was readable by unauthenticated NIS+ users (group nobody) and that NIS+ users themselves had trouble changing their passwords. niscat-o passwd.org_dir revealed that the table had read permissi on set for group nobody and that the shadow column had no permissions set for anyone. nischmod n-r passwd.org_dir removed read permission for group nobody from the passwd table. The following command added read permission for the owner to the shadow col umn of the passwd table. nistbladm -u -t passwd_tbl shadow=o+r passwd.org_dir nistbladm -u -t passwd_tbl home=o=r passwd.org_dir 4/25/97 I blew away the NIS+ space and rebuilt from scratch. Here are the default permissions: guru% nisls -l fhcrc.org. fhcrc.org.: D r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:40 1997 org_dir D r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:40 1997 groups_dir guru% nisls -l groups_dir groups_dir.fhcrc.org.: G ----rmcdr---r--- rmaster.fhcrc.org. Fri Apr 25 11:12:06 1997 admin guru% nisls -l org_dir org_dir.fhcrc.org.: T ----rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:41 1997 passwd T ----rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:42 1997 group T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:42 1997 auto_master T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:43 1997 auto_home T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:43 1997 bootparams T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:44 1997 cred T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:44 1997 ethers T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:45 1997 hosts T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:45 1997 mail_aliases T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:46 1997 sendmailvars T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:46 1997 netmasks T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:47 1997 netgroup T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:47 1997 networks T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:48 1997 protocols T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:48 1997 rpc T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:49 1997 services T r---rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:49 1997 timezone guru% nisls -l passwd.org_dir Object Name : passwd Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : ----rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:41 1997 Mod. Time : Fri Apr 25 11:11:41 1997 Object Type : TABLE Table Type : passwd_tbl Number of Columns : 8 Character Separator : : Search Path : Columns : [0] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---r---r---r--- [1] Name : passwd Attributes : (TEXTUAL DATA) Access Rights : ----rm--r---r--- [2] Name : uid Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---r---r---r--- [3] Name : gid Attributes : (TEXTUAL DATA) Access Rights : r---r---r---r--- [4] Name : gcos Attributes : (TEXTUAL DATA) Access Rights : r---rmcdrmcdr--- [5] Name : home Attributes : (TEXTUAL DATA) Access Rights : r---rmcdrmcdr--- [6] Name : shell Attributes : (TEXTUAL DATA) Access Rights : r---rmcdrmcdr--- [7] Name : shadow Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% nisls -l group.org_dir T ----rmcdrmcdr--- rmaster.fhcrc.org. Fri Apr 25 11:11:42 1997 group.org_dir.fhcrc.org. guru% niscat -o group.org_dir Object Name : group Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : ----rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:42 1997 Mod. Time : Fri Apr 25 11:11:42 1997 Object Type : TABLE Table Type : group_tbl Number of Columns : 4 Character Separator : : Search Path : Columns : [0] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---rmcdrmcdr--- [1] Name : passwd Attributes : (TEXTUAL DATA) Access Rights : ----rmcdrmcdr--- [2] Name : gid Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : r---rmcdrmcdr--- [3] Name : members Attributes : (TEXTUAL DATA) Access Rights : r---rmcdrmcdr--- guru% niscat -o auto_master.org_dir Object Name : auto_master Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:42 1997 Mod. Time : Fri Apr 25 11:11:42 1997 Object Type : TABLE Table Type : automount_map Number of Columns : 2 Character Separator : Search Path : Columns : [0] Name : key Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ---------------- [1] Name : value Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% nisact -o auto_home.org_dir nisact: Command not found guru% niscat -o auto_home.org_dir Object Name : auto_home Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:43 1997 Mod. Time : Fri Apr 25 11:11:43 1997 Object Type : TABLE Table Type : automount_map Number of Columns : 2 Character Separator : Search Path : Columns : [0] Name : key Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ---------------- [1] Name : value Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o bootparams.org_Dir Object Name : bootparams Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:43 1997 Mod. Time : Fri Apr 25 11:11:43 1997 Object Type : TABLE Table Type : bootparams_tbl Number of Columns : 2 Character Separator : Search Path : Columns : [0] Name : key Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : value Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% nisact -o cred.org_dir Object Name : cred Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:44 1997 Mod. Time : Fri Apr 25 11:11:44 1997 Object Type : TABLE Table Type : cred_tbl Number of Columns : 5 Character Separator : : Search Path : Columns : [0] Name : cname Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : auth_type Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : auth_name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [3] Name : public_data Attributes : (TEXTUAL DATA) Access Rights : -----m---------- [4] Name : private_data Attributes : (TEXTUAL DATA) Access Rights : -----m---------- guru% niscat -o ethers.org_dir Object Name : ethers Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:44 1997 Mod. Time : Fri Apr 25 11:11:44 1997 Object Type : TABLE Table Type : ethers_tbl Number of Columns : 3 Character Separator : Search Path : Columns : [0] Name : addr Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% nisact -o hosts.org_dir Object Name : hosts Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:45 1997 Mod. Time : Fri Apr 25 11:11:45 1997 Object Type : TABLE Table Type : hosts_tbl Number of Columns : 4 Character Separator : Search Path : Columns : [0] Name : cname Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : addr Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [3] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o mail_aliases.org_dir Object Name : mail_aliases Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:45 1997 Mod. Time : Fri Apr 25 11:11:45 1997 Object Type : TABLE Table Type : mail_aliases Number of Columns : 4 Character Separator : Search Path : Columns : [0] Name : alias Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : expansion Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : comments Attributes : (TEXTUAL DATA) Access Rights : ---------------- [3] Name : options Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o sendmailvars.org_dir Object Name : sendmailvars Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:46 1997 Mod. Time : Fri Apr 25 11:11:46 1997 Object Type : TABLE Table Type : sendmailvars Number of Columns : 2 Character Separator : Search Path : Columns : [0] Name : key Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ---------------- [1] Name : value Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o netmasks.org_dir Object Name : netmasks Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:46 1997 Mod. Time : Fri Apr 25 11:11:46 1997 Object Type : TABLE Table Type : netmasks_tbl Number of Columns : 3 Character Separator : Search Path : Columns : [0] Name : addr Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : mask Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% nisact -o netgroup.org_dir Object Name : netgroup Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:47 1997 Mod. Time : Fri Apr 25 11:11:47 1997 Object Type : TABLE Table Type : netgroup_tbl Number of Columns : 6 Character Separator : Search Path : Columns : [0] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ---------------- [1] Name : group Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ---------------- [2] Name : host Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [3] Name : user Attributes : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE) Access Rights : ---------------- [4] Name : domain Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [5] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o networks.org_dir Object Name : networks Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:47 1997 Mod. Time : Fri Apr 25 11:11:47 1997 Object Type : TABLE Table Type : networks_tbl Number of Columns : 4 Character Separator : Search Path : Columns : [0] Name : cname Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : addr Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [3] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o protocols.org_dir Object Name : protocols Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:48 1997 Mod. Time : Fri Apr 25 11:11:48 1997 Object Type : TABLE Table Type : protocols_tbl Number of Columns : 4 Character Separator : Search Path : Columns : [0] Name : cname Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : number Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [3] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o rpc.org_dir Object Name : rpc Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:48 1997 Mod. Time : Fri Apr 25 11:11:48 1997 Object Type : TABLE Table Type : rpc_tbl Number of Columns : 4 Character Separator : Search Path : Columns : [0] Name : cname Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : number Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [3] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o services.org_dir Object Name : services Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:49 1997 Mod. Time : Fri Apr 25 11:11:49 1997 Object Type : TABLE Table Type : services_tbl Number of Columns : 5 Character Separator : Search Path : Columns : [0] Name : cname Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [2] Name : proto Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [3] Name : port Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [4] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o timezone.org_dir Object Name : timezone Directory : org_dir.fhcrc.org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 12:0:0 Creation Time : Fri Apr 25 11:11:49 1997 Mod. Time : Fri Apr 25 11:11:49 1997 Object Type : TABLE Table Type : timezone_tbl Number of Columns : 3 Character Separator : Search Path : Columns : [0] Name : name Attributes : (SEARCHABLE, TEXTUAL DATA, CASE INSENSITIVE) Access Rights : ---------------- [1] Name : tzone Attributes : (TEXTUAL DATA) Access Rights : ---------------- [2] Name : comment Attributes : (TEXTUAL DATA) Access Rights : ---------------- guru% niscat -o fhcrc.org. Object Name : fhcrc Directory : org. Owner : rmaster.fhcrc.org. Group : admin.fhcrc.org. Access Rights : r---rmcdrmcdr--- Time to Live : 24:0:0 Creation Time : Wed Dec 31 16:00:00 1969 Mod. Time : Fri Apr 25 11:52:16 1997 Object Type : DIRECTORY Name : 'fhcrc.org.' Type : NIS Master Server : Name : rmaster.fhcrc.org. Public Key : Diffie-Hellman (192 bits) Universal addresses (6) [1] - udp, inet, 140.107.10.102.0.111 [2] - tcp, inet, 140.107.10.102.0.111 [3] - -, inet, 140.107.10.102.0.111 [4] - -, loopback, rmaster.rpc [5] - -, loopback, rmaster.rpc [6] - -, loopback, rmaster.rpc Replicate : Name : guru.fhcrc.org. Public Key : Diffie-Hellman (192 bits) Universal addresses (3) [1] - udp, inet, 140.107.46.113.0.111 [2] - tcp, inet, 140.107.46.113.0.111 [3] - -, inet, 140.107.46.113.0.111 Replicate : Name : pooh.fhcrc.org. Public Key : Diffie-Hellman (192 bits) Universal addresses (3) [1] - udp, inet, 140.107.10.101.0.111 [2] - tcp, inet, 140.107.10.101.0.111 [3] - -, inet, 140.107.10.101.0.111 Replicate : Name : rserver1.fhcrc.org. Public Key : Diffie-Hellman (192 bits) Universal addresses (3) [1] - udp, inet, 140.107.10.110.0.111 [2] - tcp, inet, 140.107.10.110.0.111 [3] - -, inet, 140.107.10.110.0.111 Replicate : Name : rserver2.fhcrc.org. Public Key : Diffie-Hellman (192 bits) Universal addresses (3) [1] - udp, inet, 140.107.10.111.0.111 [2] - tcp, inet, 140.107.10.111.0.111 [3] - -, inet, 140.107.10.111.0.111 Time to live : 12:0:0 Default Access rights : guru% Restoring NIS+ after tragedy Generally, this is no need to restore the NIS+ files. A client can be re-introduced into the NIS+ space simply by following the standard process for creating a NIS+ client. A replica server can be re-introduced into the space by deleting /va/nis/{server name}.log and issuing a "nisping -C" command. A master server is theonly machine for which one might want to go to backup files. To restore a master server's NIS+ data, restore the following files: /var/nis/* /etc/.rootkey /etc/defaultdomain /etc/nsswitch.conf reboot /opt/local/sbin/nisdump, run by cron on rmaster every night, saves /var/nis in /opt/local/config/files/var_nis.tar.Z. It also saves /etc/.rootkey in /opt/local/config/files/safe.rootkey. (Although, of course, .rootkey is easy to recreate, just type "key login -r", enter root's password, and 'tis done.) Another cron job archive's copies of /opt/local/config/files in /opt/local/config/backup; keeps a week's worth. Files are imported into the NIS+ space using the nisaddent command. nisaddent -avf hosts hosts # This adds the contents of hosts to the hosts table nisaddent -mvf hosts hosts # This merges the contents of hosts with the hosts table nisaddent -avf auto_home -t auto_home key-value #This adds the contents of the file auto_home to the auto_home table nisaddent -mvf passwd passwd #These two commands import the passwd and nisaddent -mvf shadow shadow #and shadow files into the NIS+ passwd table There is also a way to recreate the root master from the files in rmaster:/opt/local/config/files; I need to document this here. Maintaining the NIS+ space When a change is made to the NIS+ space, it is stored in RAM by niscachemgr. Every two minutes, a box with new changes in niscachemgr propagates those changes to niscachemgr on other boxes. "nisping org_dir", "nisping group_dir" can be used to propagate these changes immediately. At some point, one wants to commit these changes to disk. "nisping -C' accomplish this; rmaster runs this as a cron job twice a night. (Why twice? In case the first one fails for some reason. I have no evidence to suggest that a checkpoint would ever fail.) For the first few months of 1997, rmaster ran this every hour. After conversations with Sun Service, I abandoned this. Apparently, nisping -C uses lots of machine resources, and while a checkpoint is happening, access to NIS+ tables can be interrupted. We also postulated that this kind of behavior may have been causing aliases to drop out of mail_aliases.org_dir. Troubleshooting "no public key for unix.machine" Look for "no publc key for unix.machine" in syslog. This occurs transiently when a client machine is added or removed but should not occur otherwise. If it does occur, the machine in question is having trouble with credentials. Try the following procedure. -Verify that /etc/inet/hosts contains the line: 140.107.10.102 rmaster -On the troubled machine: -rm -rf /var/nis/* -nisclient -I -d fhcrc.org. -h rmaster -init 6 If this fails, then perform the following steps before repeating the above procedure. -From any other machine in the NIS+ domain -nisaddcred -rp unix.machine@fhcrc.org -P machine.fhcrc.org. -wait a few minutes -nisaddcred -p unix.machine@fhcrc.org -P machine.fhcrc.org. des -wait a few minutes In some situations, when NIS+ is hosing a machine, the box will not go down with "init 6". In these situation, kill any "umount" processes on the box; the reboot should then proceed normally. "possible loop in name space" Thus far, this has meant that the root master is corrupt, time to wipe the NIS+ space and rebuild from scratch. These seem like serious problems. "xdr_array: out of memory" "WARNING: db_dictionary" Removing a NIS+ client -Run /opt/local/sbin/nukenis -Rebooting is not entirely necessary ... but is desirable Note that nukenis replaces /etc/nsswitch.conf with a straight files + dns configuration file. If you want to be utterly thorough, remove the client's NIS+ credentials. -On any box still living in the NIS+ space (where "guru" is the example name of the box): nisaddcred -rp unix.guru@fhcrc.org -P guru.fhcrc.org. Removing a NIS+ replica server On the NIS+ replica server, perform the same steps as are outlined for removing NIS+ from a client. On the master server (rmaster): nisrmdir -fs guru.fhcrc.org. groups_dir.fhcrc.org. nisrmdir -fs guru.fhcrc.org. org_dir.fhcrc.org. nisrmdir -fs guru.fhcrc.org. fhcrc.org. nisclient -co guru On the ex-replica server: rm -r /var/nis/* rm /etc/.rootkey ps -ef | grep nis , kill pids for all nisd's and nis_cachemngrs nisclient -i -d fhcrc.org. -h rmaster mod /etc/nsswitch.conf as desired reboot /usr/sbin/rpc.nisd Ignore complaints about not being able to find the /var/nis coldstart file. If the replica server is up and functioning when you start this process, you can skip the "f" parameter in the nisrmdir commands. Why would I want to do this? The NIS+ logs on rmaster are only checkpointed if updates have been propagated to *all* replica servers. If a replica server is going to be down for a while, then I might choose to tell rmaster that this downed box is no longer a replica server, thus allowing the checkpoints on the logs to complete. When the downed box returns to life, I would repeat the steps to reinstate it as a replica server. Removing the NIS+ space entirely Just repeat the steps outlined in "Removing a NIS+ client" on every single box. Try to traverse the tree from the leaves in, e.g. pure clients first, replica servers second, master servers next, root server last. Useful NIS+ Admin scripts nisdump: #!/bin/sh PATH=/usr/lib/nis cd /opt/local/config/files nisaddent -d aliases > aliases nisaddent -d bootparams > bootparams nisaddent -d ethers > ethers nisaddent -d group > group nisaddent -d hosts > hosts nisaddent -d netgroup > netgroup nisaddent -d netid > netid nisaddent -d netmasks > netmasks nisaddent -d networks > networks nisaddent -d passwd > passwd nisaddent -d protocols > protocols nisaddent -d publickey > publickey nisaddent -d rpc > rpc nisaddent -d services > services nisaddent -d shadow > shadow nisaddent -d timezone > timezone nisaddent -d -t auto_home.org_dir key-value > auto_home nisaddent -d -t auto_master.org_dir key-value > auto_master #nisaddent -d -t auto_direct.org_dir key-value > auto_direct /usr/bin/chmod 600 shadow /usr/bin/tar cfp var_nis.tar /var/nis /usr/bin/cp /etc/.rootkey safe.rootkey nispoing: #!/bin/sh #Checkpoint the NIS+ domain /usr/lib/nis/nisping -C fhcrc.org. /usr/lib/nis/nisping -C org_dir.fhcrc.org. /usr/lib/nis/nisping -C groups_dir.fhcrc.org. /usr/lib/nis/nisping fhcrc.org. /usr/lib/nis/nisping org_dir.fhcrc.org. /usr/lib/nis/nisping groups_dir.fhcrc.org. nukenis: #!/bin/sh # Run this as root to remove NIS+ from a machine # You may want to manually copy ASCII files from /opt/local/config/files to # the relevant locations. --sk 2-26-97 echo "Replacing /etc/nsswitch.conf ..." if [ -f /opt/local/config/root/etc/nsswitch.dns ]; then cp /opt/local/config/root/etc/nsswitch.dns /etc/nsswitch.conf else cp /etc/nsswitch.files /etc/nsswitch.conf echo "Remember to add 'dns' to /etc/nsswitch.conf" fi echo "Stopping rpc services" /etc/init.d/rpc stop /etc/init.d/nscd stop /etc/init.d/sendmail stop echo "Nuking NIS+ files" rm -f /etc/.rootkey rm -rf /var/nis/* rm -rf /var/nis/.* rm -rf /etc/defaultdomain /etc/init.d/rpc start /etc/init.d/nscd start if [ -f /opt/local/config/root/etc/nsswitch.dns ]; then /etc/init.d/sendmail start else echo "Add 'dns' to /etc/nsswitch.conf before restarting sendmail" fi This script compares the NIS+ tables to the file-based masters. If there is a difference, scream. I wrote this script during a period when alias entries were dropping out of the NIS+ table randomly. Turns out that this was occurring because I was running "nisping -C fhcrc.org." too frequently - every hour or more. When I yanked that cronjob, the "missing aliases" problem stopped. monitor_nisplus: #!/usr/local/bin/perl # If aliases.org_dir is not identical to # bug0:/home/mailops/etc/aliases.nisplus then scream to sk. --sk 4-11-97 # If hosts.org__dir is not identical to /home/hostops/etc/hosts then # scream to sk. --sk 6-20-97 use Sys::Syslog; use POSIX; use File::Copy 'cp'; $logdir = "/home/nisops/log"; $tmpdir = "/home/nisops/tmp"; ###################################################################### # Aliases table ###################################################################### $dumpfile = "aliases.dump"; $lockfile = "monitor_aliases.lock"; $logfile = "aliases.log"; $masterdir = "/home/mailops/etc"; $masterfile = "aliases.nisplus"; $upaliases = "/tmp/upaliases.lock"; # If master text file isn't readable, bail if (! -r "$masterdir/$masterfile") { exit; } # If upaliases is running, bail if (-e "$upaliases") { exit; } # Dump aliases.org_dir to a file system ("/usr/lib/nis/nisaddent -d aliases > '$tmpdir/$dumpfile'"); cp ("$masterdir/$masterfile", "$tmpdir/aliases.file"); # Clean the dump file open (DUMP, "<$tmpdir/$dumpfile"); open (OUT, ">$tmpdir/aliases.dump1"); while () { s/^#.*\n//; # Strip comments at beginning of line s/\s*#.*//; # Strip comments in middle of line s/:\s*\n/: /; # Join lines which end with ":" s/:\s*/:\$\$\$/; # Save colon plus space combinations s/,\s*\n/,/; # Join lines which end with "," s/\(.*?\)//g; # Strip parens and their contents s/\t//g; # Strip tabs s/ //g; # Strip spaces s/^\n//; # Strip blank lines s/:\$\$\$/: /; # Restore space after colon print (OUT $_); } close DUMP; close OUT; system ("/usr/bin/sort '$tmpdir/aliases.dump1' > '$tmpdir/aliases.dump2'"); # Clean the master file open (MASTER, "<$tmpdir/aliases.file"); open (OUT, "> $tmpdir/aliases.file1"); while () { s/.*#.*\n//; # Strip comments s/:\s*\n/: /; # Join lines which end with ":" s/:\s*/:\$\$\$/; # Save colon plus space combinations s/,\s*\n/,/; # Join lines which end with "," s/\(.*?\)//g; # Strip parens and their contents s/\t//g; # Strip tabs s/ //g; # Strip spaces s/^\n//; # Strip blank lines s/:\$\$\$/: /; # Restore space after colon print (OUT $_); } close MASTER; close OUT; system ("/usr/bin/sort '$tmpdir/aliases.file1' > '$tmpdir/aliases.file2'"); # If there are differences and this is news, scream $diff = (system ("/usr/bin/diff $tmpdir/aliases.dump2 $tmpdir/aliases.file2"))/256; if (($diff == 1) && (! -e "$tmpdir/$lockfile")) { $diff = `/usr/bin/diff $tmpdir/aliases.dump2 $tmpdir/aliases.file2`; open FILE, ">$tmpdir/aliases.msg"; print FILE "NIS+ aliases not the same as files. --monitor_nisplus"; close FILE; system "/usr/bin/mailx -s 'skendric' apager\@fhcrc.org < $tmpdir/aliases.msg"; system "/usr/bin/mailx -s 'NIS+ aliases not the same as files' skendric\@fhcrc.org < $tmpdir/aliases.msg"; system ("/usr/bin/touch $tmpdir/$lockfile"); open LOG, ">>$logdir/$logfile"; print LOG scalar localtime, "\n"; print LOG $diff, "\n"; close LOG; } # If there are no differences but the lockfile exists, then a problem has been # fixed, remove the lockfile if (($diff == 0) && (-e "$tmpdir/$lockfile")) { unlink "$tmpdir/$lockfile"; } # If the lock file exists, a problem has occurred; leave the temp files until # the problem is resolved if ( ! -e "$tmpdir/$lockfile") { unlink <$tmpdir/aliases.*>; } ###################################################################### # Hosts table ###################################################################### $dumpfile = "hosts.dump"; $edho = "/tmp/edho.lock"; $lockfile = "monitor_hosts.lock"; $logfile = "hosts.log"; $masterdir = "/home/hostops/etc"; $masterfile = "hosts"; $uphosts = "/tmp/uphosts.lock"; # If edho or uphosts are running, bail if ( (-e $edho) || (-e $uphosts) ) {exit}; # Dump hosts.org_dir to a file system ("/usr/lib/nis/nisaddent -d hosts > '$tmpdir/$dumpfile'"); cp ("$masterdir/$masterfile", "$tmpdir/hosts.file"); # Clean the dump file open (DUMP, "<$tmpdir/$dumpfile"); open (OUT, ">$tmpdir/hosts.dump1"); while () { s/^\n//; # Strip blank lines s/^#.*\n//; # Strip comments s/\s#.*//; # Strip comments s/\t/ /g; # Replace tabs with spaces s/ +/ /g; # Reduce all white space to a single space s/ \n/\n/; # Strip trailing space s/ (.*?) .*/ $1/; print (OUT $_); } close DUMP; close OUT; system ("/usr/bin/sort '$tmpdir/hosts.dump1' > '$tmpdir/hosts.dump2'"); # Clean the master file open (MASTER, "<$tmpdir/hosts.file"); open (OUT, "> $tmpdir/hosts.file1"); while () { s/^\n//; # Strip blank lines s/^#.*\n//; # Strip comments s/\s#.*//; # Strip comments s/\t/ /g; # Replace tabs with spaces s/ +/ /g; # Reduce all white space to a single space s/ \n/\n/; # Strip trailing space s/ (.*?) .*/ $1/; print (OUT $_); } close MASTER; close OUT; system ("/usr/bin/sort '$tmpdir/hosts.file1' > '$tmpdir/hosts.file2'"); # If there are differences and this is news, scream $diff = (system ("/usr/bin/diff $tmpdir/hosts.dump2 $tmpdir/hosts.file2"))/256; if (($diff == 1) && (! -e "$tmpdir/$lockfile")) { $diff = `/usr/bin/diff $tmpdir/hosts.dump2 $tmpdir/hosts.file2`; open FILE, ">$tmpdir/hosts.msg"; print FILE "NIS+ hosts not the same as files. --monitor_nisplus"; close FILE; system "/usr/bin/mailx -s 'skendric' apager\@fhcrc.org < $tmpdir/hosts.msg"; system "/usr/bin/mailx -s 'NIS+ hosts not the same as files' skendric\@fhcrc.org < $tmpdir/hosts.msg"; system ("/usr/bin/touch $tmpdir/$lockfile"); open LOG, ">>$logdir/$logfile"; print LOG scalar localtime, "\n"; print LOG $diff, "\n"; close LOG; } # If there are no differences but the lockfile exists, then a problem has been # fixed, remove the lockfile if (($diff == 0) && (-e "$tmpdir/$lockfile")) { unlink "$tmpdir/$lockfile"; } # If the lock file exists, a problem has occurred; leave the temp files until # the problem is resolved if ( ! -e "$tmpdir/$lockfile") { unlink <$tmpdir/hosts.*>; } Useful Sun NIS+ documents Document ID: 1010 SYNOPSIS: NIS+ database recovery DETAIL DESCRIPTION: Regarding backup/restore strategy of nis+ data, if the root server goes down, can it recover from a replica server? Is a simple dump/restore of /var/nis enough for backing up the nis+ domain? SOLUTION SUMMARY: If you use backup and restore on /var/nis that is sufficient. However there are a couple of caveats. 1) If you restore a master server from an out of date (with respect to the namespace) /var/nis directory, the slaves will all do full resyncs to get back to this _older_version of the data and thus delete any changes that had occurred later in the cycle. 2) If you change the name or IP address of a NIS+ server the backup will no longer be valid. 3) For replicas you can just delete /var/nis/servername.log and ping the master to get a fresh copy of the data. (forces a full resync) 4) Since the log file has ufs "holes" in it, you must use a backup program that understands about this feature. (ufsdump/ufsrestore does) DATE APPROVED: 11/20/95 KEYWORDS: nis+ database recovery backup restore OS RELEASE: Solaris -------------------------------------------------- SunService Tip Sheet for SUN NIS+ Revision: 1.5 Date: November 11, 1996 Mail to: support@network.East.Sun.COM Preface 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: Common 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 4.0: Some Frequently Asked Questions 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 6.0: Known Bugs & RFEs 7.0: References 7.1: Important Man Pages 7.2 Sunsolve Documents 7.3 Sun Educational Services 7.4: Solaris Documentation 7.5: Third Party Documentation 7.6: RFCs 8.0: Supportability 9.0: Additional Support 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 Common 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.) 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 Unfortunately, there is no easy way to configure the root server again when the IP address is changed. This is because the clients maintain the server's IP address in their cold start file, and the server has the old IP address in its cache. You must totally reinitialize the Root Server for an IP address change. The best way to do this is first dump the NIS+ tables to ASCII files using the nisaddent command: root-master# cd /var/tmp/nisfiles root-master# nisaddent -d aliases > aliases root-master# nisaddent -d bootparams > bootparams root-master# nisaddent -d ethers > ethers root-master# nisaddent -d group > group root-master# nisaddent -d hosts > hosts root-master# nisaddent -d netgroup > netgroup root-master# nisaddent -d netid > root-master# nisaddent -d netmasks > netmasks root-master# nisaddent -d networks > networks root-master# nisaddent -d passwd > passwd root-master# nisaddent -d protocols > protocols root-master# nisaddent -d publickey > publickey root-master# nisaddent -d rpc > rpc root-master# nisaddent -d services > services root-master# nisaddent -d shadow > shadow root-master# nisaddent -d timezone > timezone root-master# nisaddent -d -t auto_home.org_dir key-value > auto_home root-master# nisaddent -d -t auto_master.org_dir key-value > auto_master At this point, edit the newly dumped hosts file to reflect the new ipaddress(es). Then, you must clean out old NIS+ info: root-master# cp /etc/nsswitch.nisplus /etc/nsswitch.conf root-master# /etc/init.d/rpc stop root-master# rm -f /etc/.rootkey root-master# rm -rf /var/nis/* root-master# /etc/init.d/rpc start And finally, you can reconfigure your NIS+ server, as described in Section 3.2. After you have reconfigured the Root Master server you will need to reinitialize the nis+ clients. On the clients, remove the old NIS+ info as detailed above and follow the procedure in Section 3.3 to reinitialize the clients. 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 On Solaris 2.5 machines and later the passwd command now performs all functions previously performed by nispasswd. %passwd -r nisplus As root on Solaris 2.5 and later you either use adminsuite or #passwd -r nisplus username On Solaris 2.4 and earlier 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 using adminsuite or 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 Do not use nispasswd! This will change the passwd in the local /etc/passwd file. Then, run chkey -p and enter the new network passwd: # chkey -p 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/hosts hosts Or, you could dump a table, make changes and then replace the copy of the table in NIS+ For example: %% nisaddent -d hosts > /tmp/hosts %% vi /tmp/hosts %% nisaddent -r -f /etc/hosts hosts There is a special case to modify the password table using nisaddent. Example: %% nisaddent -d passwd > /tmp/passwd %% nisaddent -d shadow > /tmp/shadow %% vi /tmp/passwd %% nisaddent -r -f /tmp/passwd passwd %% nisaddent -m -f /tmp/shadow -t passwd.org_dir shadow The reason that you must do the passwd table this way is that is you don't reload all the shadow information your passwords will be lost. 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/* # rm -rf /etc/defaultdomain # /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. 4.0 Some Frequently Asked Questions 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 -p They have to again type their NIS+ network password (nisplus) and then their login password (password typed in when logging into system) 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 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.x NIS+ Patches Solaris 2.3 NIS+ Patches 101318-82 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd) An important patch that should be installed on any machines. Since it contains a large number of NIS+ fixes, it is an absolute necessity for a NIS+ machine. 101384-08 SunOS 5.3: Admintool Jumbo patch Fixes a large number of bugs related to NIS+ and admintool. This patch must be installed if you use admintool to modify your NIS+ databases. 101582-03 SunOS 5.3: POINT PATCH: Password aging & NIS+ don't work (together) This optional patch should be installed only if you want to to combine NIS+ and password aging. 101736-03 SunOS 5.3: nisplus patch Fixes errors in the NIS+ library. Should be installed on all NIS+ machines. 102447-01 OpenWindows 3.3: xdm cannot be used on NIS+ networks Corrects a bug which prevented NIS+ users from logging in via xdm. 5.2: Solaris 2.4 NIS+ Patches 101945-43 SunOS 5.4: jumbo patch for kernel An important patch that should be installed on any machines. Since it contains a large number of NIS+ fixes, it is an absolute necessity for a NIS+ machine. 102294-01 OpenWindows 3.4: xdm cannot be used on NIS+ networks Corrects a bug which prevented NIS+ users from logging in via xdm. 101973-24 SunOS 5.4: fixes for libnsl and ypbind This is a required patch for nis+. 102277-02 SunOS 5.4: nss_nisplus.so.1 fixes 102153-04 SunOS 5.4: Admintool Jumbo patch 102273-01 SunOS 5.4: nisupdkeys -a does not deal properly with multi-homed systems 102336-01 SunOS 5.4: POINT PATCH: 1091205 - Password aging & NIS+ don't work This optional patch should be installed only if you want to to combine NIS+ and password aging. 102521-01 SunOS 5.4: rpc.nisd leaks one file descriptor each checkpoint request *** OBSOLETED BY 101973-15 or later 102677-01 SunOS 5.4: nispasswd coredumps in mailoc with SEGV 102608-03 SunOS 5.4: nisaddent and nispopulate fixes atch-ID# SunOS 5.4: nis_cachemgr fixes 5.3: Solaris 2.5 NIS+ Patches 103060-05 SunOS 5.5: nis_cachemgr fix atch-ID# SunOS 5.5: rpc.nisd hangs in write(2) 103279-02 SunOS 5.5: nscd breaks passwd shadowing with NIS+ 6.0: Known Bugs & RFEs There are no known open issues on NIS+. 7.0 References 7.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 7.2: Sunsolve Documents There are a number of Sunsolve documents concerning NIS+ The ones listed below either contain some additional information not in this document, or reference rare problems, or rare how-tos. 7.2.1: FAQs 1012 NIS+ questions 7.2.2: Infodocs 2216 NIS+ questions 11742 How to convert a NIS+ root replica server to a root mas 7.2.3: SRDBs 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. 7.3: Sun Educational Services NIS+ concepts and administration offered by SUNED (contact 1-800 number to get more information) 7.4: Solaris Documentation _Name Services Administration Guide_, part #801-6633-10 _Name Services Configuration Guide_, part #801-6635-10 7.5: Third Party Documentation _All About Administering NIS+_, by Rick Ramasey, Prentice Hall 7.6: RFCs There are no RFCs on NIS+. 8.0 Supportability SunService is not responsible for the initial configuration of your NIS+ environment. In addition, SunService can not diagnose your NIS+ performance problems, or suggest NIS+ tuning guidelines. We can help resolve problems where NIS+ is not behaving correctly, but in such cases the contact must be a system administrator who understands how the NIS+ domain is setup. 9.0 Additional Support For initial configuration, or NIS+ performance tuning guidelines, please contact your local SunService office for possible consulting offerings. Sun's Customer Relations organization can put you in touch with your local SunIntegration or Sales office. You can reach Customer Relations at 800-821-4643. Preface The purpose of this support document is to give an overview of the nis+ naming service, give references to other documentation for detailed explanations and procedures where applicable and to include certain procedures that do no exist in other documentation. This document will also include a FAQ section and a section on debugging nis+. This document will not include in depth descriptions that can be found in other Sun documentation, nor will it include procedures that can be found in same. This document is intended to be used as a reference. The following list of documents will be referenced frequently and are all part of the standard doc set for their appropriate releases. Solaris 2.3 SunOS 5.3 Administering NIS+ and DNS NIS+ Quick Start Solaris 2.4 Name Services Administration Guide Name Services Configuration Guide NIS+ Transition Guide Solaris 2.5 NIS+ and FNS Administration Guide NIS+ and DNS Setup and Configuration Guide NIS+ Transition Guide This document will also contain references to patches and it should be noted that patches are very dynamic and the revisions occur frequently. Thus it is always best to check with Sunsolve or the solution center to see what the current version of a patch is before installing it. From sbk@fhcrc.org Tue Nov 26 11:27:06 1996 Received: from bug1.fhcrc.org (bug1.fhcrc.org [140.107.10.110]) by gnat.fhcrc.org (8.8.3/8.8.2) with ESMTP id LAA00696 for ; Tue, 26 Nov 1996 11:27:05 -0800 (PST) Received: from spitbug.fhcrc.org (spitbug.fhcrc.org [140.107.46.101]) by bug1.fhcrc.org (8.8.3/8.8.2) with ESMTP id LAA09434 for ; Tue, 26 Nov 1996 11:25:33 -0800 (PST) Received: (from sbk@localhost) by spitbug.fhcrc.org (8.8.3/8.8.2) id LAA03550; Tue, 26 Nov 1996 11:25:52 -0800 (PST) Date: Tue, 26 Nov 1996 11:25:52 -0800 (PST) From: Stuart_Kendrick To: skendric@fhcrc.org Subject: Re: SUMMARY: NIS+ root replica --> root master (fwd) Message-ID: ---------- Forwarded message ---------- Date: Thu, 21 Nov 1996 12:14:35 GMT From: Kevin Davidson To: Stuart Kendrick Subject: Re: SUMMARY: NIS+ root replica --> root master >>>>> Stuart Kendrick writes: sbk> I asked about recovery strategies should a master server croak. sbk> There are no canned strategies -- no way to promote a replica server to sbk> master, for instance. sbk> In theory, it should be possible to take recent file dumps and create a sbk> server from them. And in theory, it could be possible to restore from a sbk> recent backup. I haven't tried either to date. The key issue would be sbk> whether or not current replica servers would survive the experience. Maybe I missed your original message ? We proved yesterday that you *can* successfully rebuild a NIS+ master (and a replica) simply by preserving /var/nis. Our two main servers (our NIS+ master and replica) were both upgraded from 2.4 to 2.5.1. As the partitions were strangely sized (we set them up before we really got to grips with Solaris, so we had /var in the root partition) we opted to jumpstart them to install 2.5.1 from scratch and then customise them. Obviously we had to do one at a time to maintain the NIS+ service. All it takes is to put back /var/nis from a dump and then keylogin -r (for some reason preserving /etc/.rootkey didn't work). Also you can use this script to dump your NIS+ tables to flat files for rebuilding with nispopulate. Beware that the services table gets screwed up (unless that's been fixed by a Sun patch to nisaddent). #!/bin/sh # Dump NIS+ tables to text files PATH=/usr/lib/nis:$PATH; export PATH cd /nis+files for table in bootparams ethers group hosts netgroup netmasks networks \ passwd protocols rpc services timezone ; do nisaddent -d -t $table.org_dir $table > $table done nisaddent -d -t mail_aliases.org_dir aliases > aliases nisaddent -d -t passwd.org_dir shadow > shadow chmod 600 shadow nisaddent -d -t cred.org_dir publickey > publickey for table in auto_master auto_home auto_direct auto_projects auto_local \ auto_objlocal auto_contrib auto_cns auto_caad auto_cdrom auto_floppy do nisaddent -d -t $table.org_dir key-value > $table done -- |Kevin.Davidson@edinburgh.ac.uk +-+ Centre for Cognitive Science/HCRC, | |tkld@cogsci.ed.ac.uk | | University of Edinburgh, | |+44 (0)131 650 6879 .oOo. | | 2 Buccleuch Place, EH8 9LW. .oOo. | `-------------------------------' `-------------------------------------------' Date: Wed, 27 Nov 1996 11:52:31 GMT From: Stephen Hickey ISI ext 53847 To: sbk@fhcrc.org Cc: gibian@stars1.hanscom.af.mil Subject: Re: SUMMARY: NIS+ root replica --> root master > To: sysadmin > Subject: SUMMARY: NIS+ root replica --> root master > Status: RO > > ================================================================== > Date: Wed, 20 Nov 1996 11:07:32 -0800 (PST) > From: Stuart Kendrick > Subject: SUMMARY: NIS+ root replica --> root master > ================================================================== > > I asked about recovery strategies should a master server croak. > > There are no canned strategies -- no way to promote a replica server to > master, for instance. > > In theory, it should be possible to take recent file dumps and create a > server from them. And in theory, it could be possible to restore from a > recent backup. I haven't tried either to date. The key issue would be > whether or not current replica servers would survive the experience. > > Thanks to Marc Gibian for thorough reponses to this and related issues. > > --sk > Hello, I did not see your original posting but I have some info for you. It is possible to recreate your NIS+ master server using several methods - restore /var/nis and /etc/.rootkey - recreate the NIS+ domain using previously dumped NIS+ tables Both methods work if you are "rebuilding" on the same machine or using new hardware because the original machine is dead! This works because the server is only referenced using the IP address and name (contained in the /var/nis/NIS_COLD_START file. Providing these stay the same, you NIS+ replicas and clients will recover The prefered method (for me!) is to restore /var/nis and the /etc/.rootkey. We have a cronjob that runs every day that dumps the tables in text format and makes a "tar" of /var/nis and /etc/.rootkey. I have attached the script. Have a look at it and see if you find it usefull. Hope this helps, Steve. _________________________________________________________________________ | | | Stephen Hickey e-Mail Hickey.S@isi.bankgesellschaft.de | | UNIX System Admin. Telephone +(49) 030 245 53847 | |_______________________________________________________________________| > Original post and responses follow: > > To: sun-managers@ra.mcs.anl.gov > Subject: NIS+ root replica --> root master > > It seems to me that once my master server is toast, I can't manage > my NIS+ domain anymore. Does anyone know differently? > > -When the master is dead, the replicas still provide all > services to clients ... but I can't mod nor dump the NIS+ tables. > -When the master is dead, there is no way to convert (promote) a > replica to master. > > Has anyone successfully recovered a master from backup? /var/nis, > /etc/.rootkey, and /etc/nsswitch.conf would seem to be the only needed > items. But it is not obvious to me what happens if /var/nis from backup > tape is "behind" /var/nis on a replica. In theory, time stamps should > allow the replica to bring the recovered master back in sync ... Has > anyone actually done this? > > --sk > > Stuart Kendrick > Network Services > FHCRC > > Date: Wed, 13 Nov 1996 14:21:36 -0500 > From: "Marc S. Gibian" > To: sbk@fhcrc.org > Subject: Re: NIS+ root replica --> root master > > You are correct that root replicas don't buy you as much as one > might think should your root master fail. I have been developing > procedures/scripts and what have you for my customer's product including > the area of NIS+ management. One case we care about is when a root master > goes away without notice. I originally thought that setting up root > replicas would allow us to just convert a root replica into the new root > master. WRONG! You can't get there from here... the procedure Sun makes > available for converting a root replica into a root master requires the > original root master to be running, although even then the procedure > never has worked for us. I believe you CAN use the technique for dumping > NIS+ table contents to flat files, used for changing IP address of root > masters, to get checkpoints from which you can then create a new root > master if needed. We haven't had time to try this, but given that I > have the IP change working (for the root master) and it uses the same > technique, I think it should work (let me know if you try it). > > Personally, I believe two critical shortcomings in NIS+'s implementation > are: > > 1. No integral mechanism for changing IP addresses on servers. This CAN > be done, but only through a lengthy and error prone procedure (though I > have it encapsulated in a (huge) shell script). > > 2. No integral mechanism for converting a root replica into the root > master. > > Unfortunately, my customer has no software support, so I can not submit > these as problem reports to Sun. > > -Marc > > Marc S. Gibian > Telos Consulting Services phone: (617) 377-6350 > PRISM/TFS email: gibian@stars1.hanscom.af.mil #!/bin/sh -f # - dump_all_tables # Could be run by cron... # First saves the old nis info then dump the new tables, # /var/nis and /etc/.rootkey echo "dump_all_tables: Starting ......\c" NIS_D="/export/home1/root/NIS_source" NIS_SAFE_D="/export/home1/root/NIS_safe" # # Save the old info... # ls ${NIS_D} | while read MY_FILE do /usr/bin/mv ${NIS_D}/${MY_FILE} ${NIS_SAFE_D} done # # Dump all the tables... # /usr/lib/nis/nisaddent -d passwd > ${NIS_D}/passwd /usr/lib/nis/nisaddent -d ethers > ${NIS_D}/ethers /usr/lib/nis/nisaddent -d group > ${NIS_D}/group /usr/lib/nis/nisaddent -d hosts > ${NIS_D}/hosts /usr/lib/nis/nisaddent -d netmasks > ${NIS_D}/netmasks /usr/lib/nis/nisaddent -d networks > ${NIS_D}/networks /usr/lib/nis/nisaddent -d netgroup > ${NIS_D}/netgroup /usr/lib/nis/nisaddent -d protocols > ${NIS_D}/protocols /usr/lib/nis/nisaddent -d rpc > ${NIS_D}/rpc /usr/lib/nis/nisaddent -d services > ${NIS_D}/services /usr/lib/nis/nisaddent -d -t timezone.org_dir timezone > ${NIS_D}/timezone /usr/lib/nis/nisaddent -d -t auto_home.org_dir key-value > ${NIS_D}/auto_home /usr/lib/nis/nisaddent -d -t auto_master.org_dir key-value > ${NIS_D}/auto_master /usr/lib/nis/nisaddent -d -t bootparams.org_dir key-value > ${NIS_D}/bootparams /usr/lib/nis/nisaddent -d -t auto_direct.org_dir key-value > ${NIS_D}/auto_direct /usr/lib/nis/nisaddent -d -t auto_apps.org_dir key-value > ${NIS_D}/auto_apps # niscat mail_aliases.org_dir > ${NIS_D}/aliases # /usr/lib/nis/nisaddent -d netid > ${NIS_D}/netid /usr/lib/nis/nisaddent -d publickey > ${NIS_D}/publickey /usr/lib/nis/nisaddent -d shadow > ${NIS_D}/shadow # # Save also the /var/nis directory in compress form and the /etc/.rootkey # /usr/bin/tar cfp ${NIS_D}/var_nis.tar /var/nis /usr/bin/compress ${NIS_D}/var_nis.tar # /usr/bin/cp -p /etc/.rootkey ${NIS_D}/safe.rootkey # echo "Done" exit SRDB ID: 10941 SYNOPSIS: NIS+ error messages DETAIL DESCRIPTION: The following NIS+ error messages appear on the client: - authdes_seccreate: unable to gen conversation key - authdes_marshal: DES encryption failure - authdes_validate: DES decryption failure - authdes_refresh: unable to encrypt conversation key These error messages are among those displayed on the server side: - _svcauth_des: no public key for - _svcauth_des: key_decryptsessionkey failed for - _svcauth_des: bad nickname - _svcauth_des: decryption failure for -_svcauth_des: encryption failure - _svcauth_des: corrupted window from - _svcauth_des: replayed credential from - _svcauth_des: invalid timestamp received from - _svcauth_des: timestamp is earlier than the one previously seen from - _svcauth_des: timestamp expired for SOLUTION SUMMARY: The following are some of the NIS+ error messages that may appear on the client or the server. This is not a complete list of all NIS+ messages. Another good reference besides this article includes the Solaris 2.4 manual, "Name Services Administration Guide". Client Messages A. authdes_seccreate: unable to gen conversation key Keyserv is unable to generate a random DES key. This is not recoverable without user/admin. intervention. Possible causes: - Keyserv is down or not responding. - Keyserv was restarted but other long running processes that use secure-rpc (or make nis+ calls) were not started. Possible action: - Check if keyserv is running/responding. If it is not then start it, start other processes, and do a keylogin. - Restart processes that log this error (most likely, automountd, rpc.nisd, and sendmail). B. authdes_marshal: DES encryption failure authdes_validate: DES decryption failure DES encryption/decryption of some authentication data failed. This is not recoverable without admin. intervention. Possible causes: - Corruptedargument to a library function. - Problem with DES chip (if used). Possible action: - Call Sun customer service and report the problem. C. authdes_validate: verifier mismatch The timestamp (T{n}) that the client sent to the server does not match the one received from the server. This is not recoverable within a secure-rpc session. Possible causes: - Client/server cache corrupted - sessionkey/timestamp. - Server deleted session key from cache for still active sessions. - Network data corruption. Possible actions: - Re-execute command D. authdes_marshal: DES encryption failure Client/server clock synchronization fails. This is automatically recoverable within a session. Possible causes: - Rpcbind on server not responding. Possible actions: - Admin. should manually synchronize the clocks if this message is followed by any timestamp related error(s). - Check remote rpcbind. E. authdes_refresh: unable to encrypt conversation key Keyserv fails to encrypt the session key with the publickey given. This is not automatically recoverable within a session. Possible causes: - Keyserv is dead or not responding. - Client has not keylogged in. - Client (host) does not have credentials. - DES encryption failure -- see B above. - Keyserv was restarted but not the other long running processes that use secure-rpc (or make nis+ calls). Possible actions: - Check if keyserv is running/responding. If it is not then start it and do a keylogin. - Restart processes that logs this error (most likely, automountd, rpc.nisd and sendmail). Server Messages F. _svcauth_des: no public key for Server cannot get clients' publickey. This is not recoverable without user/admin. intervention. Error returned to client = AUTH_BA DCRED. Possible causes: - Specified principal has no publickey. - Depending on the Name Service switch (/etc/nsswitch.conf), the name service specified is not responding. Possible actions: - Check if principal has "DES" credentials, if not add and keylogin. - Check if name service is responding. G. _svcauth_des: key_decryptsessionkey failed for Keyserv fails to decrypt the session key with the publickey given. This is not automatically recoverable within a session. Error returned to client = AUTH_BADCRED. Possible cause(s): - Keyserv is dead or not responding. - Server principal has not keylogged in. - Server principal (host) does not have credentials. - DES encryption failure. - Keyserv was restarted but other long running processes that use secure-rpc (or make nis+ calls) were not. Possible actions: - Check if keyserv is running/responding, if it is not then start it and do a keylogin. - Restart processes that logs this error (most likely, automountd, rpc.nisd and sendmail). H. _svcauth_des: bad nickname The nickname received from the client is invalid, probably corrupted along the way. This is not automatically recoverable within a session. Error returned to client = AUTH_BADCRED. Possible causes: - Congested network. Possible action(s): - None I. _svcauth_des: decryption failure for _svcauth_des: encryption failure DES encryption/decryption of some authentication data failed. This is not recoverable without admin. intervention. Error returned to client = AUTH_FAILED. Possible causes: - Corrupted argument to library function. - Problem with DES chip (if used). Possible actions: - Call Sun customer service and report the problem. J. _svcauth_des: corrupted window from principal The window sent does not match the one sent in the verifier. This is not recoverable without user/admin. intervention. Error returned to client = AUTH_BADCRED. Possible causes: - Server's key-pair changed, client used server's old public key and server has new secret key cached with keyserv. - Client's key-pair changed and client has notre-keylogged in on the client system (i.e. using client's old secret key), and server uses client new public key. - Network corruption of the data. Possible actions: - Re-keylogin on both client and server. - If using NIS+, check that the correct public key is cached in the directory object(s). K. _svcauth_des: replayed credential from This is seen if the server receives a request and finds an entry in its cache for the same client name and conversation key but the timestamp in the request is before the one in the cache. This is not recoverable without user/admin. intervention. Error returned to client = AUTH_REJECTEDCRED. Possible causes: - Clock skew between client and server. - Server receives subsequent requests in random order. Possible actions: - Synchronize client/server clocks. - Use tcp if supported by the application. L. _svcauth_des: invalid timestamp received from Timestamp received from client is corrupted or server decrypts using the wrong key. This is not recoverable without user/admin. intervention. Error returned to client = AUTH_BADVERF on initial requests, REJECTEDVERF on subsequent requests. Possible causes: - Congested network. - Server cached out the entry for this client. Possible actions: - Re-execute command. - Check the network load. M. _svcauth_des: timestamp is earlier than the one previously seen from Timestamp received from client (subsequent calls only) is earlier than the one seen previously from this client. This is not recoverable without user/admin. intervention. Error returned to client = REJECTEDVERF Possible causes: - Clock skew between client and server. - Server cached out the entry for this client. Possible actions: - Synchronize client/server clocks. - Re-execute command. N. _svcauth_des: timestamp expired for Timestamp received from client is not within the window sent. This is not recoverable without user/admin. intervention. Error returned to client = AUTH_BADCRED on initialrequests, REJECTEDVERF on subsequent requests. Possible causes: - Window too small to account for slow servers/network congestion. - Client and server clocks differ enough that the window cannot for the skew. - Server has cached out the client entry. Possible actions: - Synchronize client/server clocks. PRODUCT AREA: Gen. Network PRODUCT: NIS+ SUNOS RELEASE: Solaris 2.3 HARDWARE: any ---------- Forwarded message ---------- Date: Tue, 25 Feb 1997 19:36:22 +0100 (MET) From: Martin Trampler To: Stuart Kendrick Subject: nischmod n-r x.org_dir Hi Stuart, >>>>> "SK" == Stuart Kendrick writes: SK> I ran this command for the standard tables in the NIS+ space, SK> e.g. foreach x in (auto_home, auto_master, bootparams, cred, SK> ethers, group, hosts, mail_alaises, netgroup, netmasks, SK> networks, passwd, protocols, rpc, sendmailvars, services, SK> timezone). As I understand it, this removes read permission SK> for unauthenticated NIS+ users (NIS+ group "nobody") on all SK> tables. Well, actually all I can give you is an excerpt from the NIS+ Manpage: ----------------------- Note that for bootstrapping reasons, directory objects that are NIS+ domains, the org_dir subdirectory and the cred table within that subdirectory must have read access to the nobody principal. This makes navigation of the namespace possible when a client is in the process of locating its credentials. Granting this access does not allow the con- tents of other tables within org_dir to be read (such as the entries in the password table) unless the table itself gives "real" access rights to the nobody principal. ----------------------- Since I'm only a novice in the black magic of NIS+ I can't help you much farther, but here are my 2cents (actually pfennigs) to your questions: 1.) Why does removing read permission for group nobody on the services table disable telnet, ftp, etc.? It should do this only for users who lack nis+-credentials. These programs make all kind of system-calls (getprotobyname, gethostbyname) which depend on the tables in org_dir 2.) Why does removing read permission for group nobody cause this slow and painful death of the NIS+ space The secret key of nis+-principals is stored by a daemon (keyserv). It stays there, even after the principal logged out. The cached value is removed from the keyserv after an explicit "keylogout". I think (can't verify it) that the key also expires from keyserv after a specific amount of time if it's no longer used. If the principal needs to regain his secret key (which is encrypted with his login-passwd and stored in cred.org_dir) but cred.org_dir is not readable for him (who -at this stage- has not authentification) he can't get his encrypted key. (What I just wrote makes sense for "human" users. Workstations have their decrypted private key stored in /etc/.rootkey, so from the top of my head I can't tell why this should happen for Machines) 3.) Is there a way for me to fix this remaining cred table problem, short of nuking the NIS+ space and rebuilding it from scratch? >From here I can't tell. If I were you, I would (after having read the Manpages and Answerbook-Entries) do some "niscat -o ...", nisls ..., and nis... to get a better understanding of the problem. Have you tried an explicit "keylogin" as member of the admin group ? Sorry not to be able to solve your problem but maybe I could give you some hints what to look for. Cheers Martin Trampler ---------- Forwarded message ---------- Date: Tue, 18 Mar 1997 09:50:19 +1100 (EST) From: David Montgomery To: Stuart_Kendrick Subject: Re: nispopulate > > Hi David, > > OK, I'm interested in your expect script. Would it be possible for you to > send that to me? #! /usr/local/bin/expect -- set user $env(LOGNAME) stty -echo send_user "Password: " expect_user { timeout { send_user "\nSorry\n" exit } -re "(.*)\n" { set password $expect_out(1,string) } } send_user "\n" send_user "Verify Password: " expect_user { timeout { send_user "\nSorry\n" exit } -re "(.*)\n" { set password1 $expect_out(1,string) } } send_user "\n" if {[string compare $password1 $password]} { send_user "\nPassword mismatch.\n" exit } spawn /bin/keylogin expect "Password:" send "$password\r" spawn /bin/chkey expect "Secure-RPC password for $user:" send "nisplus\r" expect "login password for $user:" send "$password\r" stty echo expect eof > More importantly, though, I am having trouble with the nisaddent commands. > Sometimes they work ... and sometimes they don't. By "work" I mean > sometimes the user can login afterward ... and sometimes they can't. > > And I can't even change their password from root. If I type "passwd > {name}", I am prompted for their *current* login password ... which of > course I don't know. > > Of course, sometimes the nisaddent procedure works fine, users can login, > can run nisclient, everything is wonderful. > > Have you had this experience? Or does nisaddent work reliably for you? I had trouble with it months ago when I started playing around with a test namespace and since time was running out I put it in the "too hard basket". Now that the start of term rush is almost over I'll be looking at this as well as other methods of making NIS+ administration simpler. > > --sk > > On Sat, 8 Mar 1997, David Montgomery wrote: > > > Hello Stuart, > > > > > > > > I want to import an /etc/passwd and an /etc/shadow file into the NIS+ > > > space. > > > > > > nispopulate -v -F -d {domain} -l {string} -p /nis+files If I use > > > the above command (where /nis+files contains passwd and shadow and > > > "string" is an eleven character alpha-numeric string), then I get > > > appropriately populated passwd and cred tables ... but those users > > > can't log in. I can reset their password, using "passwd" from the > > > root account, and then they can log in. And run nisclient -u to sync > > > their NIS+ and login passwords. But that is tedious. > > > > > > nisaddent -mvf passwd passwd nisaddent -mvf shadow shadow If I run > > > these two commands (after cd'ing to /nis+files), then users can log > > > in fine. But they have no credentials. I have to run nisclient -c for > > > each and every one. Then, each user can run nisclient -u to sync NIS+ > > > and login passwords. Tedious. > > This is the approach I took. After adding new users I have a script to > > run nisclient -c for them. I also have an expect script which prompts > > for the user's login password then does a keylogin and chkey (using the > > default network password which I use). This way the users doesn't need > > to know anything about a "network password". It worked ok for about > > 1000 accounts last week. Do you want a copy of the expect script? > > > > > > > > Neither solution scales to large numbers. Now, I could write an > > > expect script which automates the manual, per-user steps, but this > > > would be a lot of work. Isn't there a canned strategy? Why doesn't > > > nispopulate work? (or, rather, it works fine ... but no one can log > > > in until I've reset their passwords.) > > > > > > And is there anyway around requiring each user to run nisclient -u? > > > Or is that an unavoidable step? > > > > > > Solaris 2.5.1 with a selection of the latest patches. > > > > > > > David Montgomery > > Department of Computer Science > > University of Newcastle > > University Drive Phone: +61 49 216174 > > Callaghan 2308 NSW Fax : +61 49 216929 > > AUSTRALIA Email: david@cs.newcastle.edu.au David Montgomery Department of Computer Science University of Newcastle University Drive Phone: +61 49 216174 Callaghan 2308 NSW Fax : +61 49 216929 AUSTRALIA Email: david@cs.newcastle.edu.au SRDB ID: 15047 SYNOPSIS: Unable to authenticate NIS+ server DETAIL DESCRIPTION: "nisaddcred" failed with the error message "Unable to authenticate NIS+ server" POSSIBLE CAUSE or USER ERRORS ----------------------------- (In no particular order.) - Change root password in /etc/passwd on a NIS+ server without re-encrypting the secret key stored in the cred table. Should do "chkey -p" immediately after changing the password. *Note that this problem may lurk for some time. If the superuser secret key is already stored in the keyserv when the root password is changed, you'll probably not see any problem until the keyserv is restarted (usually at the next system reboot). - Remove DES cred table entry for any NIS+ server. - Overwrite existing credentials, by executing nisaddcred, chkey (without "-p"), or newkey for any NIS+ server. - Keyserv killed and not restarted on any NIS+ server. - Keyserv restarted on NIS+ server, without restarting rpc.nisd. The rpc.nisd has an open connection to the existing keyserv, and is unable to re-open that connection. - /etc/.rootkey removed, or replaced with a copy that doesn't match the secret key stored in the cred table, and internally in the NIS+ table headers. - The publickey entry in /etc/nsswitch.conf isn't just "nisplus", so secure RPC keys can be obtained from some source (NIS, files) that is inconsistent with the NIS+ tables. SOLUTION SUMMARY: Several SRDBs discuss recovering from the lost or corrupted encrypting key, but there is no sure and safe scheme to retrieve the public key once it is mingled. The following two methods will bring the NIS+ back in operation. 1) Rule #1 with NIS+. BACK UP the /var/nis directory of all the NIS+ servers. Recovery from tape always works. 2) If that is not available, dump the contents of NIS+ namespace, and reinitialize the NIS+ server. Run the following Bourne-shell script: #!/bin/sh # GENERIC NIS+ DUMP SCRIPT if [ ! -d /etc/nis+files ] then mkdir /etc/nis+files fi cd /etc/nis+files /usr/lib/nis/nisaddent -d aliases > aliases /usr/lib/nis/nisaddent -d bootparams > bootparams /usr/lib/nis/nisaddent -d ethers > ethers /usr/lib/nis/nisaddent -d group > group /usr/lib/nis/nisaddent -d hosts > hosts /usr/lib/nis/nisaddent -d netgroup > netgroup /usr/lib/nis/nisaddent -d netid > netid /usr/lib/nis/nisaddent -d netmasks > netmasks /usr/lib/nis/nisaddent -d networks > networks /usr/lib/nis/nisaddent -d passwd > passwd /usr/lib/nis/nisaddent -d protocols > protocols /usr/lib/nis/nisaddent -d publickey > publickey /usr/lib/nis/nisaddent -d rpc > rpc /usr/lib/nis/nisaddent -d services > services /usr/lib/nis/nisaddent -d shadow > shadow /usr/lib/nis/nisaddent -d timezone > timezone /usr/lib/nis/nisaddent -d -t auto_home.org_dir key-value > auto_home /usr/lib/nis/nisaddent -d -t auto_master.org_dir key-value > auto_master # End of script Clean out leftover NIS+ material and processes by following these steps: 1. Issue the following commands from the Bourne shell: /etc/init.d/rpc stop rm -f /etc/.rootkey rm -rf /var/nis/* cp /etc/nsswitch.files /etc/nsswitch.conf /etc/init.d/rpc start Login and initialize NIS+ on the new root master by following these steps: 1. Login as root on new root master. 2. Set the domain name with the following command: % domainname top.com NOTE: DO NOT USE PERIOD AFTER COM! 3. Re-direct domainname output into /etc/defaultdomain with the following command: % domainname > /etc/defaultdomain 4. Run the nisserver script. For YP compat support, use the following command: % /usr/lib/nis/nisserver -r -Y For default support, use the following command: % /usr/lib/nis/nisserver -r 5. Populate the new NIS+ tables with the nispopulate command. If you want to restore your original data, change directory to the directory you used to backup your original: % /usr/lib/nispopulate -F -p / where is the location of the original NIS+ data. The root master is now set up. You must change each NIS+ client to match the new domain name, IP address network prefix (if required), and client binding. You updated the hosts map in /etc/nis+files to reflect all new IP address assignments, host names, and so forth. If the IP address needs to be changed on the client to match the new network portion of the NEW ROOT MASTER's IP address, do the following: 1. Login as root on client. 2. Run the/usr/sbin/sys-unconfig command on the client. This script removes all references to the old IP address, host name, network service information and so forth. 3. Enter the new information after the system reboots from the sys-unconfig command. 4. When sys-unconfig asks for Network Information Service, close NIS+ client. PRODUCT AREA: Gen. Network PRODUCT: NIS+ SUNOS RELEASE: Solaris 2.x HARDWARE: any refer to infodoc #11988 NIS+ PSD/FAQ edit your /etc/nsswitch.conf file after you make the system an nis+ root master, replica, or client these lines should appear as follows (assuming you also use dns for name service lookups) hosts: files nisplus dns rpc: files nisplus services: files nisplus netmasks: files nisplus Note Adminsuite 2.3 is released and it also has patches 2.5.1 Make sure your systems are up to rev for the patches 103612-26: SunOS 5.5.1: libc, libnsl, nis_cachemgr and rpc.nisd patch 103903-03: SunOS 5.5.1: /kernel/drv/le patch 103640-08: SunOS 5.5.1: kernel patch 103630-06: SunOS 5.5.1: ip ifconfig arp udp icm 103582-12: SunOS 5.5.1: /kernel/drv/tcp and /usr/bin/netstat patch 103738-03: SunOS 5.5.1: /usr/sbin/syslogd patch 103699-01: SunOS 5.5.1: ping dumps core when packet is blocked 104317-01: SunOS 5.5.1: nfsd patch 104166-01: SunOS 5.5.1: usr/lib/nfs/statd patch 104334-01: SunOS 5.5.1: lockd patch 104672-02: SunOS 5.5.1: usr/lib/fs/nfs/mount patch 103591-07: SunOS 5.5.1: /kernel/fs/ufs and /usr/lib/fs/ufs/fsck fixes 103847-02: SunOS 5.5.1: /usr/lib/fs/ufs/ufsdump patch 104490-01: SunOS 5.5.1: ufsrestore patch 104742-01: SunOS 5.5.1: usr/lib/fs/ufs/mkfs patch 104266-01: SunOS 5.5.1: inetd patch 104654-02: SunOS 5.5.1: automountd patch 103600-14: SunOS 5.5.1: nfs, tlimod and rpcmod patch 104331-02: SunOS 5.5.1: rpcbind patch 103597-01: SunOS 5.5.1: sockmod fix 103502-04: Soltice AdminSuite 2.2 AdminSuite patch 103558-07: SunOS 5.5.1: admintool patch 103680-01: SunOS 5.5.1: nscd/nscd_nischeck rebuild for BIND 4.9.3 103686-02: SunOS 5.5.1: rpc.nisd_resolv patch 103643-04: SunOS 5.5.1: /usr/lib/nis/nisaddent fixes 103785-01: SunOS 5.5.1: nss_nisplus.so.1 patch 103995-01: SunOS 5.5.1: rpc.nispasswdd patch 104255-01: SunOS 5.5.1: POINT PATCH: 1257084 - /usr/lib/nss_nis.so.1 103770-03: SunOS 5.5.1: nistbladm patch Generic compilation tip sheet for nis+ questions ___________________________________________________________________________ To prepare for the upgrade of the root master to the next release of the o/s Run checkpoint on the original root master. Perform a zero level dump of the root master. Create the ascii files from which you will rebuild the root master (see below for commands in a script) Copy /etc/nsswitch.files to /etc/nsswitch.conf remove or rename /etc/.rootkey , /var/nis tree, and /etc/defaultdomain then upgrade to 2.5.1 reboot to single user mode and apply the recommended 2.5.1 patches OR start with a fully patched next release of o/s networked system Then make this system a nis+ root master following guidelines in the Solaris documentation using the ascii files as the source for the build of the nis+ database files. *Note /etc/nsswitch.conf for all systems, you will need to edit on root master and replica afer these are built. hosts: files nisplus dns rpc: files nisplus services: files nisplus netmasks: files nisplus Assure that client machines can bind to the new root master. Follow instructions to make another new o/s system a replica server. The root master and replicas should be at the same o/s version. That's it. _____________________________________________________________________________ Run checkpointing on a regular basis so that the log file is flushed to permanent disk resident database entries. We recommend this order.... nisping -C your.domain.name. nisping -C org_dir.your.domain.name. nisping -C group_dir.your.domain.name. nisping your.domain.name. nisping org_dir.your.domain.name. nisping groups_dir.your.domain.name. Commands should be put in cron and run at least once a day; and, more often, if there are a lot of NIS+ transactions throughout the day that create a large log file. Refer to the following Solaris documentation NIS+ and DNS Setup and Configuration Guide-this is about 1/4 inch thick and it is essential that you read this manual and then go on to use this next document for reference NIS+ and FNS Adminsitration Guide This script can be used to make sure you have ascii files from which to rebuild a nis+ root master. You should run this periodically as an emergency procedure. Also make sure you have a zero level dump of /etc/.rootkey and /var/nis tree as the root master can be rebuilt if you can restore the files and directory tree. Both methods should be used to insure that you can bring the system back promptly. Both in the event of a hardware failure or if the system cannot be accessed for other reasons (root master password has been changed improperly). ___________________________________________________________________________ Instructions for dumping the NIS+ tables to ascii files This is shell script that will use nisaddent to dump the current NIS+ tables to ascii files in the /etc/nis+files directory, which will be created if it does not already exist. Notice that it uses niscat to dump the automount tables. #!/bin/sh if [ ! -d /etc/nis+files] then mkdir /etc/nis+files fi cd /etc/nis+files /usr/lib/nis/nisaddent -d aliases > aliases /usr/lib/nis/nisaddent -d bootparams > bootparams /usr/lib/nis/nisaddent -d ethers > ethers /usr/lib/nis/nisaddent -d group > group /usr/lib/nis/nisaddent -d hosts > hosts /usr/lib/nis/nisaddent -d netgroup > netgroup /usr/lib/nis/nisaddent -d netid > netid /usr/lib/nis/nisaddent -d netmasks > netmasks /usr/lib/nis/nisaddent -d networks > networks /usr/lib/nis/nisaddent -d passwd > passwd /usr/lib/nis/nisaddent -d protocols > protocols /usr/lib/nis/nisaddent -d publickey > publickey /usr/lib/nis/nisaddent -d rpc > rpc /usr/lib/nis/nisaddent -d services > services /usr/lib/nis/nisaddent -d shadow > shadow /usr/lib/nis/nisaddent -d timezone > timezone /usr/lib/nis/niscat auto_home.org_dir > auto_home /usr/lib/nis/niscat auto_master.org_dir > auto_master /usr/lib/nis/niscat auto_direct.org_dir > auto_direct __________________________________________________________________________ How to modify an entry in a NIS+ table Enter bourne shell by typing sh at root prompt nistablm -m new-entry old entry for example from page 213 of the NIS+ and FNS Admin Guide nistbladm -m name='R&D' Site=SanFran Manager=kuznetsov \ [name='R&D', Site=SanFran,Manager=vattel], depts.wiz.com. nistbladm -m name=username home=newhomedir \ [name=username , home=oldhomedir] , passwd.org_dir.domain. However, the nis+ team recommends you dump the passwd table edit it and rebuild the map when you need to make changes to hundreds of entries _____________________________________________________________________________ Adding a nis+ user to a group #nistbladm -m members=kevinb,charlie,bruce [name=sysadmin]group # niscat group root::0:root other::1: bin::2:root,bin,daemon sys::3:root,bin,sys,adm adm::4:root,adm,daemon uucp::5:root,uucp mail::6:root tty::7:root,tty,adm lp::8:root,lp,adm nuucp::9:root,nuucp staff::10: daemon::12:root,daemon sysadmin:*:14:kevinb,charlie,bruce nobody::60001: noaccess::60002: nogroup::65534: _______________________________________________________________________________ Instrucions for modifying an automount table to be maintained by nis+ USING THE BOURNE SHELL CREATE THE AUTO_DIRECT TABLE FIRST # nistbladm -c automount_map key=S value=S auto_direct.org_dir.labs.com. POPULATE THE AUTO_DIRECT TABLE FROM THE ASCII FILE /tmp/auto_direct # nisaddent -rf /tmp/auto_direct -t auto_direct.org_dir key-value VERIFY THAT THE TABLE WAS POPULATED # niscat auto_direct /usr/dist2 -ro,intr,noquota newdist:/usr/dist /opt -ro,intr,noquota newdist:/opt ___________________________________________________________________________ This procedure will remove a nis+ replica: the order of the nisping -C is important do the domainname first. as root user on root master system: 1) nisrmdir -f -s org_dir.yourdomainname. ^ you need this end dot example: nisrmdir -f -s roy org_dir.mdc.com. 2) nisrmdir -f -s groups_dir.yourdomainname. nisrmdir -f -s roy groups_dir.mdc.com. 3) nisrmdir -f -s yourdomainname. nisrmdir -f -s roy mdc.com. 4) nisclient -co (This overwrites creds for replica machine, it asks for root passwd of ex replica) as root user on ex replica: 1) rm -r -f /var/nis/* 2) rm /etc/.rootkey 3) ps -ef |grep nis , kill pids for all nisd's and nis_cachemngrs 4) nisclient -i -d -h ex: nisclient -i -d mdc.com. -h pat (complains about cant find /var/nis coldstart file ignore this) 5) reboot ex replica ( it will now be a nis+ client only).. to redo as replica, as root user on ex replica: 1) start rpc.nisd on as root user on root master system: 1) nisserver -R -d -h ex: nisserver -R -d mdc.com. -h roy 2) nisping -C 3) nisping -C groups_dir. 4) nisping -C org_dir. ex: nisping -C org_dir.mdc.com. 5) reboot replica.. sometimes the nisping -C complains that checkpoint failed. Kill all nisd's on replica and restart one.. one time only, and try again. also: It will complain that nisd is busy when you do nisping -C groups_dir. sometimes because the first checkpoint of org_dir is still going , try again in 5 minutes. ______________________________________________________________________________ NIS+ tables - question > > I have created an NIS+ table. printers.org_dir of type printers. I > would like to populate it from a file. Unfortunately, the nisaddent > command only supports the 17 standard table types. Do you have a quick > way (short of perl scripting) of populating this table from my existing > file? Assuming that you are running in the bourne shell and the printer.org_table is empty at this point try the following: nisaddent -rf -t printer.org_dir key-value. This will put everything that is in the ascii file into the nis+ table, it does a complete replace of the table, another words everthing the is in the table prior to executing this command will be over written. If you want to merge the data then use the -m option instead of the -r option. This is explained in the man pages of nisaddent. _____________________________________________________________________________ Instructions for internet address change on NIS+ replica To change ip adress for root replica.. 1) change address of replica in nis table.. a) vi /etc/hosts on master and nisaddent -rf /etc/hosts hosts. 2) nisping org_dir 3) nisupdkeys -a -H org_dir 4) nisupdkeys -a -H groups_dir 5) nisupdkeys -a -H `domainname` 6) change address in /etc/hosts on replica and reboot it.. thats it>> All clients will have wrong ip address cached untill time to live expires and refreshes them. Unless you do a kill; 1) nis_cachemgr 2) nisinit -c -H rootmaster 3) nis_cachemgr -i ____________________________________________________________________________ adduser script # more adduser # #!/bin/sh -v /usr/bin/nistbladm -D owner=$1.labs.com. -a name=$1 uid=$2 gid=$3 home=/home/$1 shell=/bin/sh shadow=::::::\ passwd /usr/lib/nis/nisclient -co $1 /usr/bin/nischown $1 [cname=$1,auth_type=DES]cred /usr/bin/passwd -r nisplus $1 1)This works for 2.5 for 2.4 use nispasswd instead of passwd -r nisplus 2) replace any occurance of labs.com. with actual domainname example adduser bruce 1005 30 ___________________________________________________________________________- Instructions for nis+, how to modify automount map on root master #!/bin/sh if [ ! -d /etc/nis+files] then mkdir /etc/nis+files cd /etc/nis+files /usr/lib/nis/niscat auto_master.org_dir > master vi master and delete the +auto_master line nisaddent -r -f /etc/nis+files/master -t auto_master.org_dir key-value nisping org_dir if you have replicas niscat auto_master.org to verify change took place on the automount client machine automount -v _____________________________________________________________________________ Instructions for changing all ips in nis+ domain This is a correction to first mail 1) login to root master and dump tables to flat files. a) mkdir /etc/nis+files b)cd /etc/nis+files /usr/lib/nis/nisaddent -d aliases > aliases /usr/lib/nis/nisaddent -d bootparams > bootparams /usr/lib/nis/nisaddent -d ethers > ethers /usr/lib/nis/nisaddent -d group > group /usr/lib/nis/nisaddent -d hosts > hosts /usr/lib/nis/nisaddent -d netgroup > netgroup /usr/lib/nis/nisaddent -d netid > netid /usr/lib/nis/nisaddent -d netmasks > netmasks /usr/lib/nis/nisaddent -d networks > networks /usr/lib/nis/nisaddent -d passwd > passwd /usr/lib/nis/nisaddent -d protocols > protocols /usr/lib/nis/nisaddent -d publickey > publickey /usr/lib/nis/nisaddent -d rpc > rpc /usr/lib/nis/nisaddent -d services > services /usr/lib/nis/nisaddent -d shadow > shadow /usr/lib/nis/nisaddent -d timezone > timezone /usr/bin/niscat auto_home.org_dir > auto_home /usr/bin/niscat auto_master.org_dir > auto_master /usr/bin/niscat auto_direct.org_dir > auto_direct 2) login to clients as root, one at a time. This applies to replicas also. a) rm -f -r /var/nis/* b) rm /etc/.rootkey c) rm /etc/defaultdomain d) vi /etc/hosts and change ip addresses of host and root machines e) cp /etc/nsswitch.files /etc/nsswitch.conf , halt machine 3) login to master as root a) rm -f -r /var/nis/* b) rm /etc/.rootkey c) vi /etc/hosts and change ip addresses of all machines d) cp /etc/nsswitch.files /etc/nsswitch.conf e) rm /etc/defaultdomain f) init 6 (this reboots master) 4) login to master as root user and ; a) add /usr/lib/nis to path example: in csh, setenv PATH $PATH:/usr/lib/nis b) nisserver -r -d domainname. c) cd /etc/nis+files, mv netid /tmp , mv publickey /tmp . d) vi hosts and change ip adresses.. e) nispopulate -F -d domainname. f) nisaddent -d publickey|grep unix.yourmastername >> /tmp/publickey (this will add masters current creds to bottom of file) g) vi /tmp/publickey and remove first entry for root master after making sure current cred for rootmaster added to bottom. h) nisaddent -rv -f /tmp/publickey publickey (this resets all users rpc passwd to the one before ip change) i) nisaddent -rv -f /tmp/netid netid j) nisping -C domainname. 5) reboot clients and run nisclient -i -d domainnanme. -h rootmaster 6) If you had replicas start rpc.nisd on those clients one at a time. 7) On root master run nisserver -R -d domainname. -h replica 8) nisping all three directory objects nisping -C org_dir , nisping -C groups_dir, nisping -C domainname. 9) reboot replica 10) do 6 thru 9 for next replicas.. note: This will work for domain change also just skip step 2 d , 3 c, 4 d. ________________________________________________________________________________ This procedure for changing the ip address for a nis+ root master server assumes the following: 1) You are either directly logged into the console as root or you have telneted into the server as root. 2) Your credentials are good and the server is authenicated. 3) You are running the bourne shell 4) You have read the entire procedure and understand it before you start, if not please ask questions before starting. 5) You are familiar with nis+ Change the root master`s ip address in the nis+ hosts table. This is done on the root master and the single quote found in these commands are located on the double quote and single quote key, not to be confused with the quote on the tilda key that is used for command substitution. nistbladm -m addr= '[name=],hosts.org_dir' nistbladm -m addr= '[name=loghost],hosts.org_dir' Update the universal address of the root master server. Don't forget the trailing dot '.'. This is done on the root master. nisupdkeys -a org_dir.`domainname`. nisupdkeys -a groups_dir.`domainname`. nisupdkeys -a `domainname`. Change ip address of the root master in /etc/hosts. This is done on the root master. vi /etc/hosts and change the address Reboot root master Kill the cache manager on the root master ps -ef | grep nis kill On the root replica, change ip address of the root master in /etc/hosts vi /etc/hosts and change the address Make sure the replicas /etc/nsswitch.conf hosts entry has files first. On the root replica, stop rpc, then get a new cold_start file, then kill the cache manager, and then start rpc. /etc/init.d/rpc stop nisinit -c -H /etc/init.d/rpc start kill On the root master, perform nisping to transfer the new root.object nisping -r (this may take several minutes depending on your network, so be patient). nisping org_dir.`domainname`. nisping groups_dir.`domainname`. nisping `domainname`. Verify that the domain still functions niscat, nisls, etc.... Restart the cache manager on the root master and the replica. nis_cachemgr -i Get new cold_start files for all nis+ clients by running the following commands on the nis+ clients. ps -ef | grep nis kill nisinit -c -H hostname nis_cachemgr -i _______________________________________________________________________________ How to add user without adminsuite on 2.5 go into bourne shell by typing sh at root prompt rootmaster# sh #nistbladm -a name=bruce passwd= uid=30001 gid=30005 gcos=Bruce home=/ shell=/bin/csh shadow=:::::::: passwd.org_dir #nisping org_dir (if replicas) #niscat passwd.org_dir | grep bruce bruce::30001:30005:Bruce:/:csh::::::::: # nisclient -co bruce You will be adding DES credentials in domain xxx.com. for bruce ** nisclient will overwrite existing entries in the credential ** table for hosts and users spedified above. Do you want to continue? (type 'y' to continue, 'n' to exit this script) y checking xxx.com. domain... checking cred.org_dir.xxx.com. permission... adding LOCAL credential for bruce... adding DES credential for bruce... Adding key pair for unix.30001@labs.com (bruce.labs.com.). Enter bruce's login password: Retype password: For all new NIS+ users added, you will need to update their keys on all machines that they are currently logged in by running keylogin(1), chkey(1), or nisclient(1M). # nispasswd bruce New password: Re-enter new password: NIS+ password information changed for bruce The credential information for bruce will not be changed. User bruce must do the following to update his/her credential information: Use NEW passwd for login and OLD passwd for keylogin. Use "chkey -p" to reencrypt the credentials with the new login passwd. He/she must keylogin explicitly after his/her next login. #nisping org_dir(if replicas) # niscat passwd.org_dir | grep bruce bruce:QJAcjcbLZHboA:30001:30005:Bruce:/:/bin/csh:9612:-1:-1:-1:-1::0 _____________________________________________________________________________ The NIS+ PSD contains the same mistake I made after reading the man page. nisaddent -m (for merge) does not "add" records. The PSD says: 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/hosts hosts The key thing that is wrong is "you can put new entries into a file, and..." ^^^ If you put only the *NEW* entries in the file, then, when you are done, you will have **ONLY** the new entries in the table. The difference between -m (merge) and -r (replace) is *HOW* it does the work not *WHAT* it does. They both make the table look like the file. -r does it by removing everything in the table and loading the file into it. -m has the same result, but accomplishes it by a more complex method: - compare the table to the file - ignore all the records which are the same in both - update the records that are different with the contents of the file - remove the records in the table which are not in the file - add the records in the file which are not already in the table The intent is that -m will be much more efficient in many cases. If you only have a few adds/modifies/deletes, use nisaddent -m If more is changing than remaining the same, use nissaddent -r ____________________________________________________________________________ NIS+ Credential Fix Do all the the following as root in the bourne shell *** kill nis_cachemgr and startup rpc.nisd at level zero on all nis+ servers. *** kill on all nis+ servers. kill on all nis+ servers. rpc.nisd -S 0 on all nis+ servers. *** Now redo the creds for the root master on the root master *** nisaddcred -p unix.@`domainname` -P .`domainname`. des enter the root passwd when prompted for passwd. (If the above command hangs then rm /etc/.rootkey and kill keyserv) *** next do the following on the root master *** rm /etc/.rootkey kill < PID for keyserv> *** EXECUTE THE FOLLOWING COMMANDS ON THE ROOT MASTER, NOTE THE TRAILING DOTS THAT YOU MUST HAVE ON THE NEXT 3 COMMANDS *** nisupdkeys org_dir.`domainname`. nisupdkeys groups_dir.`domainname`. nisupdkeys `domainname`. *** nisping all 3 objects on the root master *** nisping org_dir nisping groups_dir nisping `domainname` *** On the root master execute the following. *** keylogin -r enter the root passwd when prompted *** EXECUTE THE FOLLOWING COMMANDS ON THE REPLICA SERVERS, NOTE THE TRAILING DOTS THAT YOU MUST HAVE ON THE NEXT 3 COMMANDS *** nisupdkeys org_dir.`domainname`. nisupdkeys groups_dir.`domainname`. nisupdkeys `domainname`. *** Now startup rpc.nisd at level 2 and startup nis_cachemgr on all servers *** kill rpc.nisd -S 0 rpc.nisd /usr/sbin/nis_cachemgr -i ____________________________________________________________________________ To change a user's password. You will need to install Adminsuite 2.2 or 2.3 and corresponding patches in order to change passwords for a user via the gui interface to the databases when you do not know the user's previous password (for instance when the user forgets the password). The only way that you can change a password for a user from the command line mode is if you know the previous password, for instance when a new account has been setup. Then you can use password -r nisplus username and follow the directions. Use man on password for additional information. Thank u all ... __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/Received on Fri Aug 24 11:53:17 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:25:02 EDT