Re: [Nagios-devel] Distributing plugins
Posted: Wed Aug 29, 2007 4:55 am
This is a cryptographically signed message in MIME format.
--------------ms090205020301090208030800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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
--------------ms090205020301090208030800
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFuDCC
AtgwggJBoAMCAQICCQCm2uXMgNJKLDANBgkqhkiG9w0BAQUFADBPMQswCQYDVQQGEwJERTEM
MAoGA1UECBMDTlJXMRwwGgYDVQQKExNCYWVja2VyIElUIFNlcnZpY2VzMRQwEgYDVQQDEwtp
bnRlcm5hbCBDQTAeFw0wNzA4MDgxMzExMThaFw0wODA4MDcxMzExMThaMHsxCzAJBgNVBAYT
AkRFMQwwCgYDVQQIEwNOUlcxHDAaBgNVBAoTE0JhZWNrZXIgSVQgU2VydmljZXMxGDAWBgNV
BAMTD0hlbmRyaWsgQmFlY2tlcjEmMCQGCSqGSIb3DQEJARYXYW5kdXJpbkBwcm9jZXNzLXpl
cm8uZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJ9MdGOUbOUVjqr6sVAmSmwM4pl4
RCpOhRkLcZsxqS01xSdtsk60O9zKTNIM23A05WTECJwQL9jtdf2yjEpRrdBlwXGnU+muYZX7
L64RrdjqCRRdNqUlaM1YBRFTGKLSEjBfiF3B5SI6U19Gs4JdVH/Tnq9F/VmL7wPTBPT6HQfH
AgMBAAGjgY8wgYwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwLAYJYIZIAYb4QgEN
BB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBQeM6m5375Z0mi+
4fR2vjs/33lYVzAfBgNVHSMEGDAWgBS3rNDUwCv
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
--------------ms090205020301090208030800
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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
--------------ms090205020301090208030800
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFuDCC
AtgwggJBoAMCAQICCQCm2uXMgNJKLDANBgkqhkiG9w0BAQUFADBPMQswCQYDVQQGEwJERTEM
MAoGA1UECBMDTlJXMRwwGgYDVQQKExNCYWVja2VyIElUIFNlcnZpY2VzMRQwEgYDVQQDEwtp
bnRlcm5hbCBDQTAeFw0wNzA4MDgxMzExMThaFw0wODA4MDcxMzExMThaMHsxCzAJBgNVBAYT
AkRFMQwwCgYDVQQIEwNOUlcxHDAaBgNVBAoTE0JhZWNrZXIgSVQgU2VydmljZXMxGDAWBgNV
BAMTD0hlbmRyaWsgQmFlY2tlcjEmMCQGCSqGSIb3DQEJARYXYW5kdXJpbkBwcm9jZXNzLXpl
cm8uZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJ9MdGOUbOUVjqr6sVAmSmwM4pl4
RCpOhRkLcZsxqS01xSdtsk60O9zKTNIM23A05WTECJwQL9jtdf2yjEpRrdBlwXGnU+muYZX7
L64RrdjqCRRdNqUlaM1YBRFTGKLSEjBfiF3B5SI6U19Gs4JdVH/Tnq9F/VmL7wPTBPT6HQfH
AgMBAAGjgY8wgYwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwLAYJYIZIAYb4QgEN
BB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQWBBQeM6m5375Z0mi+
4fR2vjs/33lYVzAfBgNVHSMEGDAWgBS3rNDUwCv
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]