Slow service in one NIS scenario
I have a Sun Fire V210 server (that runs Solaris 10) configured as the master NIS server. In normal gethostbyname-type scenarios, such as ping, the NIS server performs well. However, when initiating the same type of lookupfrom the server (i.e. the NIS clientis the master NIS server), there is a long delay. I have observed a minimum delay in this scenario of approximately 15 seconds and a maximum delay of approximately 29 seconds.
Is this to be expected, or is there something that I can do to significantly reduce that delay?
Alan Feldstein
Cosmic Horizon
http://www.alanfeldstein.com/
# 1
It's not to be expected.
Quite what the cause and solution might be, though, I don't know.
1. Do you get the same delays using the 'NIS native' lookup tools
like ypmatch and ypcat?
2. Do you get the same delays for other maps (eg, passwd, locale,
groups -- whatever else NIS is serving) using ypmatch & ypcat?
3. Do you get the same delays for other maps using getent?
4. Does /etc/inet/ipnodes contradict /etc/hosts hosts?
5. What's the search order for hosts and ipnodes in /etc/nsswitch.conf?
cheers.
# 2
> 1. Do you get the same delays using the 'NIS native'
> lookup tools
> like ypmatch and ypcat?
no
> 2. Do you get the same delays for other maps (eg,
> passwd, locale,
> groups -- whatever else NIS is serving) using ypmatch
> & ypcat?
There is no significant delay associated with any of them when using ypmatch or ypcat. There was one notable exception:
ypmatch <NIS client name> ipnodes.byname
took a long time before failing the first time, and failed immediately the second time (looking up the same client as the first time). See my answer to Question 4 for more about this.
> 3. Do you get the same delays for other maps using
> getent?
I didn't check all of the maps because I got an interesting result with a gethostbyname-type lookup on the hosts and the ipnodes databases using getent. The former was fast. The latter took about 21 seconds.
> 4. Does /etc/inet/ipnodes contradict /etc/hosts
> hosts?
/etc/inet/ipnodes
does not "contradict"
/etc/inet/hosts
(and of course /etc/hosts is a symbolic link to the latter).
"Contradict" is too strong a word. There is a difference, however. Both files have IPV4 entries for localhost, and for the master NIS server as added by DHCP. ipnodes has an additional IPV6 entry for localhost. There are no entries for the other NIS clients in these files.
The source files for preparing the master NIS server are elsewhere, and the contents of these files are probably more important. That directory's hosts file contains an entry for every computer in the NIS domain. That directory does not contain an ipnodes file.
> 5. What's the search order for hosts and ipnodes in
> /etc/nsswitch.conf?
Both are
nis dns [NOTFOUND=return] files
Alan
# 3
> The source files for preparing the master NIS server
> are elsewhere, and the contents of these files are
> probably more important. That directory's hosts file
> contains an entry for every computer in the NIS
> domain. That directory does not contain an ipnodes
> file.
/var/yp/Makefile
defines macro INETDIR, which I had not redefined, so
/etc/inet/ipnodes
became known to the NIS server.
The Makefile also defines macro DIR, which I had redefined to point to my source directory, so that version of hosts became known to the NIS server.
As I described previously,
/etc/inet/ipnodes
does not contain entries for the other NIS clients, but the hosts file that became known to the NIS server does.
The ipnodes(4) man page explains that "The ipnodes file will be searched for IPv4 addresses when using the getipnodebyname(3SOCKET) API. If no matching IPv4 addresses are found in the ipnodes file, then the hosts file will be searched." That is why I was getting the delay, but ultimately the lookup succeeded. The man page goes on to say "To prevent delays in name resolution and to keep /etc/inet/ipnodes and /etc/inet/hosts synchronized, IPv4 addresses defined in the hosts file should be copied to the ipnodes file."
I fixed this by copying
/etc/inet/ipnodes
to a directory of my choice and redefining the INETDIR macro to point to that directory. Then I copied all IPV4 addresses from the NIS version of the hosts file into the NIS version of the ipnodes file. Finally, I updated the ipnodes map with
cd /var/yp/
make ipnodes
This fixes the problem I reported. Thank you very much for your help, kidari..
Alan
