Usage of puppet to deploy and configuration manage software patches

[Christian]

I have some questions in terms of how to use puppet of configuration management for software patches. My previous approach was it to create a puppet module for each patch ... Like Patch1 includes (FileA, FileB, FileC), Patch2 includes (FileD, FileE)... So far so good and that works but now i have to create a Patch3 with lets say FileF and FileA included. As you can see there will be a puppet conflict as i can't deploy the same files within different modules. What is the right architecture and method to manage software patches? Is it to use rpms instead of? Or are there other ideas how to manage that with puppet.

[Nikola Petrov]

Hi,

If you should decompose them you can define them as different
classes. That however as you know will lead to an explosion of different
classes which can become pretty unmaintainable with time ...

The question is if you *should* do it this way. I don't know
so much about your system so I can't tell. We are mostly updating with
proper package management and build our software for upgrades.

Maybe if you tell us more about your system/setup, we can give you a better advice?

Best, Nikola

>
> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/YNceAdQNZr4J.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[Douglas Brancaglion]

Hi, 

if your S.O is Centos/Red-hat you can use SpaceWalk, puppet is not good for this .

Tks

2012/11/9 Nikola Petrov <niko...@gmail.com>

--
Douglas Brancaglion
Security Analist

[Keiran Sweet]

Hi There,

Looking at your module approach, I think you are heading for quite a bit of pain, I've found that packaging tools such as RPM are best for this kind of task.

In my environment which is all RHEL based I (roughly) do the following:

- I have a number of YUM repositories defined and presented to the network via HTTP

- By default, all nodes have the standard production baseline YUM repositories enabled by default

- I use top scope variables to enable additional YUM repositories that may contain later package versions or testing packages via the yumrepo type

- Once these additional repositories are enabled, I can then use yum update to bring hosts up to a specific baseline of the OS or software set.

- Once I am happy with the functionality of this new repo, I can either promote it to be the production baseline or something similar.

Here is some puppet logic that operates on the $::enable_testing_repos value, and enables the testing repo if it is true for a host, else it is left defined, but disabled.

                   yumrepo { $rhelsysupporttestingrepo :

                        baseurl  => $rhelsysupporttestingrepourl,

                        descr    => "TESTING System support packages",

                        gpgcheck => '1',

                        enabled  => $::enable_testing_repos ?   {

                                        'true'  =>  '1',

                                        default =>  '0',

                                    }

                    }

Re: Spacewalk - I've just moved my entire fleet from spacewalk / satellite to YUM via HTTP (Apache) with repos created with createrepo, etc and find it much faster and flexible.

Hope this is of some use.

Thanks,

K

[Jakov Sosic]

On 11/09/2012 05:04 PM, Christian wrote:
> Ihave some questions in terms of how to use puppet of configuration

You can do it with puppet, but it really isn't designed to do that. It's
declarative nature will make you a lot of trouble trying to implement
procedural tasks. So it would be much better to use technology that is
designed with that specific issue at mind - and that are the packaging
systems. So if you use RHEL/Fedora or derivates, by all means, you
should go with RPM and not stretch the puppet to the limits with ugly
hacks to accomplish things it isn't supposed to.