Hey all,
for my munin-module I would like to implement a automagic installation
an deinstallation of munin-plugins on nodes depending on the output of a
test
I have a define called remoteplugin, which copies a plugin from the
puppetmaster to the client.
I would like to add a parameter called ''presentif'' which
contains a test
(that should be executed on the client). The result of this test
determines whether the plugin should be installed or not.
Example: suppose I would like to install a raid plugin, which monitors
the status of a raid-array. So I would like to do:
remoteplugin{"raid": presentif => "/usr/bin/test -e
/proc/mdstat"}
in "define remoteplugin" I would have something like:
define remoteplugin(presentif=""){
[....]
if <execute $presentif code here> {
$ensure => "present"
}else {
$ensure => "absent"
}
case $ensure {
present: [...install plugin...]
absent: [...remove plugin...]
}
[....]
}
I took a look at the generate function which seemed to be the right
thing, but unfortunately this is run on the puppetmaster and not on the
client.
Does someone have an idea how I could achieve this?
Thank you all,
udo.
On Jan 30, 2008, at 9:13 PM, Udo Waechter wrote:> Hey all, > > for my munin-module I would like to implement a automagic installation > an deinstallation of munin-plugins on nodes depending on the output > of a > test > > I have a define called remoteplugin, which copies a plugin from the > puppetmaster to the client. > > I would like to add a parameter called ''presentif'' which contains a > test > (that should be executed on the client). The result of this test > determines whether the plugin should be installed or not.The only way to do this is to use a custom fact. -- You don''t learn anything the second time you''re kicked by a mule. -- Anonymous Texan --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Thanks Luke, unfortunately the fact approach is not general enough. I have now decided to write a script, which I then use on the munin- nodes to install and or deinstall plugins. It will receive as aruments the plugins name and a test. It executes the test and - depending on the tests result - either installs and or deinstalls the plugin. Have a nice evening, udo. On 30.01.2008, at 13:30, Luke Kanies wrote:> On Jan 30, 2008, at 9:13 PM, Udo Waechter wrote: > >> Hey all, >> >> for my munin-module I would like to implement a automagic >> installation >> an deinstallation of munin-plugins on nodes depending on the output >> of a >> test >> >> I have a define called remoteplugin, which copies a plugin from the >> puppetmaster to the client. >> >> I would like to add a parameter called ''presentif'' which contains a >> test >> (that should be executed on the client). The result of this test >> determines whether the plugin should be installed or not. > > > The only way to do this is to use a custom fact. > > -- > You don''t learn anything the second time you''re kicked by a mule. > -- Anonymous Texan > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- :: udo waechter - root@zoide.net :: N 52º16''30.5" E 8º3''10.1" :: genuine input for your ears: http://www.auriculabovinari.de :: your eyes: http://ezag.zoide.net :: your brain: http://www.zoide.net
udo waechter schrieb:> Thanks Luke, > unfortunately the fact approach is not general enough.There ain''t nothing more general than a custom fact. You could for example create a fact that lists all applicable plugins (like the output of munin-node-configure) and decide upon this on the server which plugins to deploy. Of course it''s debatable whether that approch is any "better" than jsut calling out to the shell. Regards, David
On 31.01.2008, at 13:08, David Schmitt wrote:> udo waechter schrieb: >> Thanks Luke, >> unfortunately the fact approach is not general enough. > > There ain''t nothing more general than a custom fact. > > You could for example create a fact that lists all applicable plugins > (like the output of munin-node-configure) and decide upon this on the > server which plugins to deploy. >Yes, this also came to my mind. Unfortunately munin-node-configure only works with plugins that are autoconfigurable. Those that are not, do not work with this scripts. for example, the raid-plugin does not work with node-configure. Thus being able to define a test condition ist the best approach for me. Bye, udo.> Of course it''s debatable whether that approch is any "better" than > jsut > calling out to the shell. > > > Regards, David > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- :: udo waechter - root@zoide.net :: N 52º16''30.5" E 8º3''10.1" :: genuine input for your ears: http://www.auriculabovinari.de :: your eyes: http://ezag.zoide.net :: your brain: http://www.zoide.net