Path: utzoo!mnetor!uunet!husc6!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl
From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.sys.pyramid
Subject: Re: BIND breaks inetd/rlogin
Message-ID: <10600@tut.cis.ohio-state.edu>
Date: 14 Apr 88 15:44:52 GMT
References: <171100002@uxc.cso.uiuc.edu>
Sender: news@tut.cis.ohio-state.edu
Lines: 48
In-reply-to: paul@uxc.cso.uiuc.edu's message of 12 Apr 88 21:51:00 GMT


paul@uxc.cso.uiuc.edu writes:
   After installing BIND 4.8 we've encountered a strange interaction
   between inetd and named.  If named is activated first (and the
   /etc/nameserver file created) followed later by inetd in
   /etc/rc.local, rlogin breaks.  Specifically a user will get the
   last login message then a connection closed.  If inetd is activated
   first so it uses the /etc/hosts file, everything is fine.

   A similar situation arose once before when the loghost entry was
   omitted from the localhost entry in /etc/hosts.  Our named has a
   CNAME record for loghost that resolves to localhost.

The problem is that named has not had sufficient time to initialize
such that, when /etc/inetd kicked in and went looking for the IP addr
of loghost, the request timed out due to named not being prepared to
answer queries yet.  The effect is identical as for having forgotten
to include loghost in your named zone files.  (And we, too, suffered
from exactly these problems when I first brought it up.)

We're running Hedrick's named 4.7.2 on our 98{x,xe}'s and one thing I
got with that is a little program called (logically enough) `host,'
which is extremely useful for direct nameserver queries.  Our
/etc/rc.local file invokes the nameserver thusly:

...
NAMESERVER=1
...
if [ "$NAMESERVER" ]; then
	if [ -f /etc/named ]; then
		/etc/named & echo 'Nameserver start.'	>/dev/console 2>&1
		cp /dev/null /etc/nameserver
		echo 'Waiting: nameserver init.'	>/dev/console 2>&1
		/usr/local/bin/host -w loghost
	fi
fi

`Host' takes a -w argument, meaning, "wait and keep retrying until you
get an answer."  So we start named, and then our boot procedure just
sort of parks it right there, waiting for named to be prepared to
answer queries.  We start inetd immediately following this, now
guaranteed to get a sane response about loghost.

I would simply include host.c here, but I see that it has a UCB
copyright on it, so I don't think I can do that - sorry.  You'll have
to get permission from an Appropriate Person (UCB?  Hedrick?  I don't
know) to get it, I guess.

--Karl