[1403] in SIPB_Linux_Development
Re: comment on RedHat-Athena dist...
daemon@ATHENA.MIT.EDU (Derek Atkins)
Tue Aug 27 14:23:30 1996
To: Edwin Foo <efoo@MIT.EDU>
Cc: linux-dev@MIT.EDU
In-Reply-To: Your message of "Tue, 27 Aug 1996 08:38:28 EDT."
<199608271238.MAA11932@kabuf.mit.edu>
Date: Tue, 27 Aug 1996 14:22:21 EDT
From: Derek Atkins <warlord@MIT.EDU>
> Hello there. I took a look at Derek's alpha version of RedHat-Athena
> after reading the announcement in the discuss archive of linux-dev,
> and it looks good. There's a couple of questions I have though
> before I go ahead and commit to the "upgrade" (as in use Athena RPMS
> instead of simply untarrin the packages like previously):
First, the tarfiles are old, out of date, mostly unsupported, and are
probably going to go away once the RedHat-Athena goes out of alpha.
But besides that....
One other thing. If you use the RPMS you gain the ability to upgrade
easily in the future.. So when new Athena software is released it is
easy to upgrade to it.
1) Will anyone be willing to track releases of new/updated packages
as they become available and put them into the RPM tree? I ask
because the mirror as we have it is a direct copy off the RedHat
FTP site, which is fine. It's just that there's a whole bunch of
new/updated packages that also sit on the RedHat FTP site that
fix bugs, security holes, etc.
(ftp://ftp.redhat.com/pub/contrib/RPMS &
ftp://ftp.redhat.com/pub/updates-i386).
Yes, I do plan to do this. I wanted to get the installation working,
first, before installing the upgrades. I do plan to fix the
installation with all of the 3.0.3 security fixes and eratta.
If anything, I'd like to propose that we mirror those directories
if possible on small-gods. Many of the updated packages in
(...)/updates-i386 in particular fix some fairly serious security
holes/bugs, such as the updated version of RPM (2.1.2 vs. 2.0.2),
Perl 5.003 instead of 5.001, etc. Having access to a local mirror
would help a lot, I think.
I do plan to keep a local mirror, and I also plan to update the actual
installation site when I can (or when I think it is necessary). As
for upgrading RPM, well, perhaps... There aren't any security holes
in RPM 2.0-2.
Personally, I think it'd be much nicer if people didn't have to
install RedHat 3.0.3, and _then_ upgrade with all these other RPMS.
If they could be folded into the default installation it'd be nice.
But I don't know how RPM installation scripts work, so I won't demand
that this be done.
Well, it depends what "upgrades" you are proposing.. Some of the
upgrades I plan to merge into the installation. Some of them I plan
to leave for the user to do by him/herself. In addition, I think it
would be useful to mirror all the upgrades anyways, in case users
install a system and then want to upgrade in the future.
2) Question for Derek: what kind of approach are you taking towards
the package selection? The default RedHat installation includes a
bunch of packages that already exist on AFS in various lockers (perl,
for example). Do you intend to install only a minimal system and run
everything else off AFS (ala NetBSD), or will we continue to just
kind of install everything but the kitchen sink, and tack on a few
Athena-specific packages? Miminalist installations probably have
benefits in terms of disk space requirements and upgradeability
since there's no need to store everything locally, and only the
AFS copy of a program needs to be updated for all workstations
on campus to get it.
I chose packages to make a slightly-more-than-minimalist client. I
installed OS packages locally that I thought would be useful to have
local, and I left many things that are available in AFS out of the
default installation. I do *NOT* install everything but the kitchen
sink -- go look at the Athena Client Configuration to see what I
actually do install.
Right now, Linux-Athena does not support an /svrd model. It was more
important to get the installation working with what we had than to get
an /srvd model working. So, for now, all of the Athena packages get
installed locally. However, the user could easily install Athena and
then rm -rf /usr/athena and symlink /usr/athena into AFS-land.
3) Is there a reason why the default cache size for Linux-AFS is 10
megs? I'm just curious; when I was using NetBSD the installation
defaulted to 40, and I think I've gotten much better performance
after increasing my Linux-AFS cache to 40 recently. But then, I
run a "miminalist" system and try to run programs off AFS as much
as possible to save local disk space, so this is just my 2 cents.
The only reason is that two years ago I thought 10MB was big enough to
be useful and small enough for people who were tight on diskspace. I
can easily up the value, or turn on AFSADJUST. So, no, there isn't a
good reason. I wanted to choose something as the default that would
be small enough to fit on most everyone's drive.
The problem is that we cannot force people to have a cache partition,
so there isn't an easy way to test the size. If people want to up the
size to something bigger, thats fine with me.
4) Has any of this been tested on the RedHat Rembrandt Beta yet?
I'm probably going to try that system pretty soon and install the
RedHat-Athena packages by hand, but I would like to know first if
there are any known incompatbilities.
No, and there WILL be imcompatibilities. RedHat-Athena is based on
RedHat 3.0.3. The RPMS in /mit/linux/packages/RedHat are not meant to
be installed by hand -- it is a staging area for the RedHat-Athena
installation. The packages have a specific order to get installed
which the installation procedure enforces.
Once the 3.0.3 RedHat-Athena installation is "stable", I plan to start
playing with Rembrandt. The problem is that I needed to change the
installation system in order to support a lot of the RedHat-Athena
installation. Since the Rembrandt system changed the installation
program, I have to re-implement all of my changes.
I do plan to make a RedHat-Athena based on Rembrandt in the near
future. I just want to get the 3.0.3-based system up and running,
first.
> Otherwise, it looks pretty nice. Congrats, Derek.
Thanks,
-derek
