[3087] in SIPB_Linux_Development
Re: SIPB Installer Bugs: Custom Install
daemon@ATHENA.MIT.EDU (Camilla R Fox)
Wed Oct 11 18:26:02 2000
Message-Id: <200010112225.SAA13104@tomb-of-the-unknown-dominatrix.mit.edu>
To: Alex Coventry <alex_c@MIT.EDU>
cc: warlord@MIT.EDU, linux-dev@MIT.EDU, cfox@MIT.EDU
In-Reply-To: Your message of "Wed, 11 Oct 2000 16:02:03 EDT."
<200010112002.QAA08305@w20-575-38.mit.edu>
Date: Wed, 11 Oct 2000 18:25:56 -0400
From: Camilla R Fox <cfox@MIT.EDU>
The more we constrain what we're going to allow, the better the quality
of product we'll be able to manage. We're having a hard enough time
finding person time for this project that adding features is a low
priority.
alex_c writes:
> My main concern with the custom installer is that it means there may be
> more non-standard configurations out there that we're going to be
> expected to help with, because they arose from our installer. Someone
> who is competent enough use the custom installer is going to be able to
> grab extra rpm's themselves, so the advantage of including it doesn't
> seem that great to me. On the other hand I would think that providing
> the custom install option to everyone greatly increases the risk that
> people who don't know what they're doing end up with a broken
> configuration that they expect us to help them fix. Perhaps someone
> with more experience in tending to a widely used distribution would have
> a better idea of how serious this risk is.
I'm mostly with Alex, here. Given how owls has pledged I/S support for
machines installed with our installer, it seems poor to let it make
non-supportable configurations easy to do.
The product we're putting out is a very specific one. We can
accomplish this best by not giving people room to hurt themselves with
it. I did put a pretty stern warning about the custom install in the
one-sheet but apparently it's not being heeded.
warlord writes:
> Is there some way that we could provide two different installers
> (perhaps based upon which install floppy you use?) This way we can
> have one install server but two installers (ours and the default
> RedHat installer). Would that work?
Note that we're using a vanilla redhat floppy, and doing everything in
the second stage installer. This means essentially a whole new NFS
exported directory. If someone wants to install Red Hat, getting
instructions from redhat's web page, and using a Red Hat mirror is the
way to go. There are Red Hat mirrors on faster subnets than the SIPB
server subnet, and I don't see what we'd be adding to the community by
running a redhat mirror.
> what isn't. I would like to be able to install a machine that can
> work on or off the net, but still be Athenized.
Installing extra packages was one of the most annoying things about the
first cluster pilots. Lots of local software (such as screen, pine,
etc.) ended up early in people's paths, and didn't play nice with afs.
We don't want people to hurt this way unless they really stand up and
ask for it.
The large size of IS-linux-athena is also a bummer, but there's not
much we can do about it. Ripping things out is harder than adding
them, in terms of making the dependencies work.
On a different note, if we wanted to support different configurations,
perhaps we should look into documenting how to do this the Athena way,
so that a customized machine will still be able to take automatic
updates. This might even take the form of writing mkserv scripts to do
popular things.
Another thing that would be nice is a run level that is sane for
off-the-network use. I hear various people are making them work on
their laptops. A standard laptop configuration (with tether
instructions, and off the network support) would be really neat, and is
something we can do.
-Camilla
