NIS cached?

[Alan Meyer_4]

I am attempting to write some scripts to check for NIS connectivity and in the processing of attempting to break things to test the script, I have come across something interesting.

With the NIS.client down, I do an id check against a userid that is in NIS and not in the local passwd file, I get the proper response in stead of an error.

I also get the same response with NIS.client up but not bound to a server.

My question is, does NIS cache UID information on the local machine?

Thanks.

[Florian Heigl (new acc)]

There is a password caching daemon around, I stumbled on it once, but can't find the name/manpage right now.

[Florian Heigl (new acc)]

pwgrd(1M) - Password and Group Hashing and Caching daemon.

[Babu A · Accepted solution]

Hi Alan,

The passwd & group information is cached using "pwgrd" daemon...

pwgrd provides accelerated lookup of password and group information for libc routines like getpwuid and getgrname. pwgrd implements per request type caches and hashtables as appropriate. When the corresponding routine in libc is called, a request is issued to pwgrd via a Unix domain socket connection. pwgrd determines whether it can satisfy the request, returning the appropriate results to the requesting proccess

You can see the status of the daemon by usig "pwgr_stat"
... displays the current status of the pwgrd daemon process running on the system. It includes whether or not the daemon is running, how much activity is occurring, as well as statistics for each kind of request serviced by pwgrd. Request specific statistics include the number of request and the percent of requests handled by the cache and the hashtables used to service that request. A request may not have both a cache and a hashtable. Requests where no answer was found are not counted in the hit rate.

The display is updated every 2 seconds. Use the q key to exit pwgr_stat. pwgr_stat verifies that pwgrd is accessible by issuing a NULL request to pwgrd, therefore the NULL request count will be increased as long as pwgr_stat is running.


Thanks & regards,

Babu

[Alan Meyer_4]

This is great information, thanks. One more question though. So, the ID command information is cached, when someone attempts to actually to login to the system then, wouldn't they be using the cached information? Or would they be going directly to the NIS server for authentication?

[Alan Meyer_4]

Ultimately, what I am trying to accomplish is to test the NIS authentication to the NIS servers.

Due to circumstances beyond my control, instead of using subnetted Master/Slave broadcast servers, every node is hardcoded to a NIS server with a ypset command. Unfortunately, if one of these NIS servers goes down AND the machine is on a subnet where there is no resident slave server, the machine looses NIS binding and no login authentication can be done.

I am working on a better design with those up river from me, but in the mean time these up river folks are asking for a script to test the NIS authentication and to force a new ypset binding when the test fails.

So, what I really need is a way to determine when the NIS connection is broke.

Ideas?