check time syncronization

[mark.potter at academy.com]

Hari Sekhon <hpsekhon at googlemail.com> wrote on 02/21/2008 01:52:15 PM:

> mark.potter at academy.com wrote:
> > Another option would to be used check_by_ssh. I am, of course, 
> > assuming they are allowed to use ssh but a machine with no remote 
> > connectivity is a problem to begin with. check_by_ssh isn't quite as 
> > nice as nrpe but it would accomplish the checks in question. One could 

> > also write a pretty simple wrapper to check the time on both servers, 
> > compare it, and account for the lag between the checks. It wouldn't be 

> > pretty but it would work for the most part.
>
> check_by_ssh? I'd avoid that at any cost, ssh is too powerful, it's the 
> equivalent of nrpe with the "don't blame me flag if you get hacked". If 
> you can't use nrpe, then you certainly can't give out ssh access.

This is patently untrue. NRPE opens a new port and introduces new 
processes to an environment. This has to be vetted through all security 
testing and that can take months at some companies only to have it fail 
because they do not understand it. If they are admining Linux boxes 
already I am betting they have ssh running in the environment and properly 
locked down at many levels. SSH may be more powerful than NRPE as far as 
what could happen but it is also running in a lot more places. It is an 
alternative if you can't get NRPE approved. The final statement is false 
as well. "If you can't use nrpe, then you certainly can't give out ssh 
access". I can assure you that there are many environments where the 
security admins are more concerned about introducing new processes that 
use open ports than they are about giving out ssh access when properly 
locked down. It is really very simple to allow ssh access by IP and chroot 
the nagios user making ssh no more of a risk than nrpe and not introducing 
a new "threat" into the farm. The security admins are likely wrong but 
they are also the ones calling the shots in many cases.

> 
> Also, I'm not sure it's worth writing any wrapper, since any which way 
> you'd still need a remote execution mechanism. By the time you have any 
> remote execution mechanism, then surely you should use the standard 
> check_ntp plugin...

You don't need a remote execute mechanism:
HOST-RESOURCES-MIB::hrSystemDate.0
That will pull the system date via snmp without a remote execute 
mechanism. Meaning you could, in theory, pull the date off of two systems 
with one being the ntp server, write some logic in for the lag between the 
two checks, and compare the time without any remote execute mechanism 
whatsoever. It would not be as reliable as anything using a remote execute 
method because the lag between the two checks will vary but it could be 
used as a basic check without too much trouble.

> 
> I think that SNMP, NSCA would be your best bets, but if you can't have 
> anything, there is also one more remote possibility. Timestamping 
> through ICMP. Long shot but it can be done, you'd probably need to write 

> a custom plugin though and if it's a tight environment then likely this 
> would be blocked.

I was referring to writing a wrapped for snmp checks. Amazing that you 
suggest using snmp. I highly doubt nsca can be used if nrpe cannot. SNMP 
or SSH are likely the only options for the scenario as presented. Also I 
don't know if you noticed the OP's email address but I am betting he deals 
with a lot more red tape than most us in getting anything changed, 
installed, and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20080221/5bffedc4/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
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/
-------------- next part --------------
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null