<div>Thanks Ton, </div> <div>for the detailed information, </div> <div> </div> <div>I have been swamped this week, but I will be reviewing this again when I get a chance,</div> <div> </div> <div>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. </div> <div> </div> <div>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. </div> <div> </div> <div>There are a few upgrades that I really want added into the check_nt.c core. (I have them in check_nc_net) </div> <div>1) better Help system - naturally with the common availible commands. </div> <div>2) a flag to overcome the buffer limits, and outputs to consol (STDOUT) great for enumeration and other potential usages of nc_net.</div> <div>3) A Stub command that would be able to send input string directly to the Windows Client then just output the result. </div> <div>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. </div> <div> </div> <div>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. </div> <div> </div> <div>I hope to hear from OpServices and any other parties that want to be involved in this soon,</div> <div> </div> <div>Tony (Author of NC_NEt) </div> <div> </div> <div> </div> <div><span class="gmail_quote">On 9/29/07, <b class="gmail_sendername">Ton Voon</b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:ton.voon@altinity.com" target="_blank">ton.voon@altinity.com</a> > wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Alessandro,<br><br>On 29 Sep 2007, at 17:13, Alessandro Ren wrote:<br><br>> As of the last version of nsclient, it had a check_nt_new that was <br>> sent with the package and it never made into the official check_nt.<br>> Now that's my question, can a add new features to the check_nt code<br>> and submit it to you or should we make a new check_nt? <br>> We would very much like to be on the official nagios plugins<br>> package<br>> and to contribute these new features to the community.<br><br>A similar request was made by Anthony Montibello back in March: <br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://thread.gmane.org/gmane.network.nagios.plugins.devel/4742/" target="_blank">http://thread.gmane.org/gmane.network.nagios.plugins.devel/4742/</a><br> focus=4739<br><br>And my guess is that your check_nt_new is not compatible with <br>Anthony's check_nc_net.<br><br>check_nt's protocol has become a defacto standard because it is<br>distributed with Nagios Plugins (both your server software support <br>it) and I don't want to fragment it further without a clear direction. <br><br>If we accepted both your plugins in the core code, the ground is set<br>for anyone else's special implementation of a windows agent to be <br>included, and I don't particularly want this.<br><br>So I propose this: you and Anthony (and anyone else interested) get <br>together and agree on a communication protocol that both your server<br>software will accept. You publish the protocol on some website <br>somewhere and agree to maintain that document. You may want to raise<br>a ticket with <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.iana.org/" target="_blank">http://www.iana.org/</a> to get an official port number <br>assigned to your protocol (I managed to get one for a planned piece<br>of software for Altinity called Opsview Envoy - this will be used <br>internally, so we haven't published a protocol for it. You can see it<br> at <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.iana.org/assignments/port-numbers" target="_blank">http://www.iana.org/assignments/port-numbers</a>).<br><br>You can then both implement server software that takes requests from <br>clients that conform to this protocol. I believe Anthony's is written<br>in .NET and I guess yours is in C, but that will not matter to the<br>client.<br><br>Then, I would be more than happy to accept a plugin into the core <br>distribution that conforms to the protocol. I would even say that we<br>can continue the maintenance of the plugin (as long as you don't<br>abuse the protocol by making continual changes). For instance, if you<br> both agree to support encryption later, or another authentication<br>method, I can see that we would help with updating the plugin. After<br>all, we maintain the check_http plugin even though we have no control<br>over the HTTP protocol. <br><br>Is this fair?<br><br>Ton<br><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.altinity.com/" target="_blank">http://www.altinity.com</a><br>T: +44 (0)870 787 9243<br>F: +44 (0)845 280 1725 <br>Skype: tonvoon<br><br><br><br>------------------------------------------------------------------------- <br>This SF.net email is sponsored by: Microsoft<br>Defy all challenges. Microsoft(R) Visual Studio 2005.<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/" target="_blank"> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ </a><br>_______________________________________________________<br>Nagios Plugin Development Mailing List <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Nagiosplug-devel@lists.sourceforge.net" target="_blank"> Nagiosplug-devel@lists.sourceforge.net</a><br>Unsubscribe at <a onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel </a><br>::: Please include plugins version (-v) and OS when reporting any issue.<br>::: Messages without supporting info will risk being sent to /dev/null <br></blockquote></div><br>