HP PSP installation
Gajillion
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
David Schmitt
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
Gajillion
> 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.
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.
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.
platforms and environments. The second list will vary based on the
server environment, but I think I can get around that.
David Schmitt
>> 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?
Duncan Hill
>
> 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.