[1511] in NetBSD-Development
On clusterinfo
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Dec 28 15:54:35 1997
Date: Sun, 28 Dec 1997 15:54:04 -0500
From: Greg Hudson <ghudson@MIT.EDU>
To: sipb-athena@MIT.EDU
A little bit ago, I wrote:
> The Athena clusterinfo strategy would mean that people would have to
> get cluster information before their machines would work (a big
> lose), would make no sense if people were running both NetBSD and
> some future similar Linux system on their machine at the same time,
> and would impede getting machines working in domains other than
> mit.edu (like LCS). So we probably want a different approach.
Here's a proposed approach, involving only changes to
save_cluster_info and the install:
* We will use fully-qualified hostnames in /etc/athena/rc.conf
and /etc/rc.conf. I don't think this breaks anything but
getcluster, although it makes the xlogin screen look a bit
different.
* In /etc/athena/rc.athena, if the hostname is foo.mit.edu,
try to retrieve clusterinfo for foo. Otherwise assume
that there's no network clusterinfo for this host.
* If there is no network clusterinfo for the host, read from
/etc/athena/cluster.fallback (using "getcluster -d").
* Once the system packs are mounted, copy
/etc/athena/cluster.fallback off of the system packs. Any
changes will therefore be noted at the next reactivate.
This approach lets us do okay with hosts not in the mit.edu domain and
lets hosts operate with no hesiod clusterinfo while still letting us
update the default set of cluster information for NetBSD-Athena
machines.
Some caveats and possible modifications:
* There is no local control over cluster information, just as
in the Athena model. Somewhat worse, hosts will only be
able to fudge it with local named records if they are in the
mit.edu domain.
If we wanted to solve this problem, we could make
/etc/athena/cluster.local override
/etc/athena/cluster.fallback if it exists.
* If Athena ever moves to a fqdn.cluster.ns.athena.mit.edu
model, we won't automatically win. We could look up
clusterinfo for the fqdn if it doesn't match foo.mit.edu, in
which case we would automatically win; I'm not sure if
that's a great idea or not.
* People can use Hesiod clusterinfo to control their machines
if they want, but only if they're in the mit.edu domain and
only if they're willing to settle on a single SIPB-Athena
operating system. A more flexible model, which would
depart much more from the current Athena model, might let
you specify in your local filesystem that your machine was a
"beta" machine, say, and then save_cluster_info would figure
out somehow what the beta cluster information is right now.
