NIS

[Scott McDade]

I have several 11i systems and I am using NIS to manage the account administration. I am seeing an issue where the users can't login and I have to login as root and issue a ypwhich command. It responds with something like "Domain B323 not bound". So, I issue a ypset iltdc1 which is the master and it corrects the problem. What could be causing this to happen? Is this activity logged anywhere? It only happens occasionally? I don't think it is network related as the other systems using NIS are not affected.

-Scott

[Helen French]

If the NIS client and the server are on different subnets, then you should do ypset command manually in order to bind the server. Check and see the following:

1) Do a custom patch management and install all latest patches.
2) Check /etc/rc.config.d/namesvrs file, add ypbind options (ypset) if necessary. Restart the daemons.
3) Check NIS maps and recreate any if found a problem.

[Helen French · Accepted solution]

Instead of writing a script, I would suggest you to look at the log files (/var/adm/syslog/syslog.log, /var/yp logs). Check for any warnings/error messages. You can manually run the command ypbind with and without ypset option and see what happens (put it in verbose mode -v). Check for network traffic and network paramters.

[Helen French]

This document has general NIS troubleshooting information TKB #S3100006310C:

http://support2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063211043

[Colin Topliss]

grep for ypbind in the syslog - that will give you the times of any bind messages - might be able to help you pinpoint the time the problems are occurring and highlight any pattern.

You can check the port settings (as suggested just now) by using lanadmin, and if you're still not sure of a network problem try FTP'ing a large file between the systems - if there's a problem the transfer will be slow (use hashing to see how fast FTP is transferring data, and compare to a known working system).

As for patches, I'd compare the patches between a working system and a non-working. If there's a difference then by all means patch to the same level.

[Colin Topliss]

Any pattern to the problem at all? Is it always the same systems at the same time (or around the same time)? Do you see any messages in syslog - it will help pinpoint the time the problem occurred, and you can then use that information to look at the master and see if anything was happening around that time.

I have seen similar problems, all related to either a busy system or busy network at the time the slave was trying to talk to the master. For some reason this doesn't always clear itself (never really got to the bottom of it, and I doubt I will seeing as we're migrating to LDAP).

[A. Clay Stephenson]

This generally happens as a result of: 1) these clients are not on the same subnet as the NIS server, 2) slow response to the request because the NIS server/network is very busy at that moment, 3) not enough NIS servers visible to these clients.

Also don't overlook the obvious - speed/duplex mismatches between hosts and switch ports. I would avoid auto-negotiate (unless these are Gigabit connections) and hard-set the switch ports and connection settings on the UNIX boxes. Finally, look for any NIS/Network patches and apply them.

[Scott McDade]

Colin: No pattern really. And it is hard to pin point when it happens as I only get called when they can't logon to the system. So theroically it could be dropped hours before the problem is reported. I was thinking about writing a quick script and if ypwhich comes back unbound then issue the ypset. I am just not real familar with the NIS process.

Any suggestions?

-Scott

[S.K. Chan]

It does sounds like the client is not able to send the broadcast request to the slave/master. What'sthe route between the client and the slave/master ? Is your client the the same subnet as the slave/master ? The next time this happens, start ypbind with a "-v" option so that error messages are logged, that way you have better idea what's going on. If you have similar client to this one and it is behaving well then it's probably some changes had happened to this client, check all NIS related files, check syslog.log as well. What about NIS patches .. are they updated ?

[Cindy Fischer]

I have only one 11i system and I am seeing the same problem. We have plenty of other unix systems on the same subnet that do not have the problem. It seems that this is an 11i issue. Could there be some kernel parameter or environment setting that affects NIS? We see this problem every day.Even if I am already logged in from the previous day, I have problems with network access.

Cindy