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
