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: <1991May25.085119.5733@jarvis.csri.toronto.edu>
Organization: Ziebmef home away from home
References: <1991May21.232345.8739@jarvis.csri.toronto.edu> <227@titccy.cc.titech.ac.jp>
Date: 25 May 91 12:51:19 GMT
Lines: 87

mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
| If some interface of a gateway is down, it is necessary to reach there
| by explicitely specifying its IP address or its name.
| Even if software is written properly, it is usually annoying to wait
| time-out of the first IP address.

 Locally, cases when one interface is down but the rest of the machine
is up are vanishingly small. As a sysadmin, when I suspect that a
particular interface has flaked out, I always use an interface-specific
hostname or IP address, instead of relying on telnet fallbacks.  I
would claim that sufficiently much else breaks when an interface goes
down that for ordinary users, a down interface is roughly equivalent to
a down machine.

| The user should authentificate all of IP addresses, for simplicity.
| Anyway, X11 with IP-based connection authentification is not a real
| authentification.

 Without a 4.3BSD style struct hostent, this requires the user to know
all of the interfaces on a particular machine, which is not what I
consider reasonable. I'm aware of the flaws in the host-based
authentification for X, and use better mechanisms when possible, but
most groups around here have yet to upgrade to X11R4 for various
reasons.

| A little better autehtification is by .rhosts.

 Use of .rhosts is impractical for X11 connections; for one thing, I
may not have .rhosts entries although I want an X connection for that
particular pair, either for organizational or technical reasons.

 With 4.2BSD style struct hostents, .rhosts-based authentification can
get fouled up by an intelligent, nameserver-aware rlogind that does
checking by forward-mapping from hostnames, instead of reverse mapping
from IP addresses. You can say it's a bad thing to run such a daemon on
non-DNS systems, but we have systems (like Ultrix) where one can
configure which lookup mechanisms to use, and in what order, and the
/etc/hosts based one only returns one IP address for a particular
hostname while the DNS ones return multiple IP addresses.

| > On the other hand, network topology updates are often distributed,
| >not centralized.
| Network topology updates affect routing and often cause network trouble.
| So, it should be informed to all related administrators.

 Perhaps it often causes trouble in your organization; it doesn't in
ours. Anything short of a major backbone reorganization tends to
confine its effects to the groups or departments involved. I think this
is a good thing, and something to strive for. Also, being informed of a
change is somewhat less work than having to run around and fix various
netgroups (or whatever) files, and making sure these propagate.

| >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.
| Consider the case where you have your account in Department of Statistics
| and want to trust all workstations there.

 The authentification and authorization mechanisms in things like
rlogind need work, agreed. Perhaps something like Kerberos Realms is
the right way to go. But it's an sepperate issue.

 In this specific case, I would re-run a script which generates my
.rhosts file; the script includes all the machines it finds in
/etc/hosts that are in specific domains. Inside the Dept. of Stats,
they probably use /etc/hosts.equiv to let everyone cross-rlogin
without needing to know about .rhosts.

| As the addition of non-gateway hosts is much more frequent and often
| distributed, it is convenient for users that authentification is done
| with netgroups of NIS.

 We don't use NIS locally, considering it a vile swill of bugs,
inefficiencies, and security holes; we tend to distribute around
necessary information in other, often more efficient ways.
Unfortunately, we'd like to use netgroups without running NIS, a
feature most vendors have never heard of (NFS permissions is the big
thing here; periodically we hack new mountd's up to do netgroups
without NIS, a fairly minor change if you have source).

--
"If the vendors started doing everything right, we would be out of a
 job.  Let's hear it for OSI and X!  With those babies in the wings,
 we can count on being employed until we drop, or get smart and switch
 to gardening, paper folding, or something."	- C. Philip Wood
cks@hawkwind.utcs.toronto.edu	           ...!{utgpu,utzoo,watmath}!utgpu!cks