NRPE 3.0? (protocol enhancements)
Michael Medin
michael at medin.name
Thu Mar 20 12:15:18 CET 2008
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 <bigger value>) 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 SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
More information about the Developers
mailing list