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