[2965] in testers
Release 8.0 rc.conf on Suns
daemon@ATHENA.MIT.EDU (Mike Barker)
Thu Jun 20 23:27:29 1996
From: "Mike Barker" <mbarker@MIT.EDU>
To: testers@MIT.EDU
Date: Thu, 20 Jun 1996 23:27:19 EDT
Machines culled from the snmp_data report that Tom generated:
* indicates that the machine seems to have a name, but no address
@ indicates MIT-HOSTNAME and MIT-ADDR (i.e. fake names, not real)
W20-575-8, 10, 15, 95, 109, 113, 115, 119, 120, 122, 124, 125,
126, 127, 128
test-sun2
kenworth
sum-1, -2, -3
imf
nber
aea
hanta-yo
herodotos
blue-technology-group *
pronto
mus-ref-1
hayden-1, 2, 3, 4, 6, 8
eos-4, 6, 8, 10, 14, 15, 16
barrett-1 *
england @
creep
seawolf
mcrae @
silver
m16-034-15, 16, 19, 21, 22, 23, 24, 26, 27
roylance
rotch-ref-1
mountain-dew
m11-113-7, 8, 10
jsbach
be-our-guest *
lattice
lind-ref-1
rhum @
wedlock @
caes-sun-1, 5
w91-230-1 @
That's all.
Approaches:
1. Do 7.7Y to fix. I would rather save 7.7Y (and Z) just in case
there is some serious bug left in 7.7 that needs handling to
get systems to 8.0.
2. Get a "fixit" patrol to visit these 71 machines. Ask
permission, then do the fix, and go on to the next machine.
3. Ask the owners to fix the private ones, and we'll take care of
the public ones. Assuming that a small utility could (a)
remove the existing HOST and ADDR lines and (b) put correct
ones in place, asking the owners to run such a utility does not
seem impossible.
4. Wait. When the machine blows up trying to update, reinstall
it. Presto, problem disappears. I don't like this because it
feels like we're letting the problem go unchecked, but it is
simple.
5. Some mixture of the above. E.g., "fixit" patrol for the
public, warning and/or utility for the savvy owners, and let
the others get picked up by reinstalling?
I recommend 5, but since I'm about to disappear, if someone else
has a better idea or something, let Bill know and do it!
Mike
