[Nagios-devel] NRPE 3.0? (protocol enhancements)
Posted: Thu Mar 20, 2008 3:15 am
Hello,
I know this is the wrong list but I am not subscribed to plug-devel and
figured this could work as well, if not let me know and I shall move
this to that list instead
Since I had gotten some requests for NSClient++ to allow "longer
payloads" (I added this but it requires a recompile of check_nrpe with
#define MAX_PACKETBUFFER_LENGTH ) I was a bit curious
about any ideas for a "new" version of NRPE with amongst other things
variable length payload?
Things I can imagine are;
* variable length payload (ie. negotiations of length)
* authentication (both simple password and certificates/keys)
* multiple queries/multiple results (I know Nagios wont support this out
of the box but a proxy agent could repackage and upload via NSCA or some
such, also other monitoring solutions does support and use this)
* TLS support (if nothing else just to make it simpler to negotiate
encryption/non-encryption)
* encoding/Unicode support (either a tag specifying the incoming
encoding and(or?) UTF8 support)
* support for the |-char (as of now this is "used and cant be escaped")
* support for "proper" performance data (ie. a separate "channel" for it)
... probably a few other things I cant recall now...
Just a bit curious if there is any interest, I myself am not really much
of a Unix developer (okey, I admit it, I hate emacs, and doing "longer
things" in vi is damn tedious) so not that interested to do the "Unix
client/server" but I would gladly add such support on "my end" (ie.
windows side).
Anyways, just throwing this out to see if there is any takers...
BTW, there is also a "bug" in the NRPE client/server it "only" reads
whats in the buffer and never waits for "more data" not much of a
problem since 1024 chars usually fit inside the buffer, but
theoretically if there is a hell of a lot of lag it might not, but more
importantly if you set MAX_PACKETBUFFER_LENGTH to more then around 16k
you get incomplete payloads.
// Michael Medin
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
I know this is the wrong list but I am not subscribed to plug-devel and
figured this could work as well, if not let me know and I shall move
this to that list instead
Since I had gotten some requests for NSClient++ to allow "longer
payloads" (I added this but it requires a recompile of check_nrpe with
#define MAX_PACKETBUFFER_LENGTH ) I was a bit curious
about any ideas for a "new" version of NRPE with amongst other things
variable length payload?
Things I can imagine are;
* variable length payload (ie. negotiations of length)
* authentication (both simple password and certificates/keys)
* multiple queries/multiple results (I know Nagios wont support this out
of the box but a proxy agent could repackage and upload via NSCA or some
such, also other monitoring solutions does support and use this)
* TLS support (if nothing else just to make it simpler to negotiate
encryption/non-encryption)
* encoding/Unicode support (either a tag specifying the incoming
encoding and(or?) UTF8 support)
* support for the |-char (as of now this is "used and cant be escaped")
* support for "proper" performance data (ie. a separate "channel" for it)
... probably a few other things I cant recall now...
Just a bit curious if there is any interest, I myself am not really much
of a Unix developer (okey, I admit it, I hate emacs, and doing "longer
things" in vi is damn tedious) so not that interested to do the "Unix
client/server" but I would gladly add such support on "my end" (ie.
windows side).
Anyways, just throwing this out to see if there is any takers...
BTW, there is also a "bug" in the NRPE client/server it "only" reads
whats in the buffer and never waits for "more data" not much of a
problem since 1024 chars usually fit inside the buffer, but
theoretically if there is a hell of a lot of lag it might not, but more
importantly if you set MAX_PACKETBUFFER_LENGTH to more then around 16k
you get incomplete payloads.
// Michael Medin
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]