Possible to run in.named and run YP

[Jon A. Tankersley]

ginosko!lavallee at uunet.uu.net (Warren Lavallee) writes:
>X-Sun-Spots-Digest: Volume 7, Issue 231, message 9 of 9
>
>Does anyone know if it is possible to run the nameserver under YP?...
>
>[[ Get the Bind distribution tape from Sun.  It contains a "fixed" version
>of ypserv called "ypserv.share"....

I am not going to wax loquacious on this... But, there are even more
fixes...  and them is broke.   The original problem I believe was that
ypserv would connect to the nameserver even when hosts were in the maps.

DISCLAIMER:  We are the only site that Sun is aware of that has this problem:

We've been running the nameserver for months with one YP server and one
nameserver.  Everything was fine, even with the old 4.0.1 stuff.  When we
upgraded other systems to 4.0.1 all hell broke loose.  YP maps were
getting trashed, etc.  Some by installation errors and some by the
YP/named stuff on the Bind tape.  Be ABSOLUTELY SURE that all SERVERS have
the same release of ypserv/ypxfr.   'what'ting the binaries does NO good
as the patch versions don't always seem to be derived from an FCS version
of the source.  sum'ing them doesn't tell you much beyond uniqueness of
the version.

A few other observations:
yp-only        bogus hosts return quickly with host error
nslookup       bogus hosts return quickly with host error
libc.so.resolv bogus hosts return quickly with host error
yp/named       hangs FOREVER with bogus host.  ypmatch, rlogin, telnet....
	       I'd consider this a bug.  Tracing the network traffic shows
	       that ypserv is trying OVER and OVER host.full.domain.name and
	       host.down2two.domain and then repeating.  It never accepts
	       the response from the nameserver....  Recursive or non-recursive.
	       Some allowance might be made as it looks for the root servers,
	       but 2 hours w/o failure?  I am spoofing named because I have
	       a system acting as the root server, so 20 seconds is too long.
	       Yet it will sit there forever.

sendmail       Not the MX version.  ypmap (%y) has problems resolving certain
	       hosts.  When I added a SMTP forwarder to my site's mailhost,
	       my uucp (uunet!!!) connection stop sending mail.  Seems that
	       sendmail/yp/named thought it could reach uunet.uucp via smtp,
	       but uunet wasn't talking!  Ruleset 0 wasn't dropping down
	       to the uucp mailer.....  AAAARRRRRGGGGHHHH!!!!  Switching to
	       FS/usr/lib/mailhosts and $=S fixed that problem.

	       Related problem with 3.5 systems sendmail.cf in a 4.x domain with               named:  The following rule MUST have the $: added to the LHS or
	       an infinite loop occurs appending .LOCAL onto the end until 
	       sendmail complains....  $: terminates the rule, not the ruleset.
	       This worked fine in 3.x without named.

Ruleset 0:        ------vv
R$*<@$*$%y>$*		$:$1<@$2$3.LOCAL>$4		user at etherhost

ypxfr          hosts.byname fails with (get_misc_recs) and ypinit says all is
	       kosher.  This is one of the maps modified by makdbm -b.

ypinit -s master doesn't bind to the master server before transferring maps.

Gateway ypmasters (sun3) MUST bind to themselves in order to allow network
	       traffic to flow (a very strange problem).  Net.security patch
	       seems to complicate this further by making you modify the
	       rc.local script further to allow -ypsetme to run.  Sigh.
	       This may be a YP only problem, but with the nameserver I haven't
	       tried to figure that part out.

ypcat          can't display anything to show that the map was built with -b
	       for Internet use.  Undoing the map with makedbm will though.

All the latest official patches have another interesting side effect.  NFS
mounts by diskless clients fail.  So does rcp and shutdown.  4.0.1 fixed
some problems with the gethostbyname for the libc and dynamic libraries,
but mount, rcp, shutdown, and others are staticly linked and were not
fixed in 4.0.1.  I've had to get new versions of mount and rcp to get
things working again.  This problem appears to be more critical for Sun3
systems and Sun3 ypservers.  In fact, with Sun4 servers the new mount
fixed up about everything.  With Sun3 servers, it didn't, drove me batty
'cause one network has a Sun4 server and 3 sun3 servers..... and automount
never did fail! AAAARRRRGGGGHHHH!!!!  Possibly related is net.security
portmap dies silently during the boot.  I backed off this version and
stuck with 4.0(.1?).

Also, it is still possible for bogus nameserver queries to be created.
I've seen requests for A.full.domain.name, A.down2two.domain.  Seems that
some utilities liked to query yp with a bogus char hostname to see if it
was up and running.  I've also seen trunchost.domain requests.  These can
fill up named tracing disk space REAL fast when looping occurs if left
alone too long.

I've been fighting this battle for over a month without source....  Sun
has been helpful, if a little slow.  I'd not be able to use the nameserver
at all without the help of my PAL support people.  The problem didn't make
sense to me, to them, and finally to engineering, so hopefully it is
getting resolved.  (Just got a patch to let the Sun3 ypservers allow Sun3
clients to mount NFS!)

Just letting you know that more patches may be expected.  And despite all
these problems, yp/named does work, and allow you to have subsets of the
hosts maps in yp successfully.  You just gotta watch out and be careful.
I currently have to change only one file to add most hosts to our
environment.  No more propigation of hosts tables, etc. across my
different YP domains.  THAT is the biggest plus I can think of to the
yp/named situation.  With 6 domains and over a hundred Suns I needed
yp/named.

Now if only I could get more tables into named, like printcaps.....
-tank-
#include <std/disclaimer.h>		/* nobody knows the trouble I .... */
tank at apctrc.trc.amoco.com    ..!uunet!apctrc!tank