xymon client bindaddress
list Frank Torontour
Hi,
Is there a way to have the xymon client bind to a specific IP or
interface?
I have more than one interface on a machine and I am getting ghost reports
because I setup xymon for eth0:0 instead of eth0.
--
sysadm cronomagic.com/gemstelecom.com
e-mail user-fbc5ef527f6f@xymon.invalid
POWERED BY LINUX
list Frank Torontour
Hi, I think I now have this under control. So you can ignore the previous email. No more ghosts!!
▸
Is there a way to have the xymon client bind to a specific IP or
interface?
I have more than one interface on a machine and I am getting ghost reports
because I setup xymon for eth0:0 instead of eth0.
--
sysadm cronomagic.com/gemstelecom.com
e-mail user-fbc5ef527f6f@xymon.invalid
POWERED BY LINUX
list Japheth Cleaver
▸
On 6/5/2017 9:15 AM, Frank wrote:
Hi, I think I now have this under control. So you can ignore the previous email. No more ghosts!! Is there a way to have the xymon client bind to a specific IP or interface? I have more than one interface on a machine and I am getting ghost reports because I setup xymon for eth0:0 instead of eth0.
Hi, It surprised me that this wasn't a configurable option. There's no way to currently (as opposed to binding on the listen interface), but looking at the code, I think this should be easily addable as a feature Regards, -jc
list Frank Torontour
Hi,
I am doing something that I don't think has been done with xymon before. We are running asterisk on a failover
heartbeat system. When the failover occurs heartbeat shuts down everything on the primary server and xymon
goes nuts. So I set up heartbeat to stop xymon when it shuts everything else down. Now when the "floating IP"
goes to the secondary server, the secondary starts up all the services and I set it up for xymon to start too. I was
thinking would be a great idea if I could bind xymon to the floating IP the same way I do it for the rest of the
services. So far during tests it seems to be working out ok without the binding, but may be necessary after all.
▸
On 6/7/17 5:24 PM, Japheth Cleaver wrote:On 6/5/2017 9:15 AM, Frank wrote:Hi, I think I now have this under control. So you can ignore the previous email. No more ghosts!! Is there a way to have the xymon client bind to a specific IP or interface? I have more than one interface on a machine and I am getting ghost reports because I setup xymon for eth0:0 instead of eth0.Hi, It surprised me that this wasn't a configurable option. There's no way to currently (as opposed to binding on the listen interface), but looking at the code, I think this should be easily addable as a feature Regards, -jc
--
sysadm cronomagic.com
e-mail user-fbc5ef527f6f@xymon.invalid
POWERED BY LINUX
list Adam Goryachev
▸
On 8/6/17 07:46, Frank wrote:
Hi,
I am doing something that I don't think has been done with xymon before. We are running asterisk on a failover
heartbeat system. When the failover occurs heartbeat shuts down everything on the primary server and xymon
goes nuts. So I set up heartbeat to stop xymon when it shuts everything else down. Now when the "floating IP"
goes to the secondary server, the secondary starts up all the services and I set it up for xymon to start too. I was
thinking would be a great idea if I could bind xymon to the floating IP the same way I do it for the rest of the
services. So far during tests it seems to be working out ok without the binding, but may be necessary after all.
When you say "xymon" do you mean xymon-client or are you running the xymon server components on this redundant system? It seems to me that running the monitoring system on the same system that you are monitoring is likely to lead to problems (ie, on total system failure you won't be told about it). I would suggest to run the monitoring on a 3rd server, which is stand-alone from this pair. Xymon doesn't care which IP address the client reports originate from, as long as the name is correct. However, I would advise to have both systems report status individually, with their own names, then you can see the status of each server in the pair. In order to alert and see the status of the services provided by the pair, then you can use combined status such as procs on serverA OR procs on serverB = procs green for Service and so on. Hope this helps... Regards, Adam --
list Jeremy Laidman
▸
On 6 June 2017 at 00:13, Frank <user-fbc5ef527f6f@xymon.invalid> wrote:
Hi, Is there a way to have the xymon client bind to a specific IP or interface? I have more than one interface on a machine and I am getting ghost reports because I setup xymon for eth0:0 instead of eth0.
Based on the eth0:0 interface name, I assume you're using Linux . Under
Linux you can use the routing table to nudge the kernel towards using a
particular IP address you specify, by using the "src" parameter when adding
a route. By default, the kernel chooses the source IP address based on a
route table lookup of the destination. So you could add a route to your
Xymon server that specifies the use of a specific src IP you want like so:
ip route add <xymsrv IP> dev eth0 src <eth0:0 IP>
As is normal for route lookups, the selection of the route with the "src"
specified, is determined by the destination IP address, regardless of the
process making the request or the protocol used. This means "ssh <xymon
IP>" or "wget <xymon IP>" would also have the eth0:0 IP as their source,
which may or may not be what you want.
Instead of using routing tricks, you could use iptables and can setup a
source NAT (SNAT) rule for the traffic you're interested in, to "NAT" to
the alternate IP address. For example, use a rule that only matches
TCP/1984, which would change the source IP as it egresses the server,
outbound on that port. Or, you could use the "owner" module to specify the
"xymon" user, so that only the Xymon client traffic uses the alternative IP
address. Or a combination of these.
Actually, it's slightly more complicated than that, because "SNAT" only
operates in the nat/POSTROUTING, and "owner" only operates in the
mangle/OUTPUT chain, you have to use "owner" to mark packets and then use
"SNAT" to modify packets that have been so marked. For example, the
following tags packets from processes run as the xymon user, but only when
the destination port is 1984, and then performs the SNAT on the matched
packets:
iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner xymon -m tcp
--dport 1984 -j MARK --set-mark 0xdeadbeef
iptables -t nat -A POSTROUTING -o eth0 -m mark --mark 0xdeadbeef -j SNAT
--to-source <eth0:0 IP>
However, it would be nicer if the Xymon client could be told to bind to a
particular IP address (or interface name).
J
list Frank Torontour
Hi,
Thank you for your input. It is good to know but I think it is a bit overkill. Right now the
system is working perfectly, and I just used the name associated with eth0:0. But it would
be nice if xymon was able to bind to the IP. Oh yes I am using linux.
▸
On 6/8/17 2:04 AM, Jeremy Laidman wrote:On 6 June 2017 at 00:13, Frank <user-fbc5ef527f6f@xymon.invalid <mailto:user-fbc5ef527f6f@xymon.invalid>> wrote:
Hi,
Is there a way to have the xymon client bind to a specific IP
or interface?
I have more than one interface on a machine and I am getting ghost
reports
because I setup xymon for eth0:0 instead of eth0.
Based on the eth0:0 interface name, I assume you're using Linux . Under Linux you can use the routing table to nudge the kernel towards using a particular IP address you specify, by using the "src" parameter when adding a route. By default, the kernel chooses the source IP address based on a route table lookup of the destination. So you could add a route to your Xymon server that specifies the use of a specific src IP you want like so:
ip route add <xymsrv IP> dev eth0 src <eth0:0 IP>
As is normal for route lookups, the selection of the route with the "src" specified, is determined by the destination IP address, regardless of the process making the request or the protocol used. This means "ssh <xymon IP>" or "wget <xymon IP>" would also have the eth0:0 IP as their source, which may or may not be what you want.
Instead of using routing tricks, you could use iptables and can setup a source NAT (SNAT) rule for the traffic you're interested in, to "NAT" to the alternate IP address. For example, use a rule that only matches TCP/1984, which would change the source IP as it egresses the server, outbound on that port. Or, you could use the "owner" module to specify the "xymon" user, so that only the Xymon client traffic uses the alternative IP address. Or a combination of these.
Actually, it's slightly more complicated than that, because "SNAT" only operates in the nat/POSTROUTING, and "owner" only operates in the mangle/OUTPUT chain, you have to use "owner" to mark packets and then use "SNAT" to modify packets that have been so marked. For example, the following tags packets from processes run as the xymon user, but only when the destination port is 1984, and then performs the SNAT on the matched packets:
iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner xymon -m tcp --dport 1984 -j MARK --set-mark 0xdeadbeef
iptables -t nat -A POSTROUTING -o eth0 -m mark --mark 0xdeadbeef -j SNAT --to-source <eth0:0 IP>
However, it would be nicer if the Xymon client could be told to bind to a particular IP address (or interface name).
J
-- sysadm cronomagic.com/gemstelecom.com e-mail user-fbc5ef527f6f@xymon.invalid POWERED BY LINUX
list Frank Torontour
Well it was working HI!! Here is an except from my hosts.cfg EXAMPLE: 192.168.55.55 eth0:0 192.168.2.56 voip1.example.com (eth0) but voip1 is actually mapped on the DNS to eth0:0 I have xymon-client starting up /home/xymon/runclient.sh --hostname=voip1.example.com Up till now everything runs ok. (I have not tried a failover, as I just wanted to get it to work). Probably report as a ghost when it fails over. When I add this, then I get ghost reports: Weird, xymon-server reports itself as one of the ghosts. 192.168.2.56 voip1-2.example.com (eth0 on primary) 192.168.2.57 voip1-3.example.com (eth0 on secondary) On 6/8/17 9:49 AM, Adam Goryachev wrote:
Just a nudge, consider what I said about monitoring both servers all the time. Otherwise, if one server dies, but xymon shows all green, you won't know there is a problem until the second server dies too. Regards, Adam On 8/6/17 23:10, Frank wrote:When I say xymon, I mean the xymon-client. The xymon-server is on a different machine.
▸
On 6/7/17 7:46 PM, Adam Goryachev wrote:On 8/6/17 07:46, Frank wrote:Hi, I am doing something that I don't think has been done with xymon before. We are running asterisk on a failover heartbeat system. When the failover occurs heartbeat shuts down everything on the primary server and xymon goes nuts. So I set up heartbeat to stop xymon when it shuts everything else down. Now when the "floating IP" goes to the secondary server, the secondary starts up all the services and I set it up for xymon to start too. I was thinking would be a great idea if I could bind xymon to the floating IP the same way I do it for the rest of the services. So far during tests it seems to be working out ok without the binding, but may be necessary after all.When you say "xymon" do you mean xymon-client or are you running the xymon server components on this redundant system? It seems to me that running the monitoring system on the same system that you are monitoring is likely to lead to problems (ie, on total system failure you won't be told about it). I would suggest to run the monitoring on a 3rd server, which is stand-alone from this pair. Xymon doesn't care which IP address the client reports originate from, as long as the name is correct. However, I would advise to have both systems report status individually, with their own names, then you can see the status of each server in the pair. In order to alert and see the status of the services provided by the pair, then you can use combined status such as procs on serverA OR procs on serverB = procs green for Service and so on. Hope this helps... Regards, Adam
-- sysadm cronomagic.com/gemstelecom.com e-mail user-fbc5ef527f6f@xymon.invalid POWERED BY LINUX
list David Boldt
Not sure if this is the right venue for posting feature requests, but it
would be useful if html which is generated by programs specified unique
html classes wherever possible to allow CSS styling. an example, for
Information Tables:
*** web/csvinfo.c 2017-06-19 14:14:13.186316715 -0500
--- web/csvinfo.c.new 2017-06-19 14:11:16.385617041 -0500
***************
*** 185,191 ****
sethostenv(wantedname, "", "", colorname(bgcolor), NULL);
headfoot(stdout, hffile, "", "header", bgcolor);
! printf("<table align=center border=1 summary=\"Information
table\">\n");
for (i=0; (headers[i]); i++) {
printf("<tr>\n");
--- 185,191 ----
sethostenv(wantedname, "", "", colorname(bgcolor), NULL);
headfoot(stdout, hffile, "", "header", bgcolor);
! printf("<table class=\"informationTable\" align=center border=1
summary=\"Information table\">\n");
for (i=0; (headers[i]); i++) {
printf("<tr>\n");
which would permit one to specify in file:
gifs/xymonbody.css
table.informationTable td { margin-left: 1em; margin-right: 1em }
to add a little spacing within the table cells around the text.
-- David Boldt
<user-945c7be1b8e4@xymon.invalid>
▸
On Thu, Jun 8, 2017 at 10:33 AM, Frank <user-fbc5ef527f6f@xymon.invalid> wrote:
Well it was working HI!! Here is an except from my hosts.cfg EXAMPLE: 192.168.55.55 eth0:0 192.168.2.56 voip1.example.com (eth0) but voip1 is actually mapped on the DNS to eth0:0
I have xymon-client starting up /home/xymon/runclient.sh --hostname=
voip1.example.com
▸
Up till now everything runs ok. (I have not tried a failover, as I just wanted to get it to work). Probably report as a ghost when it fails over. When I add this, then I get ghost reports: Weird, xymon-server reports itself as one of the ghosts. 192.168.2.56 voip1-2.example.com (eth0 on primary) 192.168.2.57 voip1-3.example.com (eth0 on secondary) On 6/8/17 9:49 AM, Adam Goryachev wrote:Just a nudge, consider what I said about monitoring both servers all the time. Otherwise, if one server dies, but xymon shows all green, you won't know there is a problem until the second server dies too. Regards, Adam On 8/6/17 23:10, Frank wrote:When I say xymon, I mean the xymon-client. The xymon-server is on a different machine. On 6/7/17 7:46 PM, Adam Goryachev wrote:On 8/6/17 07:46, Frank wrote:Hi, I am doing something that I don't think has been done with xymon before. We are running asterisk on a failover heartbeat system. When the failover occurs heartbeat shuts down everything on the primary server and xymon goes nuts. So I set up heartbeat to stop xymon when it shuts everything else down. Now when the "floating IP" goes to the secondary server, the secondary starts up all the services and I set it up for xymon to start too. I was thinking would be a great idea if I could bind xymon to the floating IP the same way I do it for the rest of the services. So far during tests it seems to be working out ok without the binding, but may be necessary after all.When you say "xymon" do you mean xymon-client or are you running the xymon server components on this redundant system? It seems to me that running the monitoring system on the same system that you are monitoring is likely to lead to problems (ie, on total system failure you won't be told about it). I would suggest to run the monitoring on a 3rd server, which is stand-alone from this pair. Xymon doesn't care which IP address the client reports originate from, as long as the name is correct. However, I would advise to have both systems report status individually, with their own names, then you can see the status of each server in the pair. In order to alert and see the status of the services provided by the pair, then you can use combined status such as procs on serverA OR procs on serverB = procs green for Service and so on. Hope this helps... Regards, Adam-- sysadm cronomagic.com/gemstelecom.com e-mail user-fbc5ef527f6f@xymon.invalid POWERED BY LINUX