[Puppet Users] Re: Patch Automation By Puppet
Hi Mahabubur, We use Puppet to configure Ubuntu's unattended-upgrades package, which takes care of nightly updates for us. Our Puppet only takes care of installing and configuring the package, for example: do we want only security-updates or all updates, who do we email on failure, which packages do we skip, etc.. The actual updates are installed by unattended-upgrades. Some modules are available for this: https://forge.puppet.com/tags/unattended-upgrades Regards, Martijn -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/596d1881-240e-458c-ac54-d3f08790df72%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Patch Automation By Puppet
It really depends on the OS and how you want to handle it.
Puppet already has the package (
https://docs.puppet.com/puppet/latest/type.html#package) with the option
*ensure
=> latest,* that will keep the package at the most recent patches available
in repos defined on the hosts.
If you want to patch everything your manifest can be as simple as an
* exec{ 'yum -y update':*
*path => ['/usr/bin', '/usr/sbin',},*
* }*
It really depends on what you want to accomplish.
Providing you have the puppetlabs/stdlib module installed you can use
*strftime* to pull in the current date/time to assign to a variable. If you
use a smart class parameter, *class x ( $somevar="something", ) { puppet
block }*, you can change override the smart class variable to be the date /
time you the current date/time must exceed to run your patching. Even more
complex setups would have it so that you have *$window_start *and
* $window_stop* variables to control when Puppet will even consider
patching.
Basically it will all come down to the OS you are used, the patching
commands (yum, dpkg, zypper) required to handle the process.
The best way to get this worked out is to figure out exactly how your
process will go, what depends on what and then pseudo code it to follow the
login through. Then start looking to see what Puppet can do for you
natively and what you will have to do via exec, custom facts or defines.
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2bebcb7b-5aa0-4e02-a396-e55e9674080b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Patch Automation By Puppet
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 puppet-users+unsubscr...@googlegroups.com.
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.
