Distributing plugins

[Hendrik Bäcker]

Bonjour Francois,

you are not alone with this.

I've spent a view thought on this to.

For distribution I made a privat company RPM paket for the nagios
plugins and nrpe.
Within the plugin rpm there a several own little dirty plugins...

I think this is similar to your description.

My idea was to define one nrpe command like

[check_for_update]

to let the client (formerly the remote server) start a local
script/program to fetch a new rpm (might be some kind of other internal
repository), doing some other update routines and restart the nrped.

In theory this should not be so much trouble except if all your internal
servers have a way to connect to your central repository server
(thinking about firewalls, access-lists, and so on....).

Comments on your ideas please see inline.

francois basquin schrieb:

> - using automatic copies from a repository to the clients (rsync or 
> equivalent)
> Pros: simple. Cons: implies an extra protocol, which may not be desirable
> 
Thinking about push or poll technology? Nagios is sending update to your
remote systems or just nagios sent a command to let the clients get
their updates?
Protocols should not be a huge problem if you're thinking about the
security.

> - using NFS: clients mount the plugins directory from the repository
> Pros: simpler. Cons: implies NFS, which may not be desirable
> 
Bad idea. You are very dependent on a remote NFS... what if this one
fails? All of your other remote server will ran into panic like problems.

> Going further, nrpe could also maintain the nrpe.cfg file. Why keeping the 
> "command[..]" statements locally? They could be sent via nrpe itself.
> 
In theory you are able to work with a singe nrpe command definition if
you are working with argument passing.

But be aware, you should take care that no one is able to submit a
command like this:

check_nrpe -H IP_OF_HOST -c all_cmd -a "rm -rf /"

Might get you into trouble ;)

> And a couple of beers ahead, the repository might even be a database.
> 
Even a single point of failure if the db connection is broken.

> I know this changes the philosophy behind nrpe quite a bit, but it may worth 
> to think about.

In my mind your ideas are valid.

In bigger installations you are running into those problems. "How can I
distribute the function as easy as I can?"

I think you can hit the biggest amount of server with a centralized
repository (rsync, http, ftp) and with an update command in your nrpe
config.
You have to think well about the local update scripts, what if an error
occurs?
Is the repo accessible?
Has the NRPE Daemon the rights to compile and install s.th. on the
remote system?
And so on.

But if you made it and it runs fine you are able to send out a
check_nrpe to all your remote systems and they will update themselfs.
Sounds very nice to me.

Regards
Hendrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2185 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20070829/b59c2ec2/attachment.bin>
-------------- next part --------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel