Having been foolish enough to say "Sure, we can do that" in response to the
relatively complicated patch scenario my supervisor wanted us to implement,
I can offer advice, if not code-- Our code is heavily dependent on our
environment, and probably wouldn't make much sense. It's also fairly
hideous, so I'd rather not incriminate myself. ;)
The biggest lesson I learned when trying to do patching with puppet, is if
it's anything beyond "package { ensure => latest }", don't do it with
puppet.
Puppet is very good at configuration management-- But not so good at
process management, by which I mean, puppet isn't very good at making a
sequence of events happen in the right order, at the right time.
Initially, I tried to manage the patch process directly with puppet, and it
nearly broke my brain... and the end result wasn't terribly stable, or easy
to debug. Now that I've become much better at Puppet, it might have turned
out differently, but I still try to live by the rule that Puppet manages
configurations, rather than processes.
So I use puppet to deliver the appropriate scripts and configuration files
that I use for my patch process-- I have a Debian wrapper script, and a Red
Hat wrapper script, both of which read configuration files-- I have a cron
job or two which does the prep work for the patch cycle, and I keep the
patch configuration data inside Hiera-- otherwise, all the patch "logic"
takes place on the managed host, rather than the puppet server.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/8a7767e8-6f4e-4f82-bd32-886fe2e4bdb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
