Puppet users - May 2010 - Is there a way to pass options to rpm provider of package resource?

Hi,

I am new to Puppet.

After having read quite a bit through the online puppet docs, as well
as wiki posts and James'' "Pulling Strings with Puppet" I
installed a
puppet master on an RHEL 5 box and one puppetd on an HP-UX box (which
was a bit of a challenge owe to the notorious Ruby agnosticism of that
platform) and one on another RHEL 5 box.
I verified that the basic functionality was given, after signing of
the nodes'' SSL certificates,  through a few tests with most trivial,
e.g. file resource, definitions in the master''s site.pp.

Then I wanted to create something more useful and tinkered up a first
class definition to aid me in deploying nagios/nrpe clients on the
Redhattish (i.e. RPM based) nodes.

Here I stumbled over a few issues of which one is,

if there exists a posibility to pass (additional) options to the rpm
command on the affected puppet nodes
which I guess will be executed (by some system call or forked pipe?)
on behalf of puppet''s RPM provider for redhattish systems?
In the resources'' online doc for "package" however, I
couldn''t find
any attribute that sounded fitting for this purpose.
In particular, I want to pass a "--nodeps" option to the rpm command
because the prebuilt rpm binaries that I intend to have installed
through Puppet exhibit partly pretty odd dependencies.

E.g.

# rpm -qR nagios-plugins-nrpe|grep nagios
nagios
nagios-plugins

or

# rpm -qR nagios-plugins|grep -i snmp
perl(Net::SNMP)


As for the first, I do not wish to have the Nagios server (which is
packaged in "nagios") installed on every nrpe node,
and for the Nagios Plug-ins, nor do I want to have the perl-Net-SNMP
rpm installed
(which itself most likely will depend on a net-snmp rpm) on every nrpe
node either
because I do not employ any SNMP-based Nagios plug-ins.

Since Puppet is open source of course there will be some way, at a
pinch presumably by overriding the rpm provider.
But for now I am looking for a less hackish approach as I am new to
either Ruby and Puppet.


Regards




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

Just having come across another list subscriber''s posting here
where (roughly) the posibility of package inclusion at partial
exclusion was asked
gave me the idea that maybe adapted usage of the "ensure =>
present"
vs. "ensure => absent" attributes
could serve as some sort of workaround.
So, would it work to define some kind of dummy package resources that
represent the deliberately not to be installed RPMs
and supply them with an "ensure => absent" attribute but
nevertheless
rig up some pseudo dependencies
by usage of the "require" or "before" attributes with the
respective
package referrals?



On May 19, 2:23 pm, DWIM <ralph.gro...@itdz-berlin.de>
wrote:
> Hi,
>
> I am new to Puppet.
>
> After having read quite a bit through the online puppet docs, as well
> as wiki posts and James'' "Pulling Strings with Puppet" I
installed a
> puppet master on an RHEL 5 box and one puppetd on an HP-UX box (which
> was a bit of a challenge owe to the notorious Ruby agnosticism of that
> platform) and one on another RHEL 5 box.
> I verified that the basic functionality was given, after signing of
> the nodes'' SSL certificates,  through a few tests with most
trivial,
> e.g. file resource, definitions in the master''s site.pp.
>
> Then I wanted to create something more useful and tinkered up a first
> class definition to aid me in deploying nagios/nrpe clients on the
> Redhattish (i.e. RPM based) nodes.
>
> Here I stumbled over a few issues of which one is,
>
> if there exists a posibility to pass (additional) options to the rpm
> command on the affected puppet nodes
> which I guess will be executed (by some system call or forked pipe?)
> on behalf of puppet''s RPM provider for redhattish systems?
> In the resources'' online doc for "package" however, I
couldn''t find
> any attribute that sounded fitting for this purpose.
> In particular, I want to pass a "--nodeps" option to the rpm
command
> because the prebuilt rpm binaries that I intend to have installed
> through Puppet exhibit partly pretty odd dependencies.
>
> E.g.
>
> # rpm -qR nagios-plugins-nrpe|grep nagios
> nagios
> nagios-plugins
>
> or
>
> # rpm -qR nagios-plugins|grep -i snmp
> perl(Net::SNMP)
>
> As for the first, I do not wish to have the Nagios server (which is
> packaged in "nagios") installed on every nrpe node,
> and for the Nagios Plug-ins, nor do I want to have the perl-Net-SNMP
> rpm installed
> (which itself most likely will depend on a net-snmp rpm) on every nrpe
> node either
> because I do not employ any SNMP-based Nagios plug-ins.
>
> Since Puppet is open source of course there will be some way, at a
> pinch presumably by overriding the rpm provider.
> But for now I am looking for a less hackish approach as I am new to
> either Ruby and Puppet.
>
> Regards
>
> --
> 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
athttp://groups.google.com/group/puppet-users?hl=en.
-- 
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.

> As for the first, I do not wish to have the Nagios server (which is
> packaged in "nagios") installed on every nrpe node,
As a complete diversion from your issue - I ended up moving away from
NRPE in the end and used distributed nagios servers on each box. This
was purely for scaling reasons due to NRPE tests holding up resources
on the server. Also - using nagios on each box means you can use the
Puppet naginator plugins (instead of having to manage your own
nrpe.cfg file) - combined with exported resources you can configure
server and client as well etc. etc. The benefits are many - but it
does take a bit to get your head around the setup.

BTW - Why do you care if you are installing extra packages? Are you
space constrained?

ken.

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

Hi Ken

On May 19, 6:23 pm, Ken <k...@bob.sh> wrote:
>
> As a complete diversion from your issue - I ended up moving away from
> NRPE in the end and used distributed nagios servers on each box.
> This was purely for scaling reasons due to NRPE tests holding up resources
> on the server.
A Nagios server on each monitored host?
And this should scale better than NRPE?

I really cannot believe that this is the "intended" usage.
This kind of seems to reverse the usual Nagios monitoring from a
mainly polling to an entirely pushing scheme.
I so far only monitor abt. 400 hosts from my Nagios server,
and for a while had a very modest delegation to merely two other
distributed Nagios servers (mainly owe to firewall impedances)
for less than 50 hosts.
But even in such a trivial setting I found that the nsca server on my
central Nagios server was almost overburdened
by the load of incoming passive check results (or rather the xinetd,
which admittedly probably wasn''t the best choice).
Added to this came the configuration overhead, but ok, I understand
you are letting Puppet handle this.
As a complete Puppet novice I think for now this would be beyond my
capabilities anyway.
> Also - using nagios on each box means you can use the
> Puppet naginator plugins (instead of having to manage your own
> nrpe.cfg file) - combined with exported resources you can configure
> server and client as well etc. etc. The benefits are many - but it
> does take a bit to get your head around the setup.
I should totally subscribe to that.
> BTW - Why do you care if you are installing extra packages? Are you
> space constrained?
Nay, disk space isn''t that expensive these days anymore.
But I''m a supporter of the old virtue that what isn''t required
on a
host
shouldn''t be installed on it.


Regards
Ralph

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

> A Nagios server on each monitored host?
> And this should scale better than NRPE?
>
> I really cannot believe that this is the "intended" usage.
> This kind of seems to reverse the usual Nagios monitoring from a
> mainly polling to an entirely pushing scheme.
> I so far only monitor abt. 400 hosts from my Nagios server,
> and for a while had a very modest delegation to merely two other
> distributed Nagios servers (mainly owe to firewall impedances)
> for less than 50 hosts.
> But even in such a trivial setting I found that the nsca server on my
> central Nagios server was almost overburdened
> by the load of incoming passive check results (or rather the xinetd,
> which admittedly probably wasn''t the best choice).
> Added to this came the configuration overhead, but ok, I understand
> you are letting Puppet handle this.
> As a complete Puppet novice I think for now this would be beyond my
> capabilities anyway.
The nsca solution can be problematic - we wrote our own receiver/
sender and shipped stuff via snmp instead. I seem to remember a skew
issue - where all nsca updates from all servers where sent on the
minute (ie. zero seconds past the minute) - can''t recall how this was
solved exactly though.

With nrpe, we had processes blocking and the queue wasn''t being
processed quickly enough on the main nagios host. The scheduler within
nagios can be complex when mixing active/passive services - so we
moved active checks away onto other servers and let the main server
only do passive.
> Nay, disk space isn''t that expensive these days anymore.
> But I''m a supporter of the old virtue that what isn''t
required on a
> host
> shouldn''t be installed on it.
Well - I guess it was a loaded question. My point was its kind of
going against the grain. Not that I don''t think you have a point - RPM
kind of lacks the ability to handle optionals as far as I can see - so
dependencies are mandatory. *shrug*.

If you really do want to do this, I have in the past written my own
wrappers around package to extend functionality of the core one. This
example worked around added a ''disableexcludes'' parameter for
when you
want to install packages but don''t want ''yum upgrade''
picking them up
during upgrades - things like tomcat and kernel may fall into this
category.

define my_package(
        $ensure,
        $disableexcludes = false) {

        # Normal package type cannot handle disableexcludes - so this
is a convenient
        # wrapper around exec that tries to pretend its a package :-)
        if $disableexcludes == true {
                $cmd = "yum --disableexcludes=all -y install $name ;
rpm -q $name"
                package {
                        $name:
                                noop => true,
                                ensure => $ensure,
                                require => Exec[$cmd];
                }
                exec {
                        $cmd:
                                command => $cmd,
                                timeout => 1800,
                                unless => "rpm -q $name";
                }
        } else {
                package {
                        $name:
                                ensure => $ensure;
                }
        }
}

You could very easily adapt this to add a ''nodeps'' option for
yourself
- so when it is set dropping to using the yum command in an exec as I
have shown. This will avoid having to modify the core ruby code. I did
a bit of wrapping like this at my last job - for example I had my own
''foo_mount'' resource which also turned on nagios monitoring
implicitly.

ken.

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

Many thanks for your kind help.
> The nsca solution can be problematic - we wrote our own receiver/
> sender and shipped stuff via snmp instead. I seem to remember a skew
> issue - where all nsca updates from all servers where sent on the
> minute (ie. zero seconds past the minute) - can''t recall how this
was
> solved exactly though.
This sounds like some big monitoring installation to me
where you certainly have other capacities (viz. like for developing
your own transports of check results).
Unfortunately, we haven''t apart from intermediate Perl and passing C
experience in my case.
> Well - I guess it was a loaded question. My point was its kind of
> going against the grain. Not that I don''t think you have a point -
RPM
> kind of lacks the ability to handle optionals as far as I can see - so
> dependencies are mandatory. *shrug*.
Yes, you''re probably right that in general I shouldn''t break
the
conventions of the packagers.
> If you really do want to do this, I have in the past written my own
> wrappers around package to extend functionality of the core one. This
> example worked around added a ''disableexcludes'' parameter
for when you
> want to install packages but don''t want ''yum
upgrade'' picking them up
> during upgrades - things like tomcat and kernel may fall into this
> category.
>
> define my_package(
>         $ensure,
>         $disableexcludes = false) {
>
>         # Normal package type cannot handle disableexcludes - so this
> is a convenient
>         # wrapper around exec that tries to pretend its a package :-)
>         if $disableexcludes == true {
>                 $cmd = "yum --disableexcludes=all -y install $name ;
> rpm -q $name"
>                 package {
>                         $name:
>                                 noop => true,
>                                 ensure => $ensure,
>                                 require => Exec[$cmd];
>                 }
>                 exec {
>                         $cmd:
>                                 command => $cmd,
>                                 timeout => 1800,
>                                 unless => "rpm -q $name";
>                 }
>         } else {
>                 package {
>                         $name:
>                                 ensure => $ensure;
>                 }
>         }
>
> }
>
Thank you for reminding me that I could well define my own custom
package resource and implement in it through exec
whatever was needed to ensure it gets installed.
Because I''m so new to Puppet I haven''t had this on m radar.

I guess the noop parameter in your code snippet is required to avoid
that the target platform''s package provider is invoked
and instead the exec resource can take over?
I haven''t found the noop parameter in the resource reference''s
package
section.
So is it one of the metaparameters that can be applied to (almost) any
resource (context permitting)?

Where best should I put my custom package resource?
Should it go in the main scope or better within my class''es scope?

Before I read your reply I came up with something more trivial in my
class definition
that most likely won''t work:


    Package { provider => rpm, ensure => installed }

    package { "fping":
        source      => "puppet://puppet/nagios/${source_subdir}/$
{fping_rpm}",
    }
    package { "nagios-plugins":
        source      => "puppet://puppet/nagios/${source_subdir}/$
{nagios_plugins_rpm}",
        require     => Package["fping", "perl-Net-SNMP"],
    }
    package { "nagios-nrpe":
        source      => "puppet://puppet/nagios/${source_subdir}/$
{nagios_nrpe_rpm}",
        require     => Package["nagios-plugins"],
    }
    package { "nagios-plugins-nrpe":
        source      => "puppet://puppet/nagios/${source_subdir}/$
{nagios_nrpe_plugin_rpm}",
        require     => Package["nagios-nrpe", "nagios"],
    }
    package { "perl-Net-SNMP":
        ensure      => absent,
    }
    package { "nagios":
        ensure      => absent,
    }

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

> This sounds like some big monitoring installation to me
> where you certainly have other capacities (viz. like for developing
> your own transports of check results).
> Unfortunately, we haven''t apart from intermediate Perl and passing
C
> experience in my case.
We wrote it all in Perl :-).
> I guess the noop parameter in your code snippet is required to avoid
> that the target platform''s package provider is invoked
> and instead the exec resource can take over?
> I haven''t found the noop parameter in the resource
reference''s package
> section.
> So is it one of the metaparameters that can be applied to (almost) any
> resource (context permitting)?
Yep: http://docs.reductivelabs.com/references/stable/metaparameter.html
> Where best should I put my custom package resource?
> Should it go in the main scope or better within my class''es scope?
Something like:

(where module_path is usually /etc/puppet/modules)

Create a file: $module_path/my/manifests/package.pp

With the contents:

define my::package (...args...) {
  ... do stuff here ...
}

Will enable you to call it from anywhere:

my::package{"foo": ensure => installed }

And keep things in a neat name space for you.
> Before I read your reply I came up with something more trivial in my
> class definition
> that most likely won''t work:
The rpm provider still won''t pass --nodeps I think :-).

ken.

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

> We wrote it all in Perl :-).
Ah, did you use any CPAN modules, or did you wrote all from scratch?
Just out of curiosity.

> Yep:http://docs.reductivelabs.com/references/stable/metaparameter.html
Yes, I remember to have consulted this reference already a couple of
times.
> Something like:
>
> (where module_path is usually /etc/puppet/modules)
>
Oh, I started populating /etc/puppet/manifests/classes
So is it better to organize stuff in modules right away?
> Create a file: $module_path/my/manifests/package.pp
>
> With the contents:
>
> define my::package (...args...) {
>   ... do stuff here ...
>
> }
Ok, the qualified naming scheme of the packages seems to reflect the
dir structure then (similar to Perl modules/namespaces).
>
> Will enable you to call it from anywhere:
>
> my::package{"foo": ensure => installed }
as expected.

> The rpm provider still won''t pass --nodeps I think :-).
>
Yes, it won''t.
But thanks to your definition sample I now know how to tackle this.

Btw, I forgot that I also need to import the GPG key from the packager
before having the RPMs installed
(unless I intersperse some --nodigest or --nosignature in the command
of the exec block of my custom package definition, I  suppose)

So I also included this kind of definition in my class (hope that will
work).
Of course I now know that I should rather factor that out into a
separate name space.

    define keypackage($ensure=installed) {
        $cmd = "rpm --import ${name}"
        package { $name:
            noop    => true,
            ensure  => $ensure,
            source  => "puppet://puppet/nagios/${name}",
            require => Exec["rpmkey-import"],
        }
        exec { "rpmkey-import":
            path    => "/bin:/usr/bin",
            command => $cmd,
            unless  => ''rpm -qa gpg-pubkey|xargs rpm -q --qf "%
{summary}\n"|grep -qi wieers'',
        }
    }


Btw. the $name variable I gather refers to "varname" or title that I
assign keypackage on its "instantiation",
like so?

keypackage { "RPM-GPG-KEY.dag.txt":
}

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

> Ah, did you use any CPAN modules, or did you wrote all from scratch?
> Just out of curiosity.
For the purpose of sending we just used plain old Net::SNMP:

http://search.cpan.org/~dtown/Net-SNMP-v6.0.0/lib/Net/SNMP.pm

We obviously had our own MIB, and added a section to handle traps for
this purpose. The trap object contained items like:

* service name
* severity
* description
* ... etc ...

Same sort of stuff that nsca sends.

The sender was pretty straight forward - as sending a trap is not
rocket science.

For the collector we wrote our own listener. But I think a better way
to do it today would be to use this guy:

http://search.cpan.org/~hardaker/NetSNMP-TrapReceiver-5.0301/TrapReceiver.pm

Which hooks into snmptrapd - and treats your code like a callback.
Then its just as simple as stuffing it into the unix socket using the
format Nagios expects.

An alternative could be to roll our own NSCA receiver:

http://search.cpan.org/~bingos/POE-Component-Server-NSCA-0.08/lib/POE/Component/Server/NSCA.pm

That may be better to tune then the normal NSCA. I seem to recall the
main problems with NSCA was around how many concurrent connections it
could receive at one time. Switching to UDP or at least using a
receiver that is more concurrent can improve things. I could be wrong
- sorry - my memory of the issues are a bit vague :-).

ken.

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