[1698] in SIPB_Linux_Development
Re: Redhat 4.2/Linux-Athena
daemon@ATHENA.MIT.EDU (Derek Atkins)
Wed Jun 4 15:15:08 1997
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: Erik Nygren <nygren@MIT.EDU>, Chris Murphy <chris@MIT.EDU>,
linux-dev@MIT.EDU
From: Derek Atkins <warlord@MIT.EDU>
Date: 04 Jun 1997 15:14:53 -0400
In-Reply-To: "Theodore Y. Ts'o"'s message of Wed, 4 Jun 1997 14:15:44 -0400
I think there are multiple issues here.
1) How do machines get installed with RedHat-Athena?
2) How do RedHat-Athena machines work when they are not on the
network all the time?
I do not believe that these issues are at all related to each other.
The method of installation is completely orthogonal to the current
problems of semi-connected machines.
First, an assumption: A machine needs to be on the network to use the
Athena subsystem. This can mean a full-time or a part-time
connection, it doesn't matter. But in order to use the Athena
applications, a machine must be connected. Is this a reasonable
assumption? If not, let's rm -rf /mit/sipb-athena and start over from
scratch.
Now, let's deal with these problems in reverse order. Right now, the
major problem with Linux-Athena and part-time connections is that:
a) network activity is run at boot time, when the network
isn't connected, and
b) Athena isn't tied into the network up/down scripts.
This problem is there regardless of the installation method. It
exists whether or not the programs are sitting on the local drive or
off in AFS. This problem needs to be corrected. Two things need
to be done:
i) athena.init needs to make sure the network is running
before it does anything, and
ii) the network up/down scripts (PCMCIA/PPP/etc.) need to run
athena.init after the network is brought up, and before the network is
brought down.
So far we've not even mentioned SRVD or RPM. Notice that?
The next question is the installation mechanism. The installation
mechanism assumes network connectivity (how else could you NFS-mount
small-gods?). Since we're already assuming network connectivity, then
it's safe to assume that we can start with an SRVD and then copy files
local as needed.
I don't see why it matters how "/usr/athena/bin/kinit" arrives on the
host. I mean, whether it arrives from an RPM or whether its copied
out of AFS at the first reboot after the installation.... Why does it
really matter? Also, is it really a problem if, say,
/usr/athena/bin/zwrite points off into never-never land while your
laptop is off the network? And if it is a problem, use spm to bring
zephyr local.
Erik, you asked about weird hardware. Well, the default kernel that
comes with redhat doesn't deal with weird hardware in the first place.
You asked about an SMP machine; redhat's kernel isn't SMP. What would
happen is that the user would install RedHat-Athena which would give
them AFS and an SRVD. If they wanted SMP support, they'd have to
recompile their own kernel anyways. When they do that, they can run
spm and bring the Athena packages local to the machine. Problem solved.
Basically, Ted, RPM and the redhat installation doesn't deal well with
having multiple RPMS that contain the same filenames where each
instance of the file is different. In other words, you can't have two
RPMS which both contain /usr/athena/bin/kinit, where in one RPM its a
file and the other its a symlink. You'll get an error if you try to
install both RPMs.
Another problem with the current system is that every file in the SRVD
has to be in some Athena package. Currently, this isn't the case.
That means that users aren't even installing all the programs that are
built. For example, did you know that enscript was built for Linux?
I bet it isn't on your machine....
The point of this exercise was to allow the user more flexibility in
choosing what files got installed locally vs. what files came from an
srvd, while at the same time simplifying the installation procedure in
general. I believe that the SRVD/SPM solution does that.
Assuming we fix the Athena + semi-connected-network problems, can you
explain how the SRVD/SPM installation solution doesn't work for
laptops or home machines?
-derek
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
>
>
> It shouldn't be too much work to keep RPM control files around which
> made it possible for people to generate RPM files from the SRVD tree of
> binaries; after all we already have the control files!
>
> I (like Erik) would also find it very convenient to be able to grab
> pieces of Linux-Athena and install them on my laptop. Granted laptop
> users may be in the "minority", yet I think it would be useful to have a
> solution which would work for them.
>
> If the current RPM control files are going to be abandoned because
> people want to have a solution which is more catered towards the
> always-connected desktop world, I'd be willing to take over maintaining
> RPM's for those people who only want "parts" of the Linux-Athena
> sources. (Last time I checked, I had to hack my Linux-Athena setup so
> that my machine didn't hang during the boot sequence when it was off the
> net, so there are a bunch of fixes which I want to make to some of the
> configuration files anyway....)
>
> As far as problems in terms of keeping the RPM files up to date, the
> generation of RPM files should be automated, to the point where we can
> run a script a generate fresh RPM files given a particular SRVD release.
> This shouldn't be Rocket Science, people.....
>
> - Ted
--
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
