[Nagiosplug-devel] Further development of nsclient.

[Anthony Montibello]

Thanks Ton,
for the detailed information,

I have been swamped this week, but I will be reviewing this again when I get
a chance,

As for the Check_nt/ Check_nc_net  I want to get my contributions merged
into the Nagios plugins, and I would be willing to do what I can to help
with this endevor.  Naturally I agree with oyu, in the fact that no one
wants to see a plugin updated frequenly,  my goal is for check_nt to be
stable and versitile.

Naturally the check_nc_net client is in C.( NC _Net is Dot Net C#.
Opservices should be in visual pascal/Delphi if it is from the original
nsclient. otherwise it really could not claim any more authentisity than
NC_Net or NSCLient++; but really the languages do not matter as you pointed
out already.

There are a few upgrades that I really want added into the check_nt.c core.
(I have them in check_nc_net)
1) better Help system  - naturally with the common availible commands.
2) a flag to overcome the buffer limits, and outputs to consol (STDOUT)
great for enumeration and other potential usages of nc_net.
3) A Stub command that would be able to send input string directly to the
Windows Client then just output the result.
this command would basically bypass the pre and post processing that
check_nt does, but it would allow for expansion of check_nt for other (yet
to be created projects)  where check_nt could just be put into a wrapper
sctipt to run new commands.

These three upgrades together I hope would eliminate the neccessity for many
third party apps to frequently request upgrades to check_nt.   the 2 biggest
Limitations I saw wirth the original check_nt were the Hardcoded commands
offerered no expantion, and small buffer prevents usage of enumeration
commands.

I hope to hear from OpServices and any other parties that want to be
involved in this soon,

Tony (Author of NC_NEt)


On 9/29/07, Ton Voon <ton.voon at altinity.com> wrote:
>
> Hi Alessandro,
>
> On 29 Sep 2007, at 17:13, Alessandro Ren wrote:
>
> >    As of the last version of nsclient, it had a check_nt_new that was
> > sent with the package and it never made into the official check_nt.
> >    Now that's my question, can a add new features to the check_nt code
> > and submit it  to you or should we make a new check_nt?
> >    We would very much like to be on the official nagios plugins
> > package
> > and to contribute these new features to the community.
>
> A similar request was made by Anthony Montibello back in March:
> http://thread.gmane.org/gmane.network.nagios.plugins.devel/4742/
> focus=4739
>
> And my guess is that your check_nt_new is not compatible with
> Anthony's check_nc_net.
>
> check_nt's protocol has become a defacto standard because it is
> distributed with Nagios Plugins (both your server software support
> it) and I don't want to fragment it further without a clear direction.
>
> If we accepted both your plugins in the core code, the ground is set
> for anyone else's special implementation of a windows agent to be
> included, and I don't particularly want this.
>
> So I propose this: you and Anthony (and anyone else interested) get
> together and agree on a communication protocol that both your server
> software will accept. You publish the protocol on some website
> somewhere and agree to maintain that document. You may want to raise
> a ticket with http://www.iana.org/ to get an official port number
> assigned to your protocol (I managed to get one for a planned piece
> of software for Altinity called Opsview Envoy - this will be used
> internally, so we haven't published a protocol for it. You can see it
> at http://www.iana.org/assignments/port-numbers).
>
> You can then both implement server software that takes requests from
> clients that conform to this protocol. I believe Anthony's is written
> in .NET and I guess yours is in C, but that will not matter to the
> client.
>
> Then, I would be more than happy to accept a plugin into the core
> distribution that conforms to the protocol. I would even say that we
> can continue the maintenance of the plugin (as long as you don't
> abuse the protocol by making continual changes). For instance, if you
> both agree to support encryption later, or another authentication
> method, I can see that we would help with updating the plugin. After
> all, we maintain the check_http plugin even though we have no control
> over the HTTP protocol.
>
> Is this fair?
>
> Ton
>
> http://www.altinity.com
> T: +44 (0)870 787 9243
> F: +44 (0)845 280 1725
> Skype: tonvoon
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________________
> Nagios Plugin Development Mailing List
> Nagiosplug-devel at lists.sourceforge.net
> Unsubscribe at
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20071001/c79c041c/attachment.html>