NIS PSD/FAQ

1.0: About NIS  

2.0: Debugging NIS

  2.1: ypwhich
  2.2: ypcat
  2.3: ypmatch
  2.4: getent
  2.5: Files
  2.6: The Network
  
3.0: Common How Tos

  3.1: How to Setup a NIS Master Server?
  3.2: How to Setup a NIS Slave Server?
  3.3: How to Add a New NIS Slave to an Existing NIS Environment?
  3.4: How to Setup a SunOS NIS Client?
  3.5: How to Setup a Solaris NIS Client?
  3.6: How to Run NIS from a Remote Subnet?
  3.7: How to Remove NIS From a SunOS Client?
  3.8: How to Remove NIS From a SunOS Server?
  3.9: How to Remove NIS From a Solaris Client?
  3.10: How to Use DNS without NIS?
  3.11: How to Start yppasswd on the NIS Master Server?
  3.12: How to Change a password in the NIS map?
  3.13: How to Change IP address, Host Name, or domainname of a NIS machine?
  3.14: How to Set Up Secure NIS?
  3.15: How to Use Netgroups?

4.0: Some Frequently Asked Questions

  4.1: Miscellaneous Questions
  4.2: ypinit Problems
  4.3: NIS make Problems
  4.4: NIS Update Problems
  4.5: General NIS Client Problems
  4.6: ypcat Problems
  4.7: NIS passwd Problems

5.0: Patches

  5.1: SunOS NIS Patches
  5.2: Solaris NIS Patches

6.0: Known Bugs & RFEs

  6.1: Bugs

1.0: About NIS 

This PSD documents a wide variety of information concerning NIS as implemented in the SunOS and Solaris operating systems. It is intended as both an introduction to NIS, and as a guide to the most common problems. There are many more complete references to NIS, a few of which are noted in section 7.0. In this document, the terms YP and NIS should be understood to be interchangeable. YP was the original name for the information service now known as NIS. NIS/YP is not the same thing as NIS+. The following terms are crucial for an understanding of NIS: A NIS SERVER is a machine which responds to requests for NIS service. The MASTER server actually contains all of the files which the NIS maps are built from, while the SLAVE servers just contain copies of those maps. The YPSERV daemon is run on all servers. It is what answers NIS requests. YPXFRD is usually run on the master server, to speed up transfers to the slaves. A NIS CLIENT is a machine which is allowed to access the NIS maps. The YPBIND daemon takes care of making these requests. All of NIS is bundled with SunOS. However, on Solaris versions from 2.0 up to 2.5.1, the bundled software only allows machines to be set up as NIS clients (Solaris 2.6 now has the NIS server side software back in it). If you want to set up a pre-2.6 Solaris machine as a NIS server you will need to download or purchase NSKIT. Please contact your local Sun sales office. A seperate PSD exists for NSKIT specific issues if you are running into problems involving the NSKIT, you should request the NSKIT PSD from SunService. For all intents and purposes NSKIT on Solaris 2.x is administered the same as NIS on SunOS 4.1.x except for some minor differences such as directory locations and source and Makefile differences 2.0 Debugging NIS 

2.1: ypwhich 

ypwhich will show you which NIS server you are currently bound to: %% /usr/bin/ypwhich rainbow-16 This is useful to know, because in some cases, one particular NIS server will give incorrect info, while everything else is fine. If you find that only one of your slave servers gives outdated information, you will probably want to follow the instructions in Section 3.3, to update your ypservers map information. You can also use ypwhich to learn what server a remote machine is bound to. This might be useful if you wish to examine load balance, or something similar: %% /usr/bin/ypwhich rainbow-16 rainbow The above showed that the remote machine, rainbow-16, is bound to the server rainbow. 

2.2: ypcat 

ypcat is one of the most obvious commands to use for NIS debugging. If, for example, a user can not log in, you might want to consult ypcat, to verify that their passwd does appear in the NIS map: %% /usr/bin/ypcat passwd ypcat will not always gives you the full info, because by default it does not show the column that the map is being indexed (or keyed) off of. To ensure that you are seeing everything, you can run ypcat with the -k option: %% /usr/bin/ypcat -k passwd 

2.3: ypmatch

ypmatch can be used to look at an individual item in a NIS map, with the follow syntax: %% ypmatch entry mapname For example, to find the host 'psi' in the hosts map, you would type: %% ypmatch psi hosts Essentially, the information you get with ypmatch is the same as that available with ypcat, but is slightly easier to read. 

2.4: getent 

On a Solaris machine, you can use the command getent to look up NIS entries, as follows: %% getent mapname entry (opposite order of ypmatch) For example: %% getent root passwd The difference between ypmatch and getent is that ypmatch only looks up entries in the NIS maps, while getent consults the nsswitch.conf file, and then looks up the query according to that order. For example, if nsswitch.conf reads as follows: passwd: files nis The above getent would first have looked at the /etc/passwd file, then the NIS passwd map. Essentially, getent should do exactly the same lookup as any normal program would. If you find that you have to troubleshoot something specific in your NIS database you should use the yp commands instead to make sure you dont get the information from your local files or DNS. getent is only documented as able to consult passwd and groups. However, you may be able to getent hosts and other databases on newer OS'es. 

2.5: Files 

If the above commands do not make it clear what your problem is, you might want to consult the NIS files. If a NIS server is doing something incorrect during map distribution, you should look at the /var/yp/Makefile on the NIS server. It is particularly helpful to compare the Makefile to the original one that was shipped with the system: %% diff /var/yp/Makefile /usr/lib/NIS.Makefile If the files are substantially different, you should revert to the original, and see if that fixes the problem. Note that Solaris NSkit or Solaris 2.6 does not include an original Makefile in /usr/lib. As with most config files you should consider making a backup copy of the file before making changes. If a Solaris NIS Client is not correctly accessing NIS, you should consult the file /etc/nsswitch.conf, and verify that it includes a reference to NIS. SunOS NIS clients, once bound to a NIS domain, will continue to use NIS and will not look at their local files for any lookups. 

2.6: The Network 

If all else fails, especially in the case of very intermittent problems, you may wish to investigate your overall network for problems. Most problems of this sort are due to either hardware issues or performance problems. These topics are beyond the scope of the help that SunService can provide. Consult Sections 8.0 amd 9.0 for where you can get additional assistance from within Sun. 3.0 Common How Tos 

3.1: How to Setup a NIS Master Server 

First, initialize the NIS Makefile: # cp /usr/lib/NIS.Makefile /var/yp/Makefile (Note that on Solaris 2.x you will already have a Makefile in that directory providing you have NSKit installed or are running 2.6 or newer.) Afterwards, you will want to set your nis-domain. In the example below, simply replace 'example-name' with the name that you have chosen for your nis-domain. Note that this nis-domain name does not have to have any relationship to your DNS domain name. It should simply be a name which is set identically on all your NIS machines. It is actually more secure to use a nis-domain-name that is totally unrelated to your DNS domain. # domainname example-name # domainname > /etc/defaultdomain If you are planning on using DNS with NIS, you will need to change the /var/yp/Makefile to reflect this. Remember that SunOS 4.1.x machines cannot do DNS lookups on their own and have to submit their requests to the NIS server which then does the DNS lookup for them. Near the top of the Makefile you will find the following lines: # Set the following variable to "-b" to have NIS servers use the domain name # resolver for hosts not in the current domain. #B=-b B= In order for DNS to work with NIS, you must change the last two lines, as follows: B=-b #B= Finally, you can initialize NIS by running the ypinit script. When ypinit queries you for server names, make sure you include all slave servers that you are planning to set up in the near future: # cd /var/yp # /usr/etc/yp/ypinit -m If you wish to immediatelly start NIS, you can simply start the NIS daemons on your server: # ypserv # ypbind # ypxfrd Afterwards, you should make sure that ypserv, ypbind and ypxfrd are all in your /etc/rc.local file (if on SunOS 4.1.x), and not commented out. On Solaris 2.x these daemons will be started by the S71rpc script in your /etc/rc2.d directory for you automatically on the next boot (it checks for and starts up the appropriate daemons if the /etc/defaultdomain file exists and you have the directory /var/yp/`domainname` (which ypinit made for you)). Assuming you made the proper change to your rc.local file (if you are on SunOS 4.1.x) the next reboot for either OS version will start NIS services for you.

  3.2: How to Setup a NIS Slave Server? 

Start off by setting your nis-domain name on your slave. This name (example-name below) must be identical to the nis-domain name on your NIS master. # domainname example-name # domainname > /etc/defaultdomain Start the ypbind daemon: # ypbind Verify the NIS master knows about the slave Server # ypcat -k ypservers master-name slave-no-1 slave-no-2 new_slave IF THE NIS SLAVE IS NOT IN THE LIST, USE THE PROCEDURE IN SECTION 

3.3 of this document.  

Otherwise: Run the ypinit script. master-server-ip in the example below must be the ip address of the master server: new_slave# ypinit -s master-server-ip (/usr/sbin/ypinit on Solaris 2.x) (/usr/etc/yp/ypinit on SunOS 4.1.x) NOTE: If you get the following error from ypinit: "Can't enumerate maps from $master. Please check that it is running" then you should rerun ypinint and specify the hostname of the master server e.g. ypinit -s master-hostname You can immediatelly get your machine running as a NIS slave by running ypserv: new_slave# ypserv Afterwards, you should make sure that ypserv and ypbind are both in your /etc/rc.local file, and not commented out (SunOS 4.1.x ONLY). Whenever you reboot your machine at this point, NIS should automatically be started. 3.3: How to Add a New NIS Slave to an Existing NIS Environment? When you initialize your NIS master, you give it a list of NIS slaves. If you later add additional NIS slaves, or remove one of these original NIS slaves, you must update the NIS list of servers. This is done entirely from the NIS master server. First, you must output the list of NIS servers: nis_master# cd /var/yp/`domainname` nis_master# makedbm -u ypservers > /tmp/ypservers nis_master# vi /tmp/ypservers add new slave to bottom of list. (don't change order or format.) nis_master# makedbm /tmp/ypservers ypservers (/usr/sbin/makedbm on Solaris 2.x) verify addition via: nis_master# ypcat -k ypservers now go to the new slave (it must already be a client... ypinit -c) Run the ypinit script. master-server-ip in the example below must be the ip address of the master server: new-slave # /usr/etc/yp/ypinit -s master-server-ip NOTE: If you get the following error from ypinit: "Can't enumerate maps from $master. Please check that it is running" then you should rerun ypinint and specify the hostname of the master server e.g. /usr/etc/yp/ypinit -s master-hostname You can immediatelly get your machine running as a NIS slave by running ypserv: new-slave # ypserv Afterwards, you should make sure that ypserv and ypbind are both in your /etc/rc.local file, and not commented out (SunOS 4.1.x ONLY). Whenever you reboot your machine at this point, NIS should automatically be started. 

3.4: How to Setup a SunOS NIS Client?

(Both this section and the next one assume that you have yp servers on the same subnet as they will broadcast bind (broadcasts do not typically cross routers) to a server. If no need to bind to a specific server across a subnet please see section 3.6) Start off by setting your nis-domain name. This name (example-name below) must be identical to the nis-domain name on your NIS master. # domainname example-name # domainname > /etc/defaultdomain Start the ypbind daemon: # /usr/etc/ypbind You should also make sure that ypbind is listed in your /etc/rc.local file. It will be started from S72inetsvc in /etc/rc2.d on a Solaris 2.x machine. 

3.5: How to Setup a Solaris NIS Client? 

Start off by setting your nis-domain name. This name (example-name below) must be identical to the nis-domain name on your NIS master. # domainname example-name # domainname > /etc/defaultdomain Put the NIS nsswitch file in place. # cp /etc/nsswitch.nis /etc/nsswitch.conf If you are using DNS as well, you will want to modify the hosts: line, by adding dns, as follows: hosts: files nis dns You will also need an /etc/resolv.conf file for DNS to work. See the DNS PSD or the man page for resolv.conf for details on this. The normal method for starting NIS under Solaris, is to give it a list of yp servers. They may be supplied by simply running ypinit, answering the questions, and then rebooting the machine: # ypinit -c If you prefer to start NIS in the less secure broadcast mode, rather than running ypinit, reboot your client machine without running ypinit, and it will come up running NIS in broadcast mode. Broadcast mode is considered less secure because it sends a broadcast to the network for a server for its domain. It would be possible then for a fake server to reply and give you login requests and trap your passwords, etc. Specifying a list of servers to bind to tends to make it more secure than just asking for any server that will reply to you 

3.6: How to Run NIS from a Remote Subnet? 

By default, you can not run a NIS client if your NIS server is on a different subnet. This is because NIS usually runs in broadcast mode, which means that it only queries local servers when starting. In Solaris, if you want to bind to a remote server, simply initialize the client with the -c flag: # ypinit -c (/usr/sbin/ypinit on Solaris 2.x) In SunOS, instead of running ypbind normally you must run it with the -ypsetme option, and then run ypset, using the NIS server's ip address as an argument: # ypbind -ypsetme # ypset nis-server-ip (/usr/lib/netsvc/yp/ypbind on Solaris 2.x) (/usr/sbin/ypset on Solaris 2.x) In this case, be sure to also modify the rc.local file appropriately. It is recommended that you have at least one NIS slave on each subnet. If you do this, only your NIS slave server will need to follow the above procedures all other machines on the subnet will be able to run normally, and they will bind to the local NIS slave. 

3.7: How to Remove NIS From a SunOS Client? 

To remove NIS from a SunOS client, remove the NIS files, as follows: # rm -r /var/yp/`domainname` # rm /etc/defaultdomain If you just want to temporarily disable NIS, you should move the objects to different names, rather than removing them. Afterwards, reboot the machine. 

3.8: How to Remove NIS From a SunOS Server? 

Removing NIS from a SunOS Server is a two-part process. First, you must edit the ypservers map on your NIS master, removing the defunct slave from the list of servers. Section 3.3 explains how to modify the ypservers map. Second, on the NIS slave, you must follow the normal procedure to remove NIS, described in Section 3.7 above. 

3.9: How to Remove NIS From a Solaris Client? 

To remove NIS from a Solaris client, remove the following NIS files: # rm -r /var/yp/`domainname` # rm /etc/defaultdomain If you just want to temporarily disable NIS, you should move the objects to different names, rather than removing them. Afterwards, you must also modify the nsswitch.conf file: # cp /etc/nsswitch.files /etc/nsswitch.conf If you are continuing to run DNS, you will want to modify the hosts: line of the nsswitch.conf, by adding dns: hosts: files dns Finally, reboot the machine.

  3.10: How to run DNS without NIS 

If you are running DNS on a SunOS machine, without NIS, you will find that it will react in a very erratic and unexpected manner. Lookups might not go to DNS at all, or they might go to DNS only in some specific cases. In order to run DNS in a Sun-supported manner, you should setup at least a minimal NIS configuration where you would have your SunOS clients bind to your NIS master and slaves and allow them to do the DNS lookups for your clients. If you are unwilling to do this, Sun SRDB #3886 explains how to modify your libc to remove any NIS dependencies. This procedure does work, but SunService is unable to support DNS on sites which use this configuration. On Solaris machines, you can run DNS without NIS by just modifying the 'hosts:' line in your /etc/nsswitch.conf file. See the man page for nsswitch.conf for how to do this. 

3.11: How to Start yppasswd on the NIS Master Server? 

rpc.yppasswdd must be run on the master server, in order for users to be able to change their yppasswds. To start rpc.yppasswdd from the command line, execute the following: # /usr/etc/rpc.yppasswdd /etc/passwd -nosingle -m passwd DIR=/etc If you are storing your passwd file somewhere besides /etc, you will need to change the '/etc/passwd' and 'DIR=/etc' arguments. Note: the -nosingle option works around a bug seen in various SunOS releases. On SUNOS 4.x : To start the yppasswdd daemon automatically after system reboot on your NIS master server, add the following to /etc/rc.local: # Automate rpc.yppasswdd startup /usr/etc/rpc.yppasswdd /etc/passwd -m all echo -n ' yppasswdd' Its best to use "all" instead of just passwd, because when updating the passwd map, the netid also needs to be updated as well. Usually there isnt a need to specify the DIR= option, make will automatically use /var/yp. NOTES The password file specified to rpc.yppasswdd may not be a link. 

3.12: How to Change a password in the NIS map? 

Previous to Solaris 2.5.1, from any NIS client, any user may run the command: # yppasswd As of 2.5.1 you should be using the passwd command since it follows the naming services currently in use on the machine and changes the appropriate password database (from the /etc/nsswitch.conf file). Read the man page for passwd(1) for more details. All three commands: passwd, nispasswd (for NIS+) and yppasswd (for NIS) are hard links to the same binary 

3.13: How to Change IP address, Host Name, or domainname. 

If you are changing the IP address, host name or domainname of a NIS machine, you must tear down NIS on the affected machine, make the changes, and then rebuild it. The standard procedure is: 1) remove the NIS files and reboot, per Section 3.7 or 3.8 2) edit the appropriate files to make the desired changes 3) rebuild your NIS environment per sections 3.1 through 3.5 If you are removing a NIS master server permanently you should choose a new machine to be the master and update the ypservers file and rebuild that new machine as the master. If you are removing a NIS slave server permanently you should make sure you update the ypservers file 

3.14: How to Set Up Secure NIS? 

SunOS 4.1.3_u1 and 4.1.4 allow you to increase security on your NIS server, as do older versions of SunOS, with patch 100482 installed. If you would like to restrict who may retrieve your NIS maps, you should create the file /var/yp/securenets. The contents of this file should be a number of lines which each read: netmask address For example, if you only wanted the machines 150.101.16.28 and 129.45.16.29 to be able to retrieve your NIS maps, you could enter the following two lines: 255.255.255.255 150.101.16.28 255.255.255.255 150.101.16.29 If you wanted everyone on the network 150.101.16.0 to be able to retrieve your maps, you could enter the line: 255.255.255.0 150.101.16.0 CAUTION: If you are attempting to setup a new client on a new subnet and are having problems getting it to bind to a server on the remote network check the server to see if you have enabled securenets. If so, you will not be able to get the machine to bind until you enable that subnet. 

3.15: How to Use Netgroups? 

Netgroups are only available to sites running NIS or NIS+. There is no local files implementation of netgroups. They are used to group machines or users together in order to make certain sysadmin tasks easier. The man page for negroups defines example useage of netgroups quite nicely as does Managing NFS and NIS by Hal Stern (An O'Reilly and Associates Nutshell book). A standard netgroup triple reads as follows: (hostname, username, domainname) A example netgroup line reads as follows: netgroup-name triple1 triple2 triple3 Though netgroup triples group together hostnames, usernames and domainnames, nothing really reads them in that manner. Thus, you'll usually want to use a triple just to list hosts or users i.e. in order to share NFS file systems or restrict logins to a system. For example, the following would be a typical /etc/netgroup file, on a NIS master: # cat /etc/netgroup root-users (,user1,), (,user2,), (,user3,) trusted-machines (machine1,,), (machine2,,), (machine3,,) Netgroups are limited to 1024 characters in size. If you need to put together a longer netgroup, you can do so by making a meta-group: meta-group netgroup1 netgroup2 netgroup1 (,user1,), (,user2,) netgroup2 (,user300,), (,user301,) The following netgroup will not do what you expect: bogus-group (machine1,user1,), (machine2,user2,) You might think this means user1 at machine1 and user2 at machine2, but in actuality, it is a netgroup of two users (user1 and user2) and two machines (machine1 and machine2). Always seperate out machine and user netgroups, as shown in the /etc/netgroup example above, and you will avoid confusion. Note that we reference the /etc/netgroup file but this file only exists in order to be your 'flat' source file. This file must be in your NIS or NIS+ databases. User netgroups can be used in the /etc/passwd file (and /etc/shadow if using Solaris 2.x). The following entry would include all of the users in the root-users group in your /etc/passwd + /etc/shadow files: # cat /etc/passwd ... +@root-users # cat /etc/shadow ... +@root-users On Solaris 2.x you must also edit /etc/nsswitch.conf in order to use that +/- syntax as follows: passwd: compat group: compat Machine netgroups can be used when exporting file systems. The following entry in /etc/exports on a SunOS machine would allow machines in the trusted-machines netgroup access to the /export filesystem: # cat /etc/exports /export -access=trusted-machines Remember that you must be running NIS or NIS+ for netgroups to work. Simply having an /etc/netgroup file will do nothing it is ONLY the netgroup NIS or NIS+ map which is used. Do a man on ypfiles to find out the names of the NIS or NIS+ maps. rpc.yppasswdd's lock file is '/etc/.pwd.lock'. The admin can prevent the daemon from doing the edit by making that file unwritable ("chmod 000 file" should do it). She should see a syslog msg from the daemon (if a pw change is attempted) "...Passwd file(s) busy...". She should be sure to remove that lock file (or make it writable) when she is done with the hand edit. Another (if a bit crude) workaround is to kill the daemon and restart when the hand edit is done.

4.0 Some Frequently Asked Questions 

4.1: Miscellaneous Questions 

Q: Does NIS support password aging? 

A: No. 

4.2: ypinit Problems 

Q: Why does 'ypinit -m' crash with the following error: ... "Running /var/yp/Makefile..." "make: Fatal error: No arguments to build" "Error running Makefile." ... 

A: /var/yp/Makefile does not exist. Copy it over before rerunning ypinit: # cp /usr/lib/NIS.Makefile /var/yp/Makefile # cd /var/yp # ypinit -m 

Q: Why does 'ypinit -s' crash with the following error, when trying to initialize a slave: "can't bind for domain <domainname>" "reason: internal NIS server or client error" "can't enumerate maps from <master server>" 

A: Your slave was not running ypbind, or it does not have access to NIS currently. You can verify this by running 'ypwhich' you will see that you are not currently bound to a NIS domain. Try following the procedure in Section 3.2 precisely. If that does not work, you may be on a different subnet than your master, and need to initialize ypbind per the instructions in Section 3.6. We have also seen the error corrected by specifying the hostname of the master server instead of the IP address. 

Q: Why does 'ypinit -s' crash with the following error, when trying to initialize a slave: "ypxfr(get_misc_recs) RPC call to <master> failed: RPC: Timed out." 

A: ypxfrd is not running on the NIS master server. Login to the master server and start it: # ypxfrd 

4.3: NIS Make Problems 

Q: Why does yppush refuse to transfer my brand new map when I do a make? -or- 

Q: Why do I get the following message when doing a make: "Can't bind master to send ypclear message to ypserv for map mail.aliases." { See also the next question for another possible answer to this error. } There are two solutions to this problem. If you are running a mix of operating systems on your network (Solaris, IRIX, HPUX) you should probably consider the second solution since the maps should be built by the slave servers themselves as the dbm format may be different on different OS'es. 

A1: ypxfr is confused, because copies of the new map do not exist on one of your NIS slaves. You must manually copy the maps. This can be done by copying /var/yp/`domainname`/map.* from the master to /var/yp/`domainname` on each of the slaves, using either rcp or ftp. 

A2: First make the map on your master without pushing it to the slaves since it is the push (and thus the resulting ypxfr) to hang: # cd /var/yp # make -DNOPUSH mapname.byname mapname.bynumber Now, on each slave server, transfer the map over from your master server: # cd /var/yp # ypxfr -h NIS-master mapname.byname 

Q: Why do I get the following message when doing a make: "Can't bind master to send ypclear message to ypserv for map mail.aliases." 

A: This error can sometimes occur if the servers are not bound to the master. If you see it, you should find out what your servers are bound to: # ypwhich If you find your master (or slave) is bound to something other than the master, force it to bind to the master by killing ypbind on that machine and then restarting it like this: # ypbind -ypsetme # ypset master-nis-ip 

Q: Why do I get the following error when I run a make: "can't get address for server ." 

A: There is a blank line in your ypservers map. You can verify this by running the following: ypcat -k ypservers Remove the blank line by following the standard procedure for adjusting the ypservers map that is described in Section 3.3. 

Q: Why do I get the following errors when making the netgroup map: "entry too big, problem storing netgroup" "error code 1" 

A: netgroup maps have a maximum of 200 entries, or 1024 characters per line. You will get the above errors if you have a netgroup larger than this. You can correct this, by breaking your netgroup down into subgroups, for example: big-group: big-group-sub1 big-group-sub2 big-group-sub1: half of huge netgroup big-group-sub2: half of huge netgroup 

4.4: NIS Update Problems 

Q: Why doesn't my new slave server get NIS maps when they are made? 

A: You have not added the new slave to your ypservers map. You can verify this by examining the ypservers map: # ypcat -k ypservers Section 3.3 explains how to update the ypservers map. You may also have problems if your slave server doesn't already have copies of the maps. See the first questions in section 4.3 for how to remedy this situation. 

Q: Why does my groups map not get correctly distributed? 

A: Because the netid was not distributed, the groups map does not have all the correct info. Run the following on the master to ensure that the netid is also distributed: # cd /var/yp # rm netid.time # make netid For groups updates to occur, both groups and netid must be distributed. It is always best to just run 'make' and let the processes make and distribute whatever maps have changed. Running make source-file may not update all maps that require changes. 

Q: Why is my change to the NIS maps not showing up? 

A1: You did not do a make on the NIS master. You can verify this by examining the map with ypcat. To resolve the problem, go to the NIS master and make the files: # cd /var/yp # make 

A2: If make has been run, you are probably bound to a NIS slave which is not getting updates. You may wish to retry the make, in case the NIS slave was down the first time it was run. Otherwise, you probably need to update the ypservers map. Run ypwhich to see which slave you are bound to, and then examine the ypservers map to verify the problem: # ypwhich slave-3 # ypcat -k ypservers master slave-1 slave-2 If you find that the name which appears in 'ypwhich' does not appear when you look at the ypservers map, follow the instruction in Section 3.3 to update your ypservers map. 

4.5: General NIS Client Problems 

Q: Why do I get the following error message on my NIS client: "NIS server not responding for domain..." 

A1: Your NIS server is currently down. Verify that you can ping it by IP address and if that works, login and check for the ypserv process. If it is not running then start it up. 

A2: The netmasks file on your NIS client is incorrect, and thus the netmask and broadcast addresses are being set wrong. This can be verified by booting the client single user, and then comparing the /etc/netmasks file on the client and server. They should be identical. 

A3: Your server is on a different subnet from your client, and you have not followed the appropriate procedures to take this into account. Examine Section 3.6 for an explanation of what to do in this case. The machine will probably need to be booted single user before these changes can be made. 

A4: If you are seeing "NIS server not responding" intermittently, but NIS is working in between these messages, your network is likely overloaded. This is a performance issue that SunService can not provide assistance on. Consult Sections 8.0 and 9.0 for alternatives in this situation. 

Q: Why can a user not log into my Solaris machine, even though I can see his passwd entry on that machine with 'ypmatch his-name passwd'? 

A: Your nsswitch.conf is set up wrong on the client. Section 3.5 gives info on putting the nsswitch.conf file in place when setting up a Solaris client. 

4.6: ypcat Problems 

Q: How come I can't ypcat a map that I know exists in NIS? 

A1: You might have this problem when you try and look at a map in NIS, as follows: # ypcat netmasks no such map in server's domain This occurs because NIS maps actually have unique names that are dependent upon how the map is indexed. Certain NIS maps (ethers, group, hosts, aliases, passwd, protocols, services) have standard nicknames, to make them easier to access. Run ypcat -x to see the list of aliases: # ypcat -x Use "passwd" for map "passwd.byname" ... You can access maps without aliases by using the real name. For example, the real name for the netmasks map is netmasks.byaddr: # ypcat netmasks.byaddr If you cd into /var/yp/`domainname` on your master server, you will see the complete list of actual NIS map names. Ignore the .dir and .pag suffixes. 

A2: It may also be that the server you are bound to does not have that map on it. Do a ypwhich to find out what machine you are bound to. If for example, you are bound to a slave server and you cannot ypcat aliases you should check on both that slave server and the master server in the /var/yp/'domainname' directory for the existence of files called mail.aliases.dir and .pag Chances are your master has that map while the slave does not. Follow the procedure listed in the first question in section 4.3 for how to remedy this situation. 

Q: Why does ypcat show incomplete info? 

A: You might find that when you do a ypcat of a map, some of the info is missing, for example: # ypcat netmasks.byaddr 255.255.255.0 255.255.255.0 In this case, you should run ypcat with the -k option, which also shows you the column that is being indexed off of: # ypcat -k netmasks.byaddr 150.101 255.255.255.0 150.102 255.255.255.0 Q: After I add an entry to a source file and run a make I don't see it in the output of ypcat? A: NIS maps are not guaranteed to list the information in the same order as it is in your source files due to the dbm format. Some other things to be sure of is that you 

1) made the change on your NIS master and not on a slave machine (see next paragraph), 

2) you made the change to the source file that your NIS Makefile points to and not some other local copy, and 

3) the yppush or ypxfr completed in order to give the slave server a new copy of the map. ypwhich -m on any machine in the same domain should always report the same master as owning the map. If you have any discrepancies in the output you should make sure that you are only running a make on your master and not on a slave machine. 

Q: Why, when I ypcat a map, do I see multiple lines that are exactly the same sometimes? 

A: For example, if you see this: # ypcat hosts | grep machineA 192.115.12.1 machineA mailhost datehost loghost 192.115.12.1 machineA mailhost datehost loghost 192.115.12.1 machineA mailhost datehost loghost 192.115.12.1 machineA mailhost datehost loghost This is because you are not seeing the keys that the map is indexed with. You should ypcat -k the same map and grep for the same machine and you will see this: # ypcat -k hosts | grep machineA machineA 192.115.12.1 machineA mailhost datehost loghost mailhost 192.115.12.1 machineA mailhost datehost loghost datehost 192.115.12.1 machineA mailhost datehost loghost loghost 192.115.12.1 machineA mailhost datehost loghost This map is your hosts.byname map and everytime a lookup for host 'datehost' or host 'machineA' is done the keys are examined in the map and then the appropriate entry is returned. The fact that you have 4 machine names that refer to the same IP address still requires you to have 4 differently keyed entries in the map. 

4.7: NIS passwd Problems 

Q: Why do I get the following error when running yppasswd: "can't find rpc.yppasswd server" 

A: This means that you have not enabled rpc.yppasswdd on your NIS master server. Section 3.11 explains how to do this. 

Q: Why do I get the following errors when running yppasswd: "RPC timed out" "yppasswd couldn't change entry, RPC call failed." or "passwd file is busy" 

A: The passwd file has gotten locked. If there is genuinelly nothing else that should be using it, remove the lock file on the NIS master: %% rm /etc/passwd.tmp Q: How do I hand edit the passwd file when yppasswdd is running? A: rpc.yppasswdd's lock file is '/etc/.pwd.lock'. The admin can prevent the daemon from doing the edit by making that file unwritable ("chmod 000 file" should do it). She should see a syslog msg from the daemon (if a pw change is attempted) "...Passwd file(s) busy...". She should be sure to remove that lock file (or make it writable) when she is done with the hand edit. Another (if a bit crude) workaround is to kill the daemon and restart when the hand edit is done. 5.0: Patches The following is the list of all of the NIS related patches for 4.1.3, 4.1.3_u1, 4.1.4, 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: SunOS NIS Patches  

102159   SunOS 4.1.3: modifications to create services.byservicename nis Corrects an oversight in the NIS Makefile which prevented the services.byservicename map from getting created, and slowed some NIS lookups of the service map. 

100342   SunOS 4.1 4.1.1 4.1.2 4.1.3: NIS client needs long recovery tim Fixes an error in ypbind which slowed clients rebinding after a server had been rebooted. Should be installed on NIS clients if you are experiencing this problem. 

100482   SunOS 4.1 4.1.1 4.1.2 4.1.3: ypserv and ypxfrd Jumbo Patch Closes several NIS security holes, and also fixes some NIS/DNS interoperability problems. 

101435   SunOS 4.1.3_U1: ypserv and ypxfrd fix Fixes an interoperability problem, between NIS and DNS, which could cause DNS to fail if the first nameserver in the /etc/resolv.conf was not available. 

101718   SunOS 4.1.3_U1: C2 rpc.yppasswdd patch If you are running C2 security, this patch must be installed, or you will not be able to correctly change your passwd from NIS clients, via yppasswd. 

102617   SunOS 4.1.3_U1: POINT PATCH to ypbind Fixes problems in binding to a slow NIS+ server running in compat mode and other binding problems with slow servers. 

102733   SunOS 4.1.4: mknetid fails when a user is in more than 16 group Fixes a problem where the netid map would not get made correctly if the user was in more than 16 groups. 

5.2: Solaris NIS Patches  

102707   SunOS 5.3: NIS commands fail to work with servers running in C2 

102704   SunOS 5.4: Jumbo patch for NIS commands 

102705   SunOS 5.4_x86: Jumbo patch for NIS commands Fixes a variety of problems with ypcat, ypmatch, ypwhich, ypxfr, makedbm and ypinit, many of them related to C2 security. 

101973   SunOS 5.4: Jumbo patch for ypbind and libnsl Corrects ypbind limitations, and also a bug which caused problems connecting to a 4.1.3_u1 SunOS yp server. In general, patch lists are too dynamic for this document to accurately track so those listed are the latest at the last time this document was updated. For a more complete list you should search sunsovle at http://sunsolve.sun.com or if you have a specific question about a patch you should open a call with SunService regarding the patch number and your question about it. 

6.0: Known Bugs & RFEs 

6.1: Bugs  

1078027 ypwhich -m does not dump maps if too many to list 

1076214 ypwhich -m results in ypwhich(v2dumpmaps): can't get maplist: RPC: These document a bug on older SunOS systems, where ypwhich -m will get RPC errors if there are more than ~60 maps present in the NIS domain. This Bug-ID has been closed as will not fix, as it is with a dramatically older OS. 1184919 print daemon doesn't always start up This documents a bug in SunOS which can occasionally cause failures in printing service, usually with the error "printer/tcp: unknown service". Other services called from the inetd may sometimes fail similarly. This Bug-ID has been closed as will not fix. If you are experiencing it, you may work-around it by putting a 'sleep 30' statement after the start of 'ypbind' in your rc.local file. There are probably more bugs or RFE's that may be outstanding or may be fixed. The list is generally too dynamic for this document to track. If you suspect a bug you should browse in sunsolve http://sunsolve.sun.com or if you have a question about a particular bug you should place a call into SunService with the appropriate bug number and your question about it.