[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.