Puppet users - Jan 2013 - Dynamic yum.conf 'exclude' line

Hi All,

I have finally switched to using hiera (worthy goal!) and I am looking for
a flexible way to manage the ''exclude'' line in /etc/yum.conf.

I want to be able to specify from different classes RPMs to be excluded in
/etc/yum.conf, then build the exclude line from all those classes that set
an exclude.

In my hiera hierarchy, I use %{calling_module}, but I actually modify the
yum.conf exclude line from a "yum" module so of course setting
yum_excludes
in various classes and calling hiera_array(''yum_excludes'') is
not going to
work as the %{calling_module} will be "yum".

Any ideas?

Thanks!
Gonzalo

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thursday, January 24, 2013 6:01:46 PM UTC-6, Gonzalo
wrote:
>
> Hi All,
>
> I have finally switched to using hiera (worthy goal!) and I am looking for 
> a flexible way to manage the ''exclude'' line in
/etc/yum.conf.
>
> I want to be able to specify from different classes RPMs to be excluded in 
> /etc/yum.conf, then build the exclude line from all those classes that set 
> an exclude.
>
> In my hiera hierarchy, I use %{calling_module}, but I actually modify the 
> yum.conf exclude line from a "yum" module so of course setting
yum_excludes
> in various classes and calling
hiera_array(''yum_excludes'') is not going to
> work as the %{calling_module} will be "yum".
>
> Any ideas?
>
>
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.


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+unsubscribe@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.

On Sat, Jan 26, 2013 at 1:38 AM, jcbollinger
<John.Bollinger@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.

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?

- Gonzalo

-- 
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@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.

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<javascript:>
> > 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+unsubscribe@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.

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.Bollinger@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+unsubscribe@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+unsubscribe@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.