revathi ganesh | 1 Dec 01:33 2011
Picon

Hey there How are you!!

Hola
I wanted to prove I could amount to something there is nothing else like this out here this was more than effective just imagine what it could do for you
http://bluecat.x.fc2.com/profile/92MartinJames/
ttyl.

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
Boonie | 1 Dec 18:22 2011
Picon

centos 6 instruction

Hi,

Can anyone point me to a step by step instruction on how to install
smokeping on centos 6?

I tried and got stuck while it is a rather simple thing to do on
Ubuntu. But I have a centos 6 VPS on which I'd like to have it run.

Thanks,

Dave

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

mgd | 1 Dec 20:37 2011

inconsistencies in smokeping_config documentation ***Targets*** section

At the beginning of the ***Targets***, just after the statement  
beginning with "The following variables can be set in this section:",  
the "alerts" are described as:

A comma separated list of alerts to check for this target. The alerts  
have to be setup in the Alerts section. Alerts are inherited by child  
nodes. Use an empty alerts definition to remove inherited alerts from  
the current target and its children.

Then in the Level 1 section that follows a few sentences later, it is  
written for alerts that:

     Comma separated list of alert names

     This variable inherits its value from the parent section if  
nothing is specified here.

So, the first statement says that "use an empty alert definition to  
remove inherited alerts from the current target and its children".  
Then in the section for configured targets it says: "This variable  
inherits its value from the parent section if nothing is specified  
here". These two statements clash, only one can be true. So, what is  
the true statement?

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

Gregory Sloop | 1 Dec 21:39 2011
Picon

Re: inconsistencies in smokeping_config documentation ***Targets*** section

See comments following...

mic> At the beginning of the ***Targets***, just after the statement
mic> beginning with "The following variables can be set in this section:",
mic> the "alerts" are described as:

mic> A comma separated list of alerts to check for this target. The alerts
mic> have to be setup in the Alerts section. Alerts are inherited by child
mic> nodes. Use an empty alerts definition to remove inherited alerts from
mic> the current target and its children.

mic> Then in the Level 1 section that follows a few sentences later, it is
mic> written for alerts that:

mic>      Comma separated list of alert names

mic>      This variable inherits its value from the parent section if  
mic> nothing is specified here.

mic> So, the first statement says that "use an empty alert definition to  
mic> remove inherited alerts from the current target and its children".  
mic> Then in the section for configured targets it says: "This variable  
mic> inherits its value from the parent section if nothing is specified  
mic> here". These two statements clash, only one can be true. So, what is  
mic> the true statement?

[Provided I understand your question...]
I think what it's saying is:

If you leave a child section without any *explicitly* defined alerts, it
will get the alerts from its parent.

If you want to cancel/remove an alert for a child section, then define an
"empty" alert with the same name in the child and you don't get that
alert from the parent. If there are other alerts, you'll get those.

[And I'm pretty sure it works that way. I don't have any currently
configured child sections using this, but did one a while back and it
functioned as specified here - at least IIRC it did. I was using
2.4.something - but I haven't heard of any different behavior in
2.6.x]

-Greg

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

mgd | 2 Dec 00:29 2011

Re: inconsistencies in smokeping_config documentation ***Targets*** section

Thank you, Greg

Yes, I ended up defining all my parent alerts in one line in the Targets file:

alerts =  
bigloss,someloss,startloss,rttdetect,anydelay,rttdetectbccable,rttdetectcube

Then, for each target, I defined alerts uniquely, such as:

++ SquarePE
menu = SquarePE
title = SquarePE
host = 1.2.3.4
alerts = bigloss

++ CubeCE
menu = CubeCE
title = CubeCE
host = 4.3.2.1
alerts = rttdetectcube

But, as you suggest, I could also have created a dummy or do nothing  
alert and assigned that to Targets for which I do not need email alerts.

Quoting Gregory Sloop <gregs <at> sloop.net>:

> See comments following...
>
> mic> At the beginning of the ***Targets***, just after the statement
> mic> beginning with "The following variables can be set in this section:",
> mic> the "alerts" are described as:
>
> mic> A comma separated list of alerts to check for this target. The alerts
> mic> have to be setup in the Alerts section. Alerts are inherited by child
> mic> nodes. Use an empty alerts definition to remove inherited alerts from
> mic> the current target and its children.
>
> mic> Then in the Level 1 section that follows a few sentences later, it is
> mic> written for alerts that:
>
> mic>      Comma separated list of alert names
>
> mic>      This variable inherits its value from the parent section if
> mic> nothing is specified here.
>
> mic> So, the first statement says that "use an empty alert definition to
> mic> remove inherited alerts from the current target and its children".
> mic> Then in the section for configured targets it says: "This variable
> mic> inherits its value from the parent section if nothing is specified
> mic> here". These two statements clash, only one can be true. So, what is
> mic> the true statement?
>
> [Provided I understand your question...]
> I think what it's saying is:
>
> If you leave a child section without any *explicitly* defined alerts, it
> will get the alerts from its parent.
>
> If you want to cancel/remove an alert for a child section, then define an
> "empty" alert with the same name in the child and you don't get that
> alert from the parent. If there are other alerts, you'll get those.
>
> [And I'm pretty sure it works that way. I don't have any currently
> configured child sections using this, but did one a while back and it
> functioned as specified here - at least IIRC it did. I was using
> 2.4.something - but I haven't heard of any different behavior in
> 2.6.x]
>
> -Greg
>
> _______________________________________________
> smokeping-users mailing list
> smokeping-users <at> lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
>

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

Tobias Oetiker | 2 Dec 07:07 2011
Picon

Re: inconsistencies in smokeping_config documentation ***Targets*** section

> Quoting Gregory Sloop <gregs <at> sloop.net>:
>
> > See comments following...
> >
> > mic> At the beginning of the ***Targets***, just after the statement
> > mic> beginning with "The following variables can be set in this section:",
> > mic> the "alerts" are described as:
> >
> > mic> A comma separated list of alerts to check for this target. The alerts
> > mic> have to be setup in the Alerts section. Alerts are inherited by child
> > mic> nodes. Use an empty alerts definition to remove inherited alerts from
> > mic> the current target and its children.
> >
> > mic> Then in the Level 1 section that follows a few sentences later, it is
> > mic> written for alerts that:
> >
> > mic>      Comma separated list of alert names
> >
> > mic>      This variable inherits its value from the parent section if
> > mic> nothing is specified here.
> >
> > mic> So, the first statement says that "use an empty alert definition to
> > mic> remove inherited alerts from the current target and its children".
> > mic> Then in the section for configured targets it says: "This variable
> > mic> inherits its value from the parent section if nothing is specified
> > mic> here". These two statements clash, only one can be true. So, what is
> > mic> the true statement?
> >
> > [Provided I understand your question...]
> > I think what it's saying is:
> >
> > If you leave a child section without any *explicitly* defined alerts, it
> > will get the alerts from its parent.
> >
> > If you want to cancel/remove an alert for a child section, then define an
> > "empty" alert with the same name in the child and you don't get that
> > alert from the parent. If there are other alerts, you'll get those.
> >
> > [And I'm pretty sure it works that way. I don't have any currently
> > configured child sections using this, but did one a while back and it
> > functioned as specified here - at least IIRC it did. I was using
> > 2.4.something - but I haven't heard of any different behavior in
> > 2.6.x]
> >
Yesterday mgd <at> interbaun.com wrote:

> Thank you, Greg
>
> Yes, I ended up defining all my parent alerts in one line in the Targets file:
>
> [...]

Now that you understood. Do you want to suggest changes to
Smokeping.pm (the documentation is in there ... just search for the
strings ... ).

cheers
tobi

--

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi <at> oetiker.ch ++41 62 775 9902 / sb: -9900

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

Gregory Sloop | 2 Dec 18:27 2011
Picon

Broken graphs


Ok, here's what I've got:

Ubuntu 10.4 LTS

My targets are all setup, and "smokeping --debug" shows everything is running fine.
My RRD's are getting created and populated.
www-data has read access to the RRD's.
www-data has write access to "imgcache = /var/cache/smokeping/images"

I get the base page, but if I go into any of the graph pages, I get
"broken" graphs.

I don't get any errors though.

If I were betting I'd guess it's probably a permissions issue, but I
can't see what.

Any ideas? I'm stumped.

-Greg
--

-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
503.251.0452 x82 Voice | 503.251.0452 Fax
www.sloop.net
mailto:gregs <at> sloop.net

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

Gregory Sloop | 2 Dec 18:30 2011
Picon

Re: Broken graphs

I probably should have said this, I assumed it was obvious...but this
is a new setup.

-Greg

GS> Ok, here's what I've got:

GS> Ubuntu 10.4 LTS

GS> My targets are all setup, and "smokeping --debug" shows everything is running fine.
GS> My RRD's are getting created and populated.
GS> www-data has read access to the RRD's.
GS> www-data has write access to "imgcache = /var/cache/smokeping/images"

GS> I get the base page, but if I go into any of the graph pages, I get
GS> "broken" graphs.

GS> I don't get any errors though.

GS> If I were betting I'd guess it's probably a permissions issue, but I
GS> can't see what.

GS> Any ideas? I'm stumped.

GS> -Greg

--

-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs <at> sloop.net
http://www.sloop.net
---

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

Boonie | 2 Dec 20:50 2011
Picon

Re: Broken graphs

Did you put dots in the name of the items or menus? I did that a few days 
ago and that had the same result.

Regards,

Dave

----- Original Message ----- 
From: "Gregory Sloop" <gregs <at> sloop.net>
To: "Greg Sloop" <gregs <at> sloop.net>
Cc: <smokeping-users <at> lists.oetiker.ch>
Sent: Friday, December 02, 2011 6:30 PM
Subject: Re: [smokeping-users] Broken graphs

>I probably should have said this, I assumed it was obvious...but this
> is a new setup.
>
> -Greg
>
> GS> Ok, here's what I've got:
>
> GS> Ubuntu 10.4 LTS
>
> GS> My targets are all setup, and "smokeping --debug" shows everything is 
> running fine.
> GS> My RRD's are getting created and populated.
> GS> www-data has read access to the RRD's.
> GS> www-data has write access to "imgcache = /var/cache/smokeping/images"
>
> GS> I get the base page, but if I go into any of the graph pages, I get
> GS> "broken" graphs.
>
> GS> I don't get any errors though.
>
> GS> If I were betting I'd guess it's probably a permissions issue, but I
> GS> can't see what.
>
> GS> Any ideas? I'm stumped.
>
> GS> -Greg
>
> -- 
> Gregory Sloop, Principal: Sloop Network & Computer Consulting
> Voice: 503.251.0452 x82
> EMail: gregs <at> sloop.net
> http://www.sloop.net
> ---
>
> _______________________________________________
> smokeping-users mailing list
> smokeping-users <at> lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
> 

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

Chris Wilson | 2 Dec 21:38 2011

Updated tcpping probe and script

Dear Richard, Tobi and smokeping users,

I tried to use the tcpping probe but it didn't work for me (centos 5). It seems 
that the tcptraceroute output format has changed or there is a problem with the 
script's ability to parse options. It also doesn't report tcptraceroute errors 
properly or have much in the way of debugging support. And it required 
smokeping to be run as root.

I think I have fixed these issues, and posted updated versions here:

https://github.com/aptivate/network-scripts/blob/master/TCPPing.pm
https://github.com/aptivate/network-scripts/blob/master/tcpping

I hope that you will consider these for inclusion in your projects. Richard, 
are you still maintaining tcpping? If not, is it worth merging this 
functionality into the TCPPing module?

Cheers, Chris.
--

-- 
Aptivate | http://www.aptivate.org | Phone: +44 1223 760887
The Humanitarian Centre, Fenner's, Gresham Road, Cambridge CB1 2ES

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

_______________________________________________
smokeping-users mailing list
smokeping-users <at> lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users


Gmane