[19747] in Athena Bugs
Re: sun4 8.4.26: oscheck
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 5 09:43:09 2001
Message-Id: <200109051343.JAA15358@egyptian-gods.MIT.EDU>
To: Jonathon Weiss <jweiss@MIT.EDU>
cc: bugs@MIT.EDU
In-Reply-To: Your message of "Tue, 04 Sep 2001 21:00:39 EDT."
<200109050100.VAA00566@neuterpe.mit.edu>
Date: Wed, 05 Sep 2001 09:43:06 -0400
From: Greg Hudson <ghudson@MIT.EDU>
Okay, there are four reasons why this doesn't worry me too much:
1. In most cases, a public 8.4 machine becomes a public 9.0 machine
before too much time passes. So I doubt there are very many
public 8.4 machines out there which we trashed.
2. Trashing a public machine doesn't cause a loss of data (or at
least, I hope there aren't lots of people putting important data
in /var on public machines).
3. We need to put out an 8.4 patch release with new AFS modules soon
anyway, which will rectify the problem for machines which stay up
until then.
4. ops is presumably not very inconvenienced by this for installing
servers because they can just copy /kernel/fs/afs back in when
they make the machine non-public.
So I don't think we need to go to any heroics to unscrew public 8.4
machines. We just need to fix the problem by removing the
kernel/fs/afs line from stats.common.
(There are some other srvd paths in the 8.4 stats.common--paths like
/usr/afsws and /etc/init.d/afs which don't include the word "athena",
but the 9.0 stats.common seems to be clean of them based on spot
checks.)
And we should fix os_checkfiles (in 9.0) to check that a file is
present in /os before we nuke it for updating, so that we don't run
into this kind of potential catastrophe again. I assert that that's
on Bob's plate.
