<tt>Hari Sekhon <hpsekhon@googlemail.com> wrote on 02/21/2008 01:52:15 PM: > mark.potter@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.</tt> <tt>> > 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.</tt> <tt>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.</tt> <tt> > > 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...</tt> <tt>You don't need a remote execute mechanism:</tt> <tt>HOST-RESOURCES-MIB::hrSystemDate.0</tt> <tt>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.</tt> <tt> > > 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. </tt> <tt>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. </tt>