Very Computer

        Puzzle for you NIS experts:

        I recently reorganized my /etc/hosts file to put the fully
qualified name first.  Thus it went from
129.128.72.10  arafel arafel.space.ualberta.ca
to
129.128.72.10  arafel.space.ualberta.ca arafel.  
        This on the recommendation of Hal Stern's NFS & NIS book.

        Then (cd /etc/yp; make)
        Make updated hosts, but stalled when yppush attemped to send the
new map to my slave server, lucifer.

        From the master with the new maps, I could ping, rsh, telnet etc
to lucifer.  So there wasn't a problem with the master knowing where the
slave was, or being able to reach it.

        From the slave I was able to run ypxfr by hand and bring the new
map over.

        I ended up moving the domain directory, and re-running ypinit -s

        So, why wouldn't lucifer respond to yppush?  I want to know for
next time.

--

=> University of Alberta         Lab Manager, Space Physics Group <=        
=> tel:403 492-3713                             fax: 403 492-4256 <=        

        The problem looks SO similar to just simply changing
        master from one host to another...

        There is one NIS map, that holds names of servers:

plootu# cd /var/yp
plootu# /usr/etc/yp/makedbm -u mydomain/ypservers > /tmp/filename
plootu# cat /tmp/filename
YP_LAST_MODIFIED 0776974940
YP_MASTER_NAME plootu
serifos serifos
plootu plootu

        Change hostnames there, do

plootu# /usr/etc/yp/makedbm /tmp/filename mydomain/ypservers

        Every map also has info about it's master, so you must
        change that too by remaking all maps. It is propably easiest
        to just delete all .time -files from /var/yp, and doing make:

plootu# cd /var/yp
plootu# rm *.time
plootu# make

        and make ypxfr on slave for every map, and all is well.

        This all is documented (on SunOS 4.1 at least) on sysadmin manual,
        "Changing a Map's Master Server" (page 498 on SunOs 4.1.1(?) manual)
        and "Adding a New NIS Server to the Original Set".

        Procedure is not covered there step by step, but by reading the
        text you get what must be done and WHY.

--

University of Helsinki, Computing Centre

Check the file ypservers which list your slave servers.  Perhaps it
requires the fully qualified name and not an alias which is what 'lucifer'
now is in your hosts file.

Hope it helps.

--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
David LaPointe - Eng. Systems Admin. +  If you're not the            -   ,__o
AEG Schneider Automation             +  lead dog, the scenery       -  _-\_<,

[Aside: to see the ypservers map, you have to do "ypcat -k ypservers",
as that map contains only keys (its values are blank).  (Or use makedbm -u).]

Hmm.  I don't think that's it, particularly not if yppush is working OK now
even though the ypservers map has not changed (as far as we know).

However.
I've always found when creating a new NIS map that when I first try to push
the new map to the slaves,  yppush hangs, and I have to "pull" the maps down
to each slave server with ypxfr, telling ypxfr the master's hostname
(there's a commandline option for that).  Once that's done, yppush works fine.
This sounds like the same sort of problem.

Not having the source, I've never been able to determine exactly what's
happening, but I think the problem is that ypxfr (which runs in response
to yppush) on the slave server needs to have a local copy of the map already
in order to tell which host is the master for that map.  (Because you can,
if you're crazy enough, have some masters serving some maps and other
masters serving other maps.)

(My experience is with SunOS 4, by the way.  And someone please correct
me if I'm talking *-- it's rather late:-)

So in the situation under discussion, my guess is that as the canonical
name of the master has changed, ypxfr doesn't know where to go anymore.
It doesn't sound like any maps other than hosts were changed, but if
my theory is correct, yppush would have stalled on any map.

As ypinit -s pulls all the maps, redoing that would be the easiest way
to clear the problem.

----------------------------------------------

56 Kennedy Street, Maylands WA 6051, Australia
Phone/Fax +61 9 272 5061

U N I X   A N D   O P E N   S Y S T E M S
   Configuration      Technical Writing
     Networking        Troubleshooting
Software Development      Training
----------------------------------------------