[1483] in Release_7.7_team
Re: Automatic reinstall
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Tue Sep 1 05:56:17 1998
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Robert A Basch <rbasch@MIT.EDU>
Cc: release-team@MIT.EDU
In-Reply-To: Your message of "Fri, 28 Aug 1998 10:25:17 EDT."
<199808281425.KAA15637@kiko.mit.edu>
Date: Tue, 01 Sep 1998 05:56:12 EDT
rbasch> I'm unsure how much this might have been considered in the
rbasch> past, but I've been thinking that a helpful machine
rbasch> configuration feature, at least for IRIX, would be a flag
rbasch> indicating that the machine can be reinstalled automatically,
rbasch> i.e. contains no local data that needs to be preserved.
The concept of an automatic re-install has at least been thought about
before, but I'm not sure how seriously. It certainly seems like it is
worth consideing, since IRIX gives us enough power to actually do it.
rbasch> Beyond this, we could also implement a periodic automatic
rbasch> reinstall of machines, to help ensure system integrity, remove
rbasch> cruft, etc.
I'd prefer that our systems maintained integrity without the need for
this, but I admit that they don't always succeed. I'm not sure if
this is really the rigth way to solve teh problem, but it might be.
rbasch> Of course, the big problem keeping us from doing automatic
rbasch> installation is that (as far as I know) we can't tell if it's safe
rbasch> to do so on a particular machine. (A private workstation could still
ghudson> We have always felt free to arbitrarily bash machines with PUBLIC set
ghudson> to true. We don't need a separate flag here.
I'm not completely sure this is true. Certainly we've taken a lot
more liberties with them, but I cant think of anything else that we do
that would make /var/professor/problem-sets go away, for instance.
Are we positive that completely arbitrarily nuking a PUBLIC=true
machine is OK to do?
rbasch> Another issue is that we would probably want additional install servers
rbasch> if we needed to support large-scale simultaneous diskless booting.
rbasch> Again, though, the diskless boot is only necessary to repartition
rbasch> the disk; if the disk partition sizes are OK, the reinstall could all
rbasch> be done from a miniroot copied from the install AFS volume, as was done
rbasch> for the 5.3-6.2 update.
We could presumably also work with our desyncing code here (although
we probably should think about the problems we had with the 8.2 update :-)
Jonathon
