Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!sgiblab!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: 386BSD gethostbyname change
Message-ID: <1992Oct5.173940.28016@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Reply-To: terry@icarus.weber.edu
Organization: Weber State University (Ogden, UT)
References: <1992Oct5.125237.5267@slustl.slu.edu>
Date: Mon, 5 Oct 92 17:39:40 GMT
Lines: 77
In article <1992Oct5.125237.5267@slustl.slu.edu> ejh@slustl.slu.edu (Eric J. Haug) writes:
>I became tired of not being able to boot 386bsd and mount the two
>NFS partitions because the ethernet bridge was down, or the name server
>was not up to date, so i changed the way hostname lookup fails.
>Any comments?
>eric
>In the file gethostnamadr.c in src/lib/libc/net at around line 281
>#if 0 /* get rid of this, in favor of ... ejh@slustl.slu.edu */
> if (errno == ECONNREFUSED)
> return (_gethtbyname(name));
> else
> return ((struct hostent *) NULL);
>#else
> /* always check the local host table */
> return (_gethtbyname(name));
>#endif
I think the named code has a more serious bug, and that you don't want to
use this as your fix.
First of all, numeric addresses shouldn't be appealed to the name server
anyway.
Second, there seems to be a problem resolving alias records from the name
server (no problem with host records).
The dirt, for those of you who care:
Class B subnet: 137.190 weber.edu
Logical partition: 137.190.16-24 cs.weber.edu
Logical subpartition: 137.190.18 x.cs.weber.edu
Host: xdpy18.x.cs.weber.edu
Alias: xdpy18.cs.weber.edu
Alias: xdpy18.weber.edu
Hecate.cs.weber.edu (a 386BSD box) is able to resolve cs.weber.edu,
xdpy18.x.cs.weber.edu, and xdpy18.x, but not xdpy18. No other
machines on the cs.weber.edu net have this problem.
Obviously there are problems is the host resoloution code; I don't
think "breaking" the library routines will address the real problem,
which I think is related to the host entries list being returned and
the check for an initial digit in numerical addresses on a name to address
translation being bogofied (this last actually could be needing a library
fix, but not the one shown).
I hope someone has some time to look at the problem (Eric? 8-)), but I
don't right now.
In any case, Eric's workaround will solve part of the problem, and partial
path to the name server (in this case, cs.weber.edu) will work -- is
it possible that 386BSD follows a top-down appeal? Anyone who has
tried to mail me at cs.weber.edu knows we have bind problems at cc.weber.edu
that it would take a miracle or write from God to change. This doesn't
effect the non-386BSD machines in the domain, which go upstream (bottom up)
in appeal for alias records.
There are many wonderful NFS patches in the patch kit that address the NFS
issues, and if you follow comp.unix.wizards, there has been a discussion
of AMD's backgrounding of mount requests, plus AMD patches for 386BSD have
been posted here, so if your fix was a response the mount hang, you might want
to check these out.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------