[comp.sys.pyramid] BIND breaks inetd/rlogin

paul@uxc.cso.uiuc.edu (04/13/88)

Given the following configuration:

90x, OSX4.0, NSP

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.

Suggestions and hints are welcome.

         Paul Pomes

UUCP:     {ihnp4,uunet,convex}!uiucuxc!paul
Internet, BITNET, CSNET: paul@uxc.cso.uiuc.edu
US Mail:  UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL  61801

karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (04/14/88)

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