SUMMARY: More information on YP server problem

From: mark galbraith (mark@deltam.com)
Date: Thu Aug 08 1991 - 18:39:06 CDT


Thanks to all the responses I received I have been able to get this
to work as it should have all along.

Here is my original question:

>I apparently did not include enough information in my original message.
>I would like to thank the people who have thus far replied. I will re-
>ask my question with the additional information included.
>
>I have a network of Sun workstations. We are running NIS and have only
>one NIS server. When any of the map source files are changed and the
>make file run, the server doesn't reflect the changes. All clients are
>in the same domain, and have no trouble getting their NIS information
>from the server under normal circumstances.
>
>A couple of items of note. I don't have a ypservers map as there is only
>one server. Do I need this map to make it all work right? If so, how
>do I create it? This same configuration worked just fine under SunOS 3.5.
>The problem was first noticed when we upgraded to 4.1. All I can figure
>out is that the NIS server daemon is caching the maps in an attempt to
>speed up access. This is fine and well, but how do I tell the daemon
>that its cached maps are outdated?
>
>So far our only workaround is to kill off the ypbind's; kill the ypserv;
>restart the ypserv; and restart the ypbind's. This is a royal pain in
>the a** and I would like to find out why it's necessary.
>
>Can anyone out there help?

Thanks to all the people that responded (They're too numerous to list
here). The answer was hinted at by several and by piecing them together
I was able to solve the problem.

Since I had converted the YP maps from another machine, I had not run
ypinit. This was fine and good, but I failed to perform all of the steps
necessary for YP to properly operate.

Under the older system, the ypservers map was only used to push the maps
to the other YP servers. Since no caching was performed, this worked well.
Now, under 4.1 and later, the YP server caches quite a bit of information
and depends upon some signal to indicate that the disk copy of the maps
have changed.

I had two problems that kept this update from happening. First, I didn't
have a ypservers map. I corrected this by following the steps listed in
the ypinit script file. Of note, the ypinit script contains a line like:

        cat $hf | awk '{print $$0, $$0}' \
            | makedbm - $yproot_dir/$def_dom/ypservers

When I performed this line as is, the yppush I tried came back with the
error "Unable to locate address for server 'dmdm'". This looked strange,
so I tried the line:

        cat $hf | awk '{print $$0}' \
            | makedbm - $yproot_dir/$def_dom/ypservers

And I now have a working yppush. The second problem I had was a little
bit more stupid (sheepish grin). Since I had no slave servers, I set the
variable NOPUSH to 1 in the /var/yp/Makefile. This means that no matter
what was in the ypservers map, I would not get a push. Fortunately I
found this one during the changes for the other one. I found it when
examining the Makefile for the proper format for the yppush command for
testing the new ypservers map.

The moral of this story: It's never as simple as it seems.

--Mark Galbraith Voice: +1 415 449 6881--
--Software Engineer UUCP: uunet!deltam!mark--
--System Administrator/Postmaster Domain: mark@deltam.com--
--Delta Microsystems, Inc. Compuserve: 76234,3126--



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT