I know that this is the Nagios Support Forum but I was wondering if this is also the place to talk about customizing NRPE and how the configuration data in the NRPE.cfg file on the monitored system could be improved.
Basically I want know if anyone has worked on putting the client config piece of NRPE on a DB somewhere. I am using Mongo but the DB type is irrelevant.
I also might be asking the question wrong. Basically I want all the data for Nagios and Nagios alerts that are client specific to be in a DB that can be used rather than needing to touch files on the local system.
Thanks for patience and if this the wrong forum let me know who I might talk to.
Respectfully
Moonrox
NRPE extensions
Re: NRPE extensions
Well, I think if you changed NRPE to be what you're asking for, it wouldn't be NRPE anymore. But I get what you're saying. Personally, I would just write a plugin of my own that did what I wanted it to do like what you're talking about.
Maybe something wrapped in a check_by_ssh wrapper that triggered execution on the remote server, that server's script would then look in your database for a queue specific to its machine name that lists commands it's supposed to execute, and then return the result back (though the database) so the SSH tunnel can exit and the calling script get the result out of the database.
Sounds good to me. As long as you can live with a service check dependent upon not only the thing you're checking, but a database being up, the local and remote server being able to read/write to that database, the security and management that goes along with that, being able to connect via SSH (and that security management), and doing all of this within the service check timeout limit of Nagios, then you're all set.
I don't mean that facetiously or sarcastically; I actually think my idea is a pretty good starting point. It's just that it adds what I consider extra complexity to solve a problem that I'm not sure really exists. You can distribute (or pull) the NRPE config file(s) in whatever way makes sense to you, including pulling their configuration from a database (maybe storing XML?) and creating a dynamic NRPE config file every hour or whatever, but the actual NRPE check is dependent only upon being able to connect to the remote server, get past xinetd, and execute the check. So maybe my idea of a database driving SSH connection socket tool thingy isn't so great after all.
Maybe something wrapped in a check_by_ssh wrapper that triggered execution on the remote server, that server's script would then look in your database for a queue specific to its machine name that lists commands it's supposed to execute, and then return the result back (though the database) so the SSH tunnel can exit and the calling script get the result out of the database.
Sounds good to me. As long as you can live with a service check dependent upon not only the thing you're checking, but a database being up, the local and remote server being able to read/write to that database, the security and management that goes along with that, being able to connect via SSH (and that security management), and doing all of this within the service check timeout limit of Nagios, then you're all set.
I don't mean that facetiously or sarcastically; I actually think my idea is a pretty good starting point. It's just that it adds what I consider extra complexity to solve a problem that I'm not sure really exists. You can distribute (or pull) the NRPE config file(s) in whatever way makes sense to you, including pulling their configuration from a database (maybe storing XML?) and creating a dynamic NRPE config file every hour or whatever, but the actual NRPE check is dependent only upon being able to connect to the remote server, get past xinetd, and execute the check. So maybe my idea of a database driving SSH connection socket tool thingy isn't so great after all.