[3090] in SIPB_Linux_Development
Re: SIPB Installer Bugs: Custom Install
daemon@ATHENA.MIT.EDU (Derek Atkins)
Thu Oct 12 10:05:39 2000
To: Camilla R Fox <cfox@MIT.EDU>
Cc: Alex Coventry <alex_c@MIT.EDU>, linux-dev@MIT.EDU, cfox@MIT.EDU
From: Derek Atkins <warlord@MIT.EDU>
Date: 12 Oct 2000 10:05:46 -0400
In-Reply-To: Camilla R Fox's message of "Wed, 11 Oct 2000 18:25:56 -0400"
Message-ID: <sjmy9zuxih1.fsf@rcn.ihtfp.org>
Camilla R Fox <cfox@MIT.EDU> writes:
> 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.
Agreed.
> 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.
I'm sorry, but I can't agree with this. SIPB can not and SHOULD not
be constrained by what owls pledges I/S support. SIPB does not report
to owls, and we should not let owls constrain our projects based on
their decisions. If owls wants a specific product, then they should
get the I/S funding to create that specific product; they should not
depend or require SIPB to create that specific product for them.
This doesn't mean that we cannot choose to limit the "product" that we
are creating. However, then it is our CHOICE to make that product and
limit it in those ways. SIPB should be creating products that SIPB
believes meets the needs of its "customers". If we believe that
students want to have custom installs, then it is our obligation to
support that for them, regardless of the product that owls wants.
> 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.
Really? I was under the impression that we were just creating a
RedHat installer to install an I/S Linux-Athena machine, whatever that
means. Previous SIPB RedHat-Athena installers had custom installs,
and it was never a problem.
> Note that we're using a vanilla redhat floppy, and doing everything in
> the second stage installer. This means essentially a whole new NFS
Um, why? IMHO, this complicates the install needlessly. You could at
LEAST hard-code the MIT subnetting information, default gateway, DNS
server, and install server into the install floppy. It really does
solve a good number of tech-support calls by people who just can't
remember the server name or can't seem to type it right.
It's a relatively simple change to the install floppy, and it's a
change that we HAVE made in the past. Indeed, with the SIPB 5.2
installer, you needed to know your IP address and practically nothing
else. This was a Good Thing (TM). The average install involved
hitting return a good number of times, typing your IP address, and
then hitting return a few more times.
> 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.
There are? Where?
FWIW, it has been useful, in the past, to tell people to find the
RedHat mirror at sipb-nfs:/redhat/...
> updates. This might even take the form of writing mkserv scripts to do
> popular things.
I would think that Athena would be interested in this as well. Does
mkserv even EXIST in Linux-Athena?
> 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.
Agreed. I've worked on this for me. It would REALLY just require
patches back into the Athena packages. Either that, or we can create
a "laptop" package that has no files but a bunch of scripts that run
chkconfig commands. The former is certainly cleaner, however IIRC I
had to make changes to non-Athena packages as well to get runlevels 2
and 4 to be my non-network, non-X and X runlevels.
> -Camilla
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
warlord@MIT.EDU PGP key available
