Take a look at the yum versionlock plugin. It allows you to lock a
particular package at a given version for situations like this. We use the
following define to manage our locked packages. If I were writing it today
I'd probably use file_line, but it's worked well for us so I've had more
important things to do.
#
# Actions:
# Implements a versionlock define to make version locking easy
#
# Requires:
#
# Sample Usage:
#
# To lock a package version:
# packages::yum::versionlock{ kernel-uek:
# epoch => '(none)',
# version => '2.6.32',
# release => '100.26.2.el5',
# }
#
# To remove a version lock:
# packages::yum::versionlock{ kernel-uek:
# epoch => '(none)',
# version => '2.6.32',
# release => '100.26.2.el5',
# ensure => 'absent',
# }
define packages::yum::versionlock ($epoch,$version,$release,$ensure =
'present',
$version_lock_list =
'/etc/yum/pluginconf.d/versionlock.list') {
include packages::yum
case $ensure {
present: {
exec { "yum_add_versionlock_${name}":
command => "/bin/echo '${epoch}:${name}-${version}-${release}' >>
'${version_lock_list}'",
unless => "/bin/grep -q '${epoch}:${name}-${version}-${release}'
'${version_lock_list}'",
require => Package['yum-versionlock'],
} # exec
} # case 'present'
absent: {
exec { "yum_del_versionlock_${name}":
command => "sed -i -e /'${epoch}:${name}-${version}-${release}'/d
'${version_lock_list}'",
onlyif => "/bin/grep -q '${epoch}:${name}-${version}-${release}'
'${version_lock_list}'",
require => Package['yum-versionlock'],
} # exec
} # case 'absent'
} # case $ensure
} # define
On Mon, Jan 28, 2013 at 6:40 AM, jcbollinger <john.bollin...@stjude.org>wrote:
>
>
> On Friday, January 25, 2013 4:05:37 PM UTC-6, Gonzalo wrote:
>
>>
>> On Sat, Jan 26, 2013 at 1:38 AM, jcbollinger <john.bo...@stjude.org>wrote:
>>
>>>
>>> Puppet's architecture does not lend itself to constructing values
>>> iteratively, and what Hiera brings to the table in that area does not apply
>>> to the scenario you describe. There are a couple of ways you might be able
>>> to work around Puppet's constraints there, but before you go that way I
>>> would suggest that you consider alternative strategies.
>>>
>>> Let's start with why you want to add package exclusions to yum.conf via
>>> multiple modules. I have some ideas of why you might be trying to
>>> implement such a design, but I'd prefer to avoid guessing.
>>>
>>
>> Hi John,
>>
>> Thanks for your reply.
>>
>> To be honest, I think in this particular case it's more about trying to
>> work out how to solve this type of problem, perhaps not necessarily useful
>> with this exclude line issue. One hypothetical example might be
>> constructing a "users=" line for some config file and I want to set users
>> from various modules to construct the line.
>>
>
>
> As I said, Puppet's architecture does not lend itself to that kind of
> thing. In particular, variables and resource properties can be assigned
> values only once each. Moreover, it is pretty much always a mistake for
> manifest sets to attempt introspection, as this introduces unneeded extra
> sensitivity to manifest parse order. Instead, one generally needs to step
> back and take a different approach.
>
> One such approach might be to build up your data in a custom external node
> classifier (ENC), which provides it to your classes via either a global
> Puppet variable or a class parameter.
>
> Another approach is for modules to declare independent resources instead
> of collaborating on a single resource. The Concat add-on module, for
> example, provides a way to implement that for files. You could, in
> principle, implement similar facilities to serve other purposes.
>
> Or you may find that you don't actually need quite the degree of
> flexibility you describe after all.
>
>
>>
>> For this exclude line question, I have a class that many nodes "include"
>> and they all need to exclude one particular RPM to ensure a "yum update"
>> never upgrades it. These same servers "include" another class, which also
>> have a package to be excluded. Do you have any ideas on how to solve this
>> type of problem?
>>
>>
> For packages in particular, you have additional options:
>
> 1. In your Package declarations, you can use ensure => 'present' or
> even ensure => '<package-version>' instead of ensure => 'latest'. That
> won't prevent a manual package update, but it will prevent Puppet from
> performing unwanted package updates. The variation where you specify a
> package version may even get Puppet to revert unwanted manual updates.
> 2. You really ought to take control of your package repositories.
> Creating and curating local repositories not only ensures access and
> reduces demands on your network connection to the outside world, but it
> also allows you to exercise complete control over what packages are
> available for installation / update. Depending on your package management
> system, local repositories may confer additional benefits. For example, on
> 'yum'-based systems you might consider looking at the yum-priorities and
> yum-protectbase plugins.
>
> John
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
>
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
