Path: utzoo!utgpu!news-server.csri.toronto.edu!utcs.toronto.edu!cks
Newsgroups: comp.unix.internals
From: cks@hawkwind.utcs.toronto.edu (Chris Siebenmann)
Subject: Re: Shared libraries
Message-ID: <1991May21.232345.8739@jarvis.csri.toronto.edu>
Organization: Ziebmef home away from home
References: <1991May11.100712.27111@jarvis.csri.toronto.edu> <182@titccy.cc.titech.ac.jp> <1991May15.222226.22708@jarvis.csri.toronto.edu> <198@titccy.cc.titech.ac.jp>
Date: 22 May 91 03:23:45 GMT
Lines: 74

mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
['| >' inclusion is by me.]
| My point is that gethostent of 4.2BSD is not so bad, definitely not bug.
| I am not claiming DNS is bad.

 Since I dispute your first statement and agree with your second, we
seem to have a small problem (or not have a small problem as the case
may be).

| >You can always have aliases for specific interfaces; I don't think
| >the need to use nameserver A records instead of CNAMEs is all that
| >much of a hardship (or all that inelegant).
| It is, I think, just as ungraceful as naming all interfaces for
| authentification.

 Apart from ifconfig purposes, one almost never needs to name specific
interfaces if one has well written software (and even less if you have
smart software). Certainly I can't think of a case where ordinary
users need to, unlike the authentification case with routines that
only return one IP address.

| > Registering all of the hostnames in the authentication data seems to
| >be equivalent (in this case) to requiring the users to name all the
| >interfaces (either by name or by IPs) when adding such data.
| Yes, but not for users.

 There are, at least around here, unavoidable cases where users do the
authentificiation setup and not the system administrator. As an
example I quoted in the beginning, consider X11 with IP-based
connection authentification. I as a user's system administrator have
no idea what hosts he will want to authentificate, nor which of them
are multi-homed. The user types
	xhost +neat.cs; xhost +bay.csri
and tries to start up an X application on both. Depending on where on
the network s/he happens to be sitting today, one fails and the other
works, both work, or both fail. This because xhost is only finding
(with a 4.2BSD gethostent()) the first listed IP address, and the
user's X server may wind up receiving connections that originated from
the second IP interfaces on both of those (multi-homed) hosts. At the
same time, an 'xhost +snow.white' works fine, because snow.white is
only a single-homed host ... today. That might change tomorrow.

| In general, there is not so many gateways. Addition of non-gateway
| hosts is much more frequent than the network topology change. Network
| topology change often accompanied by hosts addition. So...
[...]
| For normal users, relying on netgroups of NIS, which is maintained by
| system administrators, is the way to go. Users should not care minor
| hosts addition nor topology change.

 On the other hand, network topology updates are often distributed,
not centralized. I don't have any idea whether or not the Department
of Statistics is splitting their network today, nor if this will
affect any of my users or any of their users who're trying to use my
machines. I maintain I shouldn't have to care.

[Note that locally we usually automatically distribute an /etc/hosts
 around to various machines, via ftp and some scripts. Not having to
 manually update my /etc/hosts every time something changes is quite
 nice.]

| BTW, I don't think it is reasonable to require normal users to cope with
| subtle authentification.

 One can either make the system administrator try and cope with it
instead, or give the user simple(r) authentification mechanisms. I
think a gethostent() setup that returns multiple IP address for
multi-homed hosts is "simpler" than one that returns just one when
others exist.

--
	"This will be dynamically handled, possibly correctly, in 4.1."
		- Dan Davison on streams configuration in SunOS 4.0
cks@hawkwind.utcs.toronto.edu	           ...!{utgpu,utzoo,watmath}!utgpu!cks