Hey all, I'm trying to get depends working, but it's not working the way I expect it to.
<bb-hosts snippet> 10.18.16.172 standby # conn testip depends=(conn:eto/conn) 10.18.16.174 eto # conn ssh snmp testip
eto is currently red, but standby, which is down as well, is also red.
anything specific wrong with my depends statement? Any reason why conn wouldn't be able to depend on something else?
Thanks! --Patrick
Looks right to me, maybe domain related (FQDN)?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Hey all, I'm trying to get depends working, but it's not working the way I expect it to.
<bb-hosts snippet> 10.18.16.172 standby # conn testip depends=(conn:eto/conn) 10.18.16.174 eto # conn ssh snmp testip
eto is currently red, but standby, which is down as well, is also red.
anything specific wrong with my depends statement? Any reason why conn wouldn't be able to depend on something else?
Thanks! --Patrick
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
Looks right to me, maybe domain related (FQDN)?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Hey all, I'm trying to get depends working, but it's not working the way I expect it to.
<bb-hosts snippet> 10.18.16.172 standby # conn testip depends=(conn:eto/conn) 10.18.16.174 eto # conn ssh snmp testip
eto is currently red, but standby, which is down as well, is also red.
anything specific wrong with my depends statement? Any reason why conn wouldn't be able to depend on something else?
Thanks! --Patrick
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon <pnixon at gmail.com> wrote:
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
Looks right to me, maybe domain related (FQDN)?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Hey all, I'm trying to get depends working, but it's not working the way I expect it to.
<bb-hosts snippet> 10.18.16.172 standby # conn testip depends=(conn:eto/conn) 10.18.16.174 eto # conn ssh snmp testip
eto is currently red, but standby, which is down as well, is also red.
anything specific wrong with my depends statement? Any reason why conn wouldn't be able to depend on something else?
Thanks! --Patrick
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon <pnixon at gmail.com> wrote:
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
Looks right to me, maybe domain related (FQDN)?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Hey all, I'm trying to get depends working, but it's not working the way I expect it to.
<bb-hosts snippet> 10.18.16.172 standby # conn testip depends=(conn:eto/conn) 10.18.16.174 eto # conn ssh snmp testip
eto is currently red, but standby, which is down as well, is also red.
anything specific wrong with my depends statement? Any reason why conn wouldn't be able to depend on something else?
Thanks! --Patrick
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com # testip route:customer.cablemodem.com
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon <pnixon at gmail.com> wrote:
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
Looks right to me, maybe domain related (FQDN)?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Hey all, I'm trying to get depends working, but it's not working the way I expect it to.
<bb-hosts snippet> 10.18.16.172 standby # conn testip depends=(conn:eto/conn) 10.18.16.174 eto # conn ssh snmp testip
eto is currently red, but standby, which is down as well, is also red.
anything specific wrong with my depends statement? Any reason why conn wouldn't be able to depend on something else?
Thanks! --Patrick
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I read somewhere that if you use route, it does something weird with the pings so they go through that host or something?
Let me test it and see how it behaves
--patrick
On Tue, Jul 6, 2010 at 1:46 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com # testip route:customer.cablemodem.com
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon <pnixon at gmail.com> wrote:
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
Looks right to me, maybe domain related (FQDN)?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Hey all, I'm trying to get depends working, but it's not working the way I expect it to.
<bb-hosts snippet> 10.18.16.172 standby # conn testip depends=(conn:eto/conn) 10.18.16.174 eto # conn ssh snmp testip
eto is currently red, but standby, which is down as well, is also red.
anything specific wrong with my depends statement? Any reason why conn wouldn't be able to depend on something else?
Thanks! --Patrick
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I've not experienced that behavior. Use this for dsl/cable modems and our routers for 3+ years.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:54 PM, Patrick Nixon <pnixon at gmail.com> wrote:
I read somewhere that if you use route, it does something weird with the pings so they go through that host or something?
Let me test it and see how it behaves
--patrick
On Tue, Jul 6, 2010 at 1:46 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com # testip route:customer.cablemodem.com
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon <pnixon at gmail.com> wrote:
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon <pnixon at gmail.com> wrote:
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman <josh at imaginenetworksllc.com> wrote:
Looks right to me, maybe domain related (FQDN)?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon <pnixon at gmail.com> wrote: > Hey all, > I'm trying to get depends working, but it's not working the way I expect it to. > > <bb-hosts snippet> > 10.18.16.172 standby # conn testip > depends=(conn:eto/conn) > 10.18.16.174 eto # conn ssh snmp testip > > eto is currently red, but standby, which is down as well, is also red. > > > anything specific wrong with my depends statement? Any reason why > conn wouldn't be able to depend on something else? > > Thanks! > --Patrick > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I have nothing to add to this thread, but it looks like "depends" might be helpful for a problem I am currently having with a pair of servers, whereby one at a time will show a process as running, the other not. So as long as one of these machines is running this app, the color should stay green.
.vp
I've not experienced that behavior. Use this for dsl/cable modems and our routers for 3+ years.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:54 PM, Patrick Nixon wrote:
I read somewhere that if you use route, it does something weird with the pings so they go through that host or something?
Let me test it and see how it behaves
--patrick
On Tue, Jul 6, 2010 at 1:46 PM, Josh Luthman wrote:
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com # testip route:customer.cablemodem.com
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon wrote:
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon wrote:
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman wrote: > Looks right to me, maybe domain related (FQDN)? > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > “Success is not final, failure is not fatal: it is the courage to > continue that counts.” > --- Winston Churchill > > > > On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon wrote: >> Hey all, >> I'm trying to get depends working, but it's not working the way I expect it to. >> >> >> 10.18.16.172 standby # conn testip >> depends=(conn:eto/conn) >> 10.18.16.174 eto # conn ssh snmp testip >> >> eto is currently red, but standby, which is down as well, is also red. >> >> >> anything specific wrong with my depends statement? Any reason why >> conn wouldn't be able to depend on something else? >> >> Thanks! >> --Patrick >> >> To unsubscribe from the hobbit list, send an e-mail to >> hobbit-unsubscribe at hswn.dk >> >> >> > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
I have always used "route" and it works perfectly if conn is all you care about. I have never actually gotten "depends" to work. It doesn't make the ping go through any host you put in route and it also chains properly to make it easier. Example:
10.10.10.10 server1 # conn route:network1 20.20.20.20 network1 # conn route:network2 30.30.30.30 network2 # conn
If the route to server1 is: hobbit -> network2 -> network1 -> server1
The above statement works, that if network2 is down ... network1 and server1 go blank :)
On Tue, Jul 6, 2010 at 2:35 PM, <wiskbroom at hotmail.com> wrote:
I have nothing to add to this thread, but it looks like "depends" might be helpful for a problem I am currently having with a pair of servers, whereby one at a time will show a process as running, the other not. So as long as one of these machines is running this app, the color should stay green.
.vp
I've not experienced that behavior. Use this for dsl/cable modems and our routers for 3+ years.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:54 PM, Patrick Nixon wrote:
I read somewhere that if you use route, it does something weird with the pings so they go through that host or something?
Let me test it and see how it behaves
--patrick
On Tue, Jul 6, 2010 at 1:46 PM, Josh Luthman wrote:
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com # testip route:customer.cablemodem.com
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon wrote:
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon wrote: > They're both testip > > On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman > wrote: >> Looks right to me, maybe domain related (FQDN)? >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> “Success is not final, failure is not fatal: it is the courage to >> continue that counts.” >> --- Winston Churchill >> >> >> >> On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon wrote: >>> Hey all, >>> I'm trying to get depends working, but it's not working the way I expect it to. >>> >>> >>> 10.18.16.172 standby # conn testip >>> depends=(conn:eto/conn) >>> 10.18.16.174 eto # conn ssh snmp testip >>> >>> eto is currently red, but standby, which is down as well, is also red. >>> >>> >>> anything specific wrong with my depends statement? Any reason why >>> conn wouldn't be able to depend on something else? >>> >>> Thanks! >>> --Patrick >>> >>> To unsubscribe from the hobbit list, send an e-mail to >>> hobbit-unsubscribe at hswn.dk >>> >>> >>> >> >> To unsubscribe from the hobbit list, send an e-mail to >> hobbit-unsubscribe at hswn.dk >> >> >> > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Yes, route works fine. We always use it when monitoring stuff over VPN, to avoid getting 50 e-mails if the VPN goes down.
But my experience is that conn for the "routed" hosts go yellow, not clear, if the "router" doesn't respond to ping. Could be worth considering if you have alerts configured for yellow.
/Johan
From: Geoff Hallford [mailto:geoff.hallford at gmail.com] Sent: den 6 juli 2010 21:57 To: hobbit at hswn.dk Subject: Re: [hobbit] Depends Question
I have always used "route" and it works perfectly if conn is all you care about. I have never actually gotten "depends" to work. It doesn't make the ping go through any host you put in route and it also chains properly to make it easier. Example:
10.10.10.10 server1 # conn route:network1 20.20.20.20 network1 # conn route:network2 30.30.30.30 network2 # conn
If the route to server1 is: hobbit -> network2 -> network1 -> server1
The above statement works, that if network2 is down ... network1 and server1 go blank :)
On Tue, Jul 6, 2010 at 2:35 PM, <wiskbroom at hotmail.com<mailto:wiskbroom at hotmail.com>> wrote:
I have nothing to add to this thread, but it looks like "depends" might be helpful for a problem I am currently having with a pair of servers, whereby one at a time will show a process as running, the other not. So as long as one of these machines is running this app, the color should stay green.
.vp
I've not experienced that behavior. Use this for dsl/cable modems and our routers for 3+ years.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
"Success is not final, failure is not fatal: it is the courage to continue that counts." --- Winston Churchill
On Tue, Jul 6, 2010 at 1:54 PM, Patrick Nixon wrote:
I read somewhere that if you use route, it does something weird with the pings so they go through that host or something?
Let me test it and see how it behaves
--patrick
On Tue, Jul 6, 2010 at 1:46 PM, Josh Luthman wrote:
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com<http://customer.router.com> # testip route:customer.cablemodem.com<http://customer.cablemodem.com>
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
"Success is not final, failure is not fatal: it is the courage to continue that counts." --- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon wrote:
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
"Success is not final, failure is not fatal: it is the courage to continue that counts." --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon wrote:
They're both testip
On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman wrote: > Looks right to me, maybe domain related (FQDN)? > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > "Success is not final, failure is not fatal: it is the courage to > continue that counts." > --- Winston Churchill > > > > On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon wrote: >> Hey all, >> I'm trying to get depends working, but it's not working the way I expect it to. >> >> >> 10.18.16.172 standby # conn testip >> depends=(conn:eto/conn) >> 10.18.16.174 eto # conn ssh snmp testip >> >> eto is currently red, but standby, which is down as well, is also red. >> >> >> anything specific wrong with my depends statement? Any reason why >> conn wouldn't be able to depend on something else? >> >> Thanks! >> --Patrick >> >> To unsubscribe from the hobbit list, send an e-mail to >> hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk> >> >> >> > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk> > > >
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk<mailto:hobbit-unsubscribe at hswn.dk>
Thanks for all the insight into this.
route works as advertised
I wonder if anyone has actually gotten the depends tag working correctly.
On Tue, Jul 6, 2010 at 4:03 PM, Johan Sjöberg <johan.sjoberg at deltamanagement.se> wrote:
Yes, route works fine.
We always use it when monitoring stuff over VPN, to avoid getting 50 e-mails if the VPN goes down.
But my experience is that conn for the “routed” hosts go yellow, not clear, if the “router” doesn’t respond to ping. Could be worth considering if you have alerts configured for yellow.
/Johan
From: Geoff Hallford [mailto:geoff.hallford at gmail.com] Sent: den 6 juli 2010 21:57 To: hobbit at hswn.dk Subject: Re: [hobbit] Depends Question
I have always used "route" and it works perfectly if conn is all you care about. I have never actually gotten "depends" to work. It doesn't make the ping go through any host you put in route and it also chains properly to make it easier. Example:
10.10.10.10 server1 # conn route:network1 20.20.20.20 network1 # conn route:network2 30.30.30.30 network2 # conn
If the route to server1 is: hobbit -> network2 -> network1 -> server1
The above statement works, that if network2 is down ... network1 and server1 go blank :)
On Tue, Jul 6, 2010 at 2:35 PM, <wiskbroom at hotmail.com> wrote:
I have nothing to add to this thread, but it looks like "depends" might be helpful for a problem I am currently having with a pair of servers, whereby one at a time will show a process as running, the other not. So as long as one of these machines is running this app, the color should stay green.
.vp
I've not experienced that behavior. Use this for dsl/cable modems and our routers for 3+ years.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:54 PM, Patrick Nixon wrote:
I read somewhere that if you use route, it does something weird with the pings so they go through that host or something?
Let me test it and see how it behaves
--patrick
On Tue, Jul 6, 2010 at 1:46 PM, Josh Luthman
wrote:
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com # testip route:customer.cablemodem.com
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon wrote:
Josh, Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman
wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon wrote: > They're both testip > > On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman
> wrote: >> Looks right to me, maybe domain related (FQDN)? >> >> Josh Luthman >> Office: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> “Success is not final, failure is not fatal: it is the courage to >> continue that counts.” >> --- Winston Churchill >> >> >>
>> On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon wrote: >>> Hey all, >>> I'm trying to get depends working, but it's not working the way I >>> expect it to. >>> >>>
>>> 10.18.16.172 standby # conn testip >>> depends=(conn:eto/conn) >>> 10.18.16.174 eto # conn ssh snmp testip >>> >>> eto is currently red, but standby, which is down as well, is also >>> red. >>> >>> >>> anything specific wrong with my depends statement? Any reason why >>> conn wouldn't be able to depend on something else? >>> >>> Thanks! >>> --Patrick >>> >>> To unsubscribe from the hobbit list, send an e-mail to >>> hobbit-unsubscribe at hswn.dk >>> >>> >>> >> >> To unsubscribe from the hobbit list, send an e-mail to >> hobbit-unsubscribe at hswn.dk >> >> >> > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Tuesday, 6 July 2010 21:28:58 Patrick Nixon wrote:
Thanks for all the insight into this.
route works as advertised
I wonder if anyone has actually gotten the depends tag working correctly.
If there is no evidence that it is working correclty, please file a bug ...
Regards, Buchan
Does anyone have depends statements that for sure work?
On 7/6/10, Buchan Milne <bgmilne at staff.telkomsa.net> wrote:
On Tuesday, 6 July 2010 21:28:58 Patrick Nixon wrote:
Thanks for all the insight into this.
route works as advertised
I wonder if anyone has actually gotten the depends tag working correctly.
If there is no evidence that it is working correclty, please file a bug ...
Regards, Buchan
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
Thanks all;
In my situation, we have a pair of servers where one of the two must be running a process, that is what we monitor; the existence of the process running, not the availability of the host.
Any suggestions anyone?
Thank you,
.vp
I have always used "route" and it works perfectly if conn is all you care about. I have never actually gotten "depends" to work. It doesn't make the ping go through any host you put in route and it also chains properly to make it easier. Example:
10.10.10.10 server1 # conn route:network1 20.20.20.20 network1 # conn route:network2 30.30.30.30 network2 # conn
If the route to server1 is: hobbit -> network2 -> network1 -> server1
The above statement works, that if network2 is down ... network1 and server1 go blank :)
On Tue, Jul 6, 2010 at 2:35 PM,> wrote:
I have nothing to add to this thread, but it looks like "depends" might be helpful for a problem I am currently having with a pair of servers, whereby one at a time will show a process as running, the other not. So as long as one of these machines is running this app, the color should stay green.
.vp
I've not experienced that behavior. Use this for dsl/cable modems and
our routers for 3+ years.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to
continue that counts.”
--- Winston Churchill
On Tue, Jul 6, 2010 at 1:54 PM, Patrick Nixon wrote:
I read somewhere that if you use route, it does something weird with
the pings so they go through that host or something?
Let me test it and see how it behaves
--patrick
On Tue, Jul 6, 2010 at 1:46 PM, Josh Luthman
wrote:
I'm not certain of this because I've always used FQDN.
If you have FQDN=true and are not using them, maybe the DEPENDS tag
isn't finding eto correct?
In your case, as it is conn, you can use route
1.2.32.4 customer.router.com # testip route:customer.cablemodem.com
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to
continue that counts.”
--- Winston Churchill
On Tue, Jul 6, 2010 at 1:42 PM, Patrick Nixon wrote:
Josh,
Not sure what you were saying there?
My goal is that if eto's conn goes red, that standby's conn should go
clear if it also fails.
Does my depends statement not appear to work in that fashion?
--Patrick
On Tue, Jul 6, 2010 at 1:32 PM, Josh Luthman
wrote:
In stanby's DEPENDS statement referring to eto - not the testing of the host.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
“Success is not final, failure is not fatal: it is the courage to
continue that counts.”
--- Winston Churchill
On Tue, Jul 6, 2010 at 12:49 PM, Patrick Nixon wrote:
> They're both testip
>
> On Tue, Jul 6, 2010 at 12:41 PM, Josh Luthman
> wrote:
>> Looks right to me, maybe domain related (FQDN)?
>>
>> Josh Luthman
>> Office: 937-552-2340
>> Direct: 937-552-2343
>> 1100 Wayne St
>> Suite 1337
>> Troy, OH 45373
>>
>> “Success is not final, failure is not fatal: it is the courage to
>> continue that counts.”
>> --- Winston Churchill
>>
>>
>>
>> On Tue, Jul 6, 2010 at 12:34 PM, Patrick Nixon wrote:
>>> Hey all,
>>> I'm trying to get depends working, but it's not working the way I expect it to.
>>>
>>>
>>> 10.18.16.172 standby # conn testip
>>> depends=(conn:eto/conn)
>>> 10.18.16.174 eto # conn ssh snmp testip
>>>
>>> eto is currently red, but standby, which is down as well, is also red.
>>>
>>>
>>> anything specific wrong with my depends statement? Any reason why
>>> conn wouldn't be able to depend on something else?
>>>
>>> Thanks!
>>> --Patrick
>>>
>>> To unsubscribe from the hobbit list, send an e-mail to
>>> hobbit-unsubscribe at hswn.dk
>>>
>>>
>>>
>>
>> To unsubscribe from the hobbit list, send an e-mail to
>> hobbit-unsubscribe at hswn.dk
>>
>>
>>
>
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe at hswn.dk
>
>
>
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
On Wednesday, 7 July 2010 14:46:52 wiskbroom at hotmail.com wrote:
Thanks all;
In my situation, we have a pair of servers where one of the two must be running a process, that is what we monitor; the existence of the process running, not the availability of the host.
Any suggestions anyone?
Running under clustering software, or not?
(using depends on combotest or similar for this is not elegant, as there could be other process checks which you want to alarm on on both servers).
Regards, Buchan
participants (6)
-
bgmilne＠staff.telkomsa.net
-
geoff.hallford＠gmail.com
-
johan.sjoberg＠deltamanagement.se
-
josh＠imaginenetworksllc.com
-
pnixon＠gmail.com
-
wiskbroom＠hotmail.com