The to-do items are listed in no particular order.
-
Let the server support command authorization based on host and service groups. This requires the server to actually parse the submitted commands, as oppposed to simply matching them against the user-supplied regular expressions.
-
Let the server support a
clients
orsources
directive that allows the user to specify one or more subnets (globally and/or per-client). Connections from source addresses outside these subnets should be rejected. -
Let the server support proxying of (selected or all) data (with
forward
blocks in the configuration, for example). -
Support requests for status and configuration data in order to provide a full-blown remote API.
-
Let the client execute standard Nagios plugins directly (as an alternative to using a script such as
contrib/invoke_check
), and maybe provide a daemon mode with poor man's check scheduling (i.e., addcheck_interval
andretry_interval
directives to the client configuration). -
If the server is not available, let the client queue commands and results using local storage and submit them as soon as the server comes up again.
-
Let the client talk to multiple servers.
-
Port the client to Microsoft Windows.
-
Create a client library with Perl (and maybe Python) bindings.
-
Add IPv6 support to OpenSSL's
BIO_s_connect(3)
API, so that the client can use IPv6. (The server supports IPv6 already.) There's a ticket with a patch in OpenSSL's tracker, and a related discussion on the OpenSSL development mailing list. -
Support NULL encryption TLS-PSK cipher suites as defined in RFC 4785. This should make it easier to use tools such as
tcpdump(8)
for debugging NSCA-ng sessions. There's an older and a newer patch in OpenSSL's tracker. -
Support SHA-256/384 (and GCM) TLS-PSK cipher suites as per RFC 5487. Someone played around with this already.