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.
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.
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.
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
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, 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.
I have encountered this fun as well (used the workaround of using ypwhich to get my server running)
*** Bug 15210 has been marked as a duplicate of this bug. ***
*** Bug 61233 has been marked as a duplicate of this bug. ***
If anyone can reproduce this ("yphelper --maps master" not giving you the maps) right now, can you please contact me.
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.
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)
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.