[578] in testers
6.4R: netconfig
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Sat Dec 30 16:18:09 1989
From: probe@ATHENA.MIT.EDU
Date: Sat, 30 Dec 89 16:15:49 -0500
To: testers@ATHENA.MIT.EDU
Cc: athena-ws@ATHENA.MIT.EDU
Reply-To: Richard Basch <probe@ATHENA.MIT.EDU>
This is a statement that it is unclear how to handle the case in which
HOST is set, but ADDR is not. Unpredictable results will occur (or that
is how I am advertising it, for now). It can be argued whether the
hostname specified should be registered in the dyn.mit.edu domain or
whether it should simply ignore the HOST variable.
The entire semantics for the HOST variable should be thought out quite
carefully. I know that now if it is specified, it will use that without
hesitation (this is not the correct behavior in all circumstances, but
it is more correct than frobbing with it when it is valid, especially
since the hostname must match what is in /etc/srvtab and some hostnames
have capitalization). Thus, the circumstance where ADDR is unset and
HOST is set is UNSUPPORTED currently.
Of course, if HOST is undefined (also includes the case where it is "",
"NOHOST", or "NONAME"), the correct behavior of checking and setting the
hostname will occur in all cases.
Basically, the semantics are open for debate.
My personal views towards the semantics are:
- If ADDR is set and HOST does not match the machine name, flag a
fatal error. More precisely, a gethostbyaddr() should be done and
if it returns something that does not match gethostbyname() of the
HOST variable, then there is a conflict of data that HAS to be
resolved. After discovering this, before the program exits, it
should turn off the network, in case a different host with
consistent data with the same ADDR tries coming up.
- If ADDR is set and the results of gethostbyaddr() does not conflict
with gethostbyname(getenv("HOST")) then use the value of the HOST
variable. Flag a WARNING if strncasecmp() of the value does not
match the initial part of the canonical name, though (this means
the canonical name has been changed, and aliasing was done).
- If ADDR is set and gethostbyaddr() returns nothing, use the value of
HOST as it may just be that the nameservers are temporarily unavailable.
Depending on the reliability of the return codes, it might be possible
to then consider HOST as not set and to register the name dynamically
if a NXDOMAIN was returned by the gethostbyaddr().
- In all other cases, ignore the HOST variable; either the HOST variable
is not set or the machine is being dynamically assigned an address.
To determine the name, it should do a gethostbyaddr() and set the
hostname appropriately. If no response is received, register the
machine in the dyn.mit.edu domain.
I do not expect that the implementation of a decided set of semantics
will be done for 6.4, but it something should be done for the following
release.
-Richard
