'everything' install option in FC5test1

Rudi Chiarito nutello at sweetness.com
Sun Nov 27 20:50:33 UTC 2005


On Sun, Nov 27, 2005 at 08:55:42AM -0800, Jesse Keating wrote:
> When Anaconda can look at more repos than just Extras (think FC6)
> wouldn't it make more sense to have your own yum repo with group
> definitions for each system profile?  Then you can tell anaconda's yum
> to group-install <foo>.  After the install, yum update will do the
> updating work.

I already maintain a local yum repository.

The nice thing about cfengine is that it defines a lot of classes. When
running on x86_64 it will define 64_bit rather than 32_bit, for FC4
systems it will define fedora and fedora_4, plus other classes whose
names are derived from the IPv4/v6 address and subnet, running kernel
version, etc. You can define your own classes, too (e.g.
kickstart_server for your kickstart servers).

You can then apply actions including or excluding any number classes,
using boolean and/or/not/grouping operators. I use that to build a list
of packages that derives from all the classes the system belongs to. 

You could use cfengine to pass a number of group names to be used for
yum's groupinstall/update, but then you need to enforce that the
addition of a new group happens in the yum repository first. Plus,
keeping information in yet another place is inconvenient if, like me,
you keep the cfengine configuration files under revision control (you'd
probably want cfengine to generate the yumgroups.xml file for you in
that case).

If packages are all you want to manage then, yes, yum groups are viable
and cfengine is overkill - just generating and distributing the
cryptographic keys is too much effort for such a small return.

Especially if you have a large number of systems, though, you'll want to
go for something like cfengine and even do as much as possible with it.
I use it to tweak ldap.conf/nsswitch.conf/system-auth, install PPD files
and printers for CUPS, set up the NTP servers and clients, replicate
files, add/mount NFS shares in fstab, turn on init.d services, set up
NAT on cluster masters, manage virtual IPs, etc. This has helped
cut down on the number of permutations of kickstart files I keep. At
some point I realised that Anaconda's kickstart mechanism is never going
to cover all your needs and huge post-install sections were not the
solution (plus I needed something to automate changes that come up after
the system has been installed).

BTW, cfengine is being rewritten for version 3. I also come across
puppet, which looks promising: http://reductivelabs.com/projects/puppet


-- 
Rudi




More information about the fedora-devel-list mailing list