[Nagiosplug-help] Running local checks on windows systems?

[Dan Stromberg]

To enable external programs for NRPE use via NSClient++, you uncomment
CheckExternalScripts.dll, and put your scripts in the preexisting
[External Scripts] stanza.

On Fri, Jan 8, 2010 at 11:06 AM, Dan Stromberg
<dstromberglists at gmail.com> wrote:
> I don't supposed you took notes and/or saved references when you did it?
>
> Thanks for the reply.
>
> On Fri, Jan 8, 2010 at 11:00 AM, gmartin <gmartin at gmartin.org> wrote:
>>
>> \\Greg
>>
>>
>>
>> On Fri, Jan 8, 2010 at 1:10 PM, Dan Stromberg <dstromberglists at gmail.com>
>> wrote:
>>>
>>> There appears to be multiple ways of doing the local checks on Windows
>>> systems, and while there is commentary on the strengths and weaknesses
>>> of them in google, I've found the contrasts somewhat vague.
>>>
>>> So please allow me to describe my understanding of the strengths and
>>> weaknesses here, and hopefully People In the Know(tm) will jump in and
>>> correct me where I'm off.
>>>
>>> Here goes:
>>>
>>>
>>> nsclient:
>>> * Both a windows service and a protocol,
>>> * I've not looked at this one that much, as it appears to be superseded
>>> by nsclient++.
>>> * Connected to using Nagios plugin check_nt.
>>>
>>>
>>> nsclient++
>>> * A windows service that can serve up either or both of the nsclient and
>>> NRPE protocols.
>>> * Has an assortment of DLL's implementing the various checks, whether
>>> you connect using the nsclient protocol (check_nt) or the NRPE protocol
>>> (check_nrpe).
>>> * Allows you to continue using check_nt, which is nice if you already
>>> have some nagios checks based on that.
>>> * Allows you to start using check_nrpe for some things, but those things
>>> appear to require a dll?  As such, it seems to paint you into a corner;
>>> if you get a bunch of NRPE checks going based on nsclient++, it appears
>>> that a future move to NRPE_NT is made more complicated.
>>> * Granted, you could probably write a dll that just accepts arguments
>>> and treats them as a bash/powershell command.  Or is there something
>>> that already does this in nsclient++?
>>>
>> I'm running batch-file based checks using nsclient++ & check_nrpe witout
>> using a dll.  nsclient++ does this just fine.  The config take a little
>> investigation, but once you understand it, its easy.
>>
>>>
>>> nrpe_nt
>>> * A windows service that serves up the NRPE protocol, just like on *ix.
>>> * Allows you to use the same sort of plugin architecture for local
>>> checks that is used on *ix - enabling one to use the many plugins for
>>> Windows at
>>>
>>> http://exchange.nagios.org/directory/Plugins/Uncategorized/Operating-Systems/Windows-NRPE
>>> * Is this the reason why people are saying that NRPE is the way forward,
>>> not NSClient?
>>>
>>>
>>> sshd
>>> * Available as a cygwin sshd or via freesshd.  Speaks the ssh protocol(s)
>>> * Allows you to use the same sort of plugin architecture for local
>>> checks that is used on *ix - again enabling one to use the many plugins
>>> for Windows at
>>>
>>> http://exchange.nagios.org/directory/Plugins/Uncategorized/Operating-Systems/Windows-NRPE
>>> * Perhaps a little slower than NRPE, especially if you use NRPE without
>>> SSL
>>> * Much better authenticated than NRPE_NT, because NRPE_NT just uses
>>> IP-based authentication, while ssh is RSA public key with mutual auth
>>> * Probably harder to lock down to a list of specific commands than NRPE_NT
>>>
>>>
>>> SNMP
>>> * Another possibility I've not looked into much, at least not in a
>>> Nagios context.
>>> * Decent authentication in version 3, not so good in versions 1 and 2c.
>>> * Allows access to a LOT of stuff
>>>
>>
>> We use SNMP for hardware monitoring of WIndows servers in addition to
>> nsclient++
>>
>>>
>>> I'll add that one could probably run nsclient++ with the nsclient
>>> protocol enabled and nsclient++'s NRPE protocol support disabled, and
>>> also run NRPE_NT - on the same machine.  It seems like this would allow
>>> compatibility with existing check definitions, and give a nicer path
>>> forward - because where new plugins are needed, they could just be
>>> scripts in your favorite scripting language; they wouldn't need to be
>>> dll's in Windows-specific C or something.
>>>
>>>
>>> OK folks - where am I off?  Please tear it to shreds.
>>>
>>> Thanks!
>>>
>> \\Greg
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Nagiosplug-help mailing list
>> Nagiosplug-help at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nagiosplug-help
>> ::: Please include plugins version (-v) and OS when reporting any issue.
>> ::: Messages without supporting info will risk being sent to /dev/null
>>
>>
>