Bug 26362 - unable to initialize slave server
unable to initialize slave server
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: ypserv (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
Aaron Brown
:
: 15210 61233 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-06 16:33 EST by Need Real Name
Modified: 2007-04-18 12:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-26 12:54:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-02-06 16:33:54 EST
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 08:46:00 EST
Please look at "ypinit" at about line 24 and try to use the other possibility to
get
a list of maps ("maps=..."). For the real fix, I should look into detecting if
"ypwhich"
fails and then adding fallback for yphelper.
Comment 2 Need Real Name 2001-02-13 14:07:24 EST
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 04:47:18 EDT
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,
           denice
Comment 4 Need Real Name 2001-09-06 20:58:47 EDT
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.  

Thanks.

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
problem.
Comment 5 Steven Roberts 2002-01-23 22:37:55 EST
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 10:48:05 EST
*** Bug 15210 has been marked as a duplicate of this bug. ***
Comment 7 Alexander Larsson 2002-03-21 10:49:15 EST
*** Bug 61233 has been marked as a duplicate of this bug. ***
Comment 8 Alexander Larsson 2002-03-26 12:54:48 EST
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 15:07:43 EST
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 15:30:10 EST
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 15:52:10 EST
http://people.redhat.com/alexl/RPMS/ypserv-2.2-5.src.rpm

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.