Hi, I''m a newb to puppet but have a good deal of experience with CFEngine. We want to replace CFEngine in our environment because of its monolithic nature. As a proof of concept, I''d like to duplicate a particular function we''ve always had trouble with in CFEngine - installing HP PSP on our Redhat based ProLiant series servers. The logic is relatively simple, but execution can get complicated due to inconsistencies in Redhat package dependency handling: 1) Look for installation tool dependencies (gcc, rpm-build, kernel- headers, etc.) 2) Install required tools that are missing 3) Run the HP PSP installation script with pre-packaged XML descriptor file 4) (and this is the tricky part) Uninstall any tools installed in step 2. In other words, the output of "rpm -q -a" before step 2 and after step 4 should look identical for the most part, save the actual HP packages installed via the PSP install script. DEV boxes should still have gcc installed, but PROD boxes shouldn''t. I''ve got the "Pulling Strings with Puppet" book but I''m afraid it doesn''t go into as much depth as a I need for this. I''ve looked at some other recipes and the installation part is clear, but the removal of packages that were not previously installed is a bit tricky and haven''t seen anything like that. Anyone have some clues where I should be looking? Anything with any of those attributes out there that I can use to hobble together a prototype proof of concept? Thanks, Mark --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Gajillion schrieb:> Hi, > I''m a newb to puppet but have a good deal of experience with > CFEngine. We want to replace CFEngine in our environment because of > its monolithic nature. As a proof of concept, I''d like to duplicate a > particular function we''ve always had trouble with in CFEngine - > installing HP PSP on our Redhat based ProLiant series servers. > > The logic is relatively simple, but execution can get complicated due > to inconsistencies in Redhat package dependency handling: > > 1) Look for installation tool dependencies (gcc, rpm-build, kernel- > headers, etc.) > 2) Install required tools that are missing > 3) Run the HP PSP installation script with pre-packaged XML descriptor > file > 4) (and this is the tricky part) Uninstall any tools installed in step > 2. > > In other words, the output of "rpm -q -a" before step 2 and after step > 4 should look identical for the most part, save the actual HP packages > installed via the PSP install script. DEV boxes should still have gcc > installed, but PROD boxes shouldn''t. > > I''ve got the "Pulling Strings with Puppet" book but I''m afraid it > doesn''t go into as much depth as a I need for this. I''ve looked at > some other recipes and the installation part is clear, but the removal > of packages that were not previously installed is a bit tricky and > haven''t seen anything like that. > > Anyone have some clues where I should be looking? Anything with any > of those attributes out there that I can use to hobble together a > prototype proof of concept? Thanks,puppet is a steady-state management system, where you specify the target and puppet works out how to get there. Installing and removing packages in a single step doesn''t fit into that model at all. If there is no possibility at all to pre-compile packages from the PSP (e.g. by re-using an imaging server or stow or something similar) then I would a) hate the vendor and b) create a single script doing an unattended PSP install which is called by puppet when needed. If you really want to force this into puppet proper, you need a list of all packages needed by the installation, and -- for each server -- a list of packages out of this set that should be always installed. Call the first list $necessary and the latter $always. The list of unneeded packages, $removables, is obviously $necessary - $always. Adjust for the PSP''s dependencies as necessary. Now you can do something like this: # execute a script that does a "yum install $necessary" # and then installs the psp exec { "/usr/local/bin/psp_install": } package { $removeables: ensure => purged, require => Exec["/usr/local/bin/psp_install"] } Regards, DavidS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> puppet is a steady-state management system, where you specify the target > and puppet works out how to get there. Installing and removing packages > in a single step doesn''t fit into that model at all.I''ve actually been thinking about doing this in a multistage fashion using the current state as the steady state: state 1: PSP not installed, no support tools installed - puppet action: install support tools state 2: PSP not installed, support tools installed - puppet action: install PSP state 3: PSP installed - puppet action: check server class, uninstall support tools based on server class It may take several hours to install the PSP, but I''m looking at thousands of servers so that doesn''t concern me. It just seemed to be to shoe-horning the problem to fit the solution.> > If there is no possibility at all to pre-compile packages from the PSP > (e.g. by re-using an imaging server or stow or something similar) then I > would a) hate the vendor and b) create a single script doing an > unattended PSP install which is called by puppet when needed.Oh, we got all KINDS of HP hate going on over here over this :) We have tried the pre-compilation route, and the issue is that it loads kernel modules that are minor rev sensitive. We have to have i386, x86_64, x86_64 largesmp, and ia64 versions built for every flavor of kernel in the environment. It became unmanageable very quickly. We currently are using an unattended PSP install script too but that''s what I''m trying to get away from. It''s becoming woefully unweildy because of differences in the way RHEL4 and RHEL5 do package installation, and different package dependencies between different flavors of RHEL. That''s why I was hoping to use puppet to resolve those dependencies and install the appropriate tools without having to figure it out on every single variation of server.> If you really want to force this into puppet proper, you need a list of > all packages needed by the installation, and -- for each server -- a > list of packages out of this set that should be always installed.We have both of those. The first list is the same across all platforms and environments. The second list will vary based on the server environment, but I think I can get around that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Gajillion schrieb:>> If you really want to force this into puppet proper, you need a list of >> all packages needed by the installation, and -- for each server -- a >> list of packages out of this set that should be always installed. > > We have both of those. The first list is the same across all > platforms and environments. The second list will vary based on the > server environment, but I think I can get around that.I can imagine that the latter might be a problem, but in the end you really want to control all significant packages by puppet, which makes this problem go away. Mostly. At least you should get fine grained error messages, when two parts of the config want to do different things to the smae package ;-) Regards, DavidS PS: slightly OT: is there _any_ hardware/systems vendor who actually does "get" Linux/open source instead of trying to force spiked kludges onto customers? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
2008/10/31 Gajillion <gajillion@gmail.com>:> > Hi, > I''m a newb to puppet but have a good deal of experience with > CFEngine. We want to replace CFEngine in our environment because of > its monolithic nature. As a proof of concept, I''d like to duplicate a > particular function we''ve always had trouble with in CFEngine - > installing HP PSP on our Redhat based ProLiant series servers.Our approach was a little different. We have a standard distribution that goes on all machines. Puppet knows which packages to lay down, the order to do it in, and how to tell what network driver to load (tg3 for the G4s, bnx2 for the G5s). It also deals with the modifications to the sudoers file, snmp configuration etc. Doesn''t work when you''re trying to do multiple OS though, at least not without a pile of work. We also don''t have the situation where the support pack is already installed. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---