Shrinking/splitting up core Was: Why are there only i686 and i586 Version of glibc...

Tom Diehl tdiehl at rogueind.com
Mon Jun 7 18:51:54 UTC 2004


On Mon, 7 Jun 2004, Steven Pritchard wrote:

> On Mon, Jun 07, 2004 at 08:24:11AM -0600, Stephen Smoogen wrote:
> > I dont think Anaconda is meant to look at anything beyond the bare
> > installation Cd's the rest should be done with first-boot. Maybe first
> > boot should have a yum configuration section where you can enter the yum
> > places you want to to point ot.
> 
> How's that going to work with kickstart-based installs/upgrades?
> 
> I'd really like to see a day where a person could fire up
> kickstart-based upgrades on 200 cluster servers and have *everything*
> upgraded when the systems reboot (assuming all of their local apps
> were in an appropriate repository).

For the most part yum can do this today. It is not perfect but machines
that I kickstart from scratch do a stripped down minimal install. In the
%post I then do a yum groupinstall somegroup. I have a comps file that
knows what packages are to be installed in the group. Generally the group
is the fqdn of the machine. That way I edit the group for that machine
and poof you have a very easy to reproduce machine. Upgrades for the most
part work today by simply doing a yum update. There are some problems with
FC1 -> fc2 upgrades with lvm involved but other than that AFAIK this is
doable today.

My feeling is that this is doable with a little more work.

Kickstart in its current form has the ability to do upgrades. It is a 
simple matter of putting about a dozen lines in the ks-cfg file and rebooting
the machine. You can launch this via pxe or from an entry in the grub.conf
file if you do not want to play around with cd's or floppies.

Someone mentioned on one of these lists in the last couple of weeks about
no longer doing upgrades but doing migrations. IIRC the general idea was
save all of the known config files somewhere format, install the new os,
restore the configs and presto chango you have a new working system.
I like the idea but I do not see how thay are going to account for all
of the variables. It will be interesting to see if they can make it work.

> FWIW, I was doing stuff like this with engineering workstations
> running HP-UX at a previous job 5 years ago using HP's Ignite-UX
> tool...  It still scares me a little that we don't have a tool even
> that good yet.
> 
> That employer is using a *ton* of RHL now, and upgrades are nearly
> unmanageable.  Paying for RHEL would reduce the frequency of necessary
> upgrades, and the money isn't necessarily a problem for them, but how
> would they do all those upgrades?  (In other words, I don't think this
> is just a problem for Fedora Core/Extras/etc. users.)

If you are upgrading from RHL to RHEL Red Hat says reinstall. Some
people have used yum with varying success. If I had a bunch of machines
to upgrade that is the path I would explore. If for whatever reason you
do not want to do RHEL there are always the clones. I have not used them
but I have heard some good things about them.

Tom





More information about the fedora-devel-list mailing list