[Yum] groupreq and yum 2.6

seth vidal skvidal at linux.duke.edu
Tue Apr 18 22:32:51 UTC 2006


On Tue, 2006-04-18 at 14:48 -0700, David Lutterkort wrote:
> On Tue, 2006-04-18 at 15:42 -0400, Brian Long wrote:
> > The classes of machines are defined in profiles in make_bootdisk, a CGI
> > that generates ks.cfg and PXE configuration (part of http://kickstart-
> > tools.sf.net).  These profiles might be named for the class of machine
> > like "Engineering Workstation" or the CGI might offer checkboxes of
> > optional yum groups that can get installed if the end user would like.
> > 
> > The CGI is configured such that Engineering Workstation installs certain
> > yum groups but right now it's at a high level and we rarely change it.
> > We typically change the yumgroups.xml file and re-gen the repos.  If I
> > move the source of truth from yumgroups.xml to each profile, it's
> > increases my maintenance cost.  For each profile that references a
> > single nested yumgroup, I'd have to edit manually if I can no longer
> > nest yumgroups.  For example, if the yumgroup "Engineering-Workstation"
> > contains "Base-Workstation", "RealPlayer", "Xine", etc.  I'll have to
> > list each of those subgroups in all the Engineering Workstation
> > profiles.  Right now, if I need to make a change to all Engineering
> > Workstations, I change the Engineering-Workstation yumgroup and regen
> > the repos.
> 
> This is not directly connected to your question about yumgroups, but it
> seems that you are using yumgroups very similar to how classes are
> traditionally used in config management tools like cfengine. Instead of
> using yumgroups to express similarities between machines, have you
> thought about using a config management tool to express the desired
> state of machines ? Depending on what exactly you need to do to
> kickstart to a specific profile, this might also save you from building
> config-only rpms.
> 
> I've been looking at puppet [1] quite a bit and have written a tutorial
> on how it can be used to model the kind of layering you are doing with
> yumgroups [2] We are also working on a simple tool to help distribute
> and manage 'system recipes' based on puppet [3].
> 
> I would appreciate any feedback on these things, in particular the idea
> of moving away from using rpm's as the _only_ means of expressing the
> desired configuration of machines.
> 

Does puppet offer any way of notifying about and acknowledging newly
created keys for machines so admins can determine if they should be
allowed access or not?


-sv





More information about the Yum mailing list