Bug 26362 - unable to initialize slave server
Summary: unable to initialize slave server
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ypserv
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Aaron Brown
: 15210 61233 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-02-06 21:33 UTC by Need Real Name
Modified: 2007-04-18 16:31 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2002-03-26 17:54:53 UTC

Attachments (Terms of Use)

Description Need Real Name 2001-02-06 21:33:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.14-5.0 i586)

The NIS slave server initialization fails

Reproducible: Always
Steps to Reproduce:
1. /usr/lib/yp/ypinit -s <masterserver>
  no maps are returned.. 

Expected Results:  NIS map names are supposed to be returned by yphelper so
that ypxfer can get copies.  yphelper is non-functional.

I retrieved ypserv of the same version from it's home site and recompiled
from original source.  That code worked.

Comment 1 Florian La Roche 2001-02-13 13:46:00 UTC
Please look at "ypinit" at about line 24 and try to use the other possibility to
a list of maps ("maps=..."). For the real fix, I should look into detecting if
fails and then adding fallback for yphelper.

Comment 2 Need Real Name 2001-02-13 19:07:24 UTC
interesting... That in fact does work.  That code is commented out in the
generic distribution as it is in the RPM.  I think it's nicer if the distributed
binaries all work though.

Comment 3 Denice 2001-06-24 08:47:18 UTC
Well, I have had this problem too.  I have a 6.1 master and could not make
either a 6.2 or a 7.1 machine become a slave, even after changing the 'maps='
entry.  But finally the fix was simple for me with the alternate 'maps=' entry:

maps=`ypwhich -m | egrep $MASTER$| awk '{ printf("%s ",$1) }' -`
#  maps=`$YPBINDIR/yphelper --maps $MASTER`
The 'ypinit' script sets my master ($MASTER) to an unqualified hostname, but 
  'ypwhich -m'
returns a fully-qualified hostname.  Thus the ypinit script ends up with the
maps variable unset.  So I simply used the fully qualified master name as an
argument to the script and voil` .. it worked.  Funny how sometimes you don't
think of the simple things; ie:
  ypinit -s slave.my.dom    instead of    ypinit -s slave

  .. cheers,

Comment 4 Need Real Name 2001-09-07 00:58:47 UTC
The fact that using the alternate commented-out shell code line makes ypinit
work does not change the fact that yphelper --maps is broken.  This has not
worked since at least RH 6.1.  

Like bferrell@microdisplay.com, I downloaded Thorsten's code, and compiled it
and it works perfectly.  Not only that, but I downloaded the source rpms for
7.1, installed them with rpm -i ypserv-blah.src.rpm, unpacked the sources, and
ran make yphelper, and THAT worked.  Then I did a rpm -bc blahblah and copied
the binary into place.  Sure enough, it did NOT work. It's quite clearly
something in Red Hat's patches that breaks yphelper.

I had a discussion with someone -- I don't recall who (I think it might actually
have been Thorsten himself) -- about this about 2 years ago when we first found
this problem.  IIRC, he suggested that the problem was with the patch that adds
NDBM support.  I have made no effort whatsoever to look at that patch and/or how
it affects yphelper.  

Interestingly enough, the yphelper.c file itself is not patched at all as near
as I can tell by looking at the source RPM, so the problem must be introduced in
some other module that yphelper.o gets linked with, or a header file that gets
patched, or something...  I'm a sysadmin, not a programmer, so I didn't have
time to pursue this any further once I discovered that Thorsten's original code
worked fine.

It would make my job a lot easier if you guys would fix this, so I don't have to
keep downloading Thorsten's source, compiling yphelper myself, and installing
the binary manually as I've been doing for about 2 years now...  Now I suppose
we've discovered that using the commented method of getting the maps works which
is an easier fix, but it's still a PIA to remember and go in and fix it.  


Oh, I don't know if it matters, but our master NIS server is RH 6.1, running
with ypserv-1.3.9-1.i386.rpm which I believe is from the RH 6.1 updates tree. 
We downloaded this update specifically because the original version that shipped
with RH 6.1 exhibited the same problem, and we were hoping this update would fix
it.  It didn't... and neither did any of the subsequent RH ypserv RPMs installed
on more recent slave machines.

I'll be happy to provide any other information you feel may help you find the

Comment 5 Steven Roberts 2002-01-24 03:37:55 UTC
I have encountered this fun as well (used the workaround of using ypwhich to get my server running)

Comment 6 Alexander Larsson 2002-03-21 15:48:05 UTC
*** Bug 15210 has been marked as a duplicate of this bug. ***

Comment 7 Alexander Larsson 2002-03-21 15:49:15 UTC
*** Bug 61233 has been marked as a duplicate of this bug. ***

Comment 8 Alexander Larsson 2002-03-26 17:54:48 UTC
If anyone can reproduce this ("yphelper --maps master" not giving you the maps)
right now, can you please contact me.

Comment 9 Alexander Larsson 2002-03-26 20:07:43 UTC
Denice verified that ypserv-2.2-5 fixed this. So I'm marking this as fixed.
This should show up in Rawhide soon, but until then it's availible at
http://people.redhat.com/alexl/RPMS/as i386 rpm and source rpm.

Comment 10 Steven Roberts 2002-03-26 20:30:10 UTC
what's the easiest way to look at the source code that makes up rawhide stuff?  wondering if there is a code patch I could try myself (since RedHat 
isn't supporting 6.x anymore)

Comment 11 Alexander Larsson 2002-03-26 20:52:10 UTC

That probably builds and works on 6.2. According to a comment above I think the
fix was removing the ypserv-1.3.9-ndbmkey.patch patch from the package, but it
could also have been fixed upstream in the new version.

We do actually support 6.2 is some sense. I'm probably gonna do an errata for
ypserv soon. I just got to get the buglist under control.

Note You need to log in before you can comment on or make changes to this bug.