The saga continues.
I got my network people to open up 1985 through the firewall to my
machines, and then restarted xymon-client on those machines to use 1985
with msgcache. So while that is wrong, at least I have a work around.
Also, the fetch=ip:1984 was ignored, it only would talk on port 1985.
Then the xymonfetch on the proxy servers would connect and get data from
them.
HOWEVER, the proxy servers will not send the data to the proxy port
(1984), only the server port (1985). Which doesnât get me data to my
primary server.
Is it possible to run xymonfetch from a client machine? That client would
send to the xymon proxy server.
If I get time today (or maybe over the weekend), Iâm going to try to put
my new xymon proxy server in place (CentOS6 with 4.3.21). Again the
current servers are CentOS 5 with 4.3.10.
[xymonfetch]
ENVFILE /etc/xymon/xymonserver.cfg
#CMD $XYMONHOME/bin/xymonfetch --server=127.0.0.1:1984 --id=1
--pidfile=$XYMONSERVERLOGS/xymonfetch.pid
# does not work
CMD $XYMONHOME/bin/xymonfetch --server=204.155.140.159:1984 --id=1
--pidfile=$XYMONSERVERLOGS/xymonfetch.pid # does not
work
#CMD $XYMONHOME/bin/xymonfetch id=1
--pidfile=$XYMONSERVERLOGS/xymonfetch.pid
#
works to server not proxy
LOGFILE $XYMONSERVERLOGS/xymonfetch.log
Xymonfetch.log:
2015-11-13 08:00:19 Invalid client IP: 127.0.0.1:1984 (req 2435)
2015-11-13 08:03:36 Invalid client IP: 127.0.0.1:1984 (req 2443)
2015-11-13 08:15:22 Invalid client IP: 127.0.0.1:1984 (req 2473)
2015-11-13 08:18:46 Invalid client IP: 127.0.0.1:1984 (req 2481)
2015-11-13 08:27:52 Caught TERM signal, terminating
2015-11-13 08:27:52 Caught TERM signal, terminating
2015-11-13 08:27:52 Caught TERM signal, terminating
2015-11-13 08:29:24 Invalid client IP: 204.155.140.159:1984 (req 6)
2015-11-13 08:29:24 Invalid client IP: 204.155.140.159:1984 (req 6)
2015-11-13 08:29:24 Invalid client IP: 204.155.140.159:1984 (req 6)
2015-11-13 08:30:45 Invalid client IP: 204.155.140.159:1984 (req 10)
2015-11-13 08:30:45 Invalid client IP: 204.155.140.159:1984 (req 10)
2015-11-13 08:30:45 Invalid client IP: 204.155.140.159:1984 (req 10)
From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Root, Paul T
Sent: Thursday, November 12, 2015 9:14 AM
To: 'Japheth Cleaver'; 'xymon at xymon.com'
Subject: Re: [Xymon] xymonfetch
It gets even weirder. If I run it without xymoncmd, then it uses port 1984
(the xymonproxy) but then is trying to pull data from the machine the main
server pulls from, and doesnât even exist in the proxyâs hosts.cfg.
But when I run with xymoncmd, I get this. To me, it appears to be
completely ignoring the command line:
$ xymonfetch --server=:1984 --log-interval=60 --id=1 --debug
28843 2015-11-12 08:56:09 Transport setup is:
28843 2015-11-12 08:56:09 xymondportnumber = 1985
28843 2015-11-12 08:56:09 xymonproxyhost = NONE
28843 2015-11-12 08:56:09 xymonproxyport = 0
28843 2015-11-12 08:56:09 Recipient listed as '204.155.140.159'
28843 2015-11-12 08:56:09 Standard protocol on port 1985
28843 2015-11-12 08:56:09 Will connect to address 204.155.140.159 port
1985
28843 2015-11-12 08:56:09 Connect status is 0
28843 2015-11-12 08:56:09 Sent 16 bytes
28843 2015-11-12 08:56:09 Read 14206 bytes
28843 2015-11-12 08:56:09 Closing connection
28843 2015-11-12 08:56:09 Queuing request 1 to 10.6.0.15:1985 for
remoteclient2: 'pullclient 1
'
28843 2015-11-12 08:56:09 Queuing request 2 to 10.6.0.14:1985 for
remoteclient: 'pullclient 1
'
2015-11-12 08:56:09 Connection lost during connect/write to 10.6.0.14:1985
(req 2): Connection refused
28843 2015-11-12 08:56:09 Doing cleanup
28843 2015-11-12 08:56:09 Next poll of remoteclient in 55 seconds
28843 2015-11-12 08:56:09 Request completed: req 2, peer 10.6.0.14:1985,
action was 2, type was 0
2015-11-12 08:56:09 Connection lost during connect/write to 10.6.0.15:1985
(req 1): Connection refused
28843 2015-11-12 08:56:09 Doing cleanup
28843 2015-11-12 08:56:09 Next poll of remoteclient2 in 48 seconds
28843 2015-11-12 08:56:09 Request completed: req 1, peer 10.6.0.14:1985,
action was 2, type was 0
28843 2015-11-12 08:56:57 Queuing request 3 to 10.6.0.15:1985 for
remoteclient2: 'pullclient 1
'
2015-11-12 08:56:57 Connection lost during connect/write to 10.6.0.15:1985
(req 3): Connection refused
28843 2015-11-12 08:56:57 Doing cleanup
28843 2015-11-12 08:56:57 Next poll of remoteclient2 in 52 seconds
28843 2015-11-12 08:56:57 Request completed: req 3, peer 10.6.0.15:1985,
action was 2, type was 0
It makes no difference if I put in âserver=127.0.0.1:1984 or
âserver=204.155.140.159:1984.
From: Japheth Cleaver [mailto:user-87556346d4af@xymon.invalid]
Sent: Wednesday, November 11, 2015 6:13 PM
To: Root, Paul T; xymon at xymon.com<mailto:xymon at xymon.com>
Subject: Re: [Xymon] xymonfetch
On 11/11/2015 2:04 PM, Root, Paul T wrote:
Iâm having issues with xymonfetch.
I have 2 xymon proxies, that also have the xymon server running as a
backup to the main server on port 1985. The proxy sends to the main
server on port 1984 and to itself on port 1985.
Iâm trying to add 2 new machines as clients of these proxy servers. They
are outside a firewall that I donât want to open, so Iâm doing a
fetch. Xymon-client is running on 1984, and msgcache is running.
Client clientlaunch.cfg:
[msgcache]
# DISABLED
ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg
CMD $XYMONCLIENTHOME/bin/msgcache --no-daemon
--pidfile=$XYMONCLIENTLOGS/msgcache.pid
LOGFILE $XYMONCLIENTLOGS/msgcache.log
Proxy tasks.cfg:
[xymonfetch]
ENVFILE /etc/xymon/xymonserver.cfg
#CMD $XYMONHOME/bin/xymonfetch --server=YOUR.XYMON.SERVER.IP
--no-daemon --pidfile=$XYMONSERVERLOGS/xymonfetch.pid
CMD $XYMONHOME/bin/xymonfetch --server=127.0.0.1:1985
--log-interval=60 --id=1 --pidfile=$XYMONSERVERLOGS/xymonfetch.pid
LOGFILE $XYMONSERVERLOGS/xymonfetch.log
Proxy hosts.cfg:
10.6.0.14 remoteclient # pulldata=10.6.0.14:1984
http://198.36.155.243
10.6.0.15 remoteclient2 # pulldata=10.6.0.15:1984
I have a third xymon server, the development server, which is not a proxy,
and the server runs on 1984. This pulls the data just fine from the
remoteclients.
The xymonfetch.log file gets these errors:
2015-11-11 15:56:24 Connection lost during connect/write to 10.6.0.14:1985
(req 27): Connection refused
2015-11-11 15:56:41 Connection lost during connect/write to 10.6.0.15:1985
(req 28): Connection refused
2015-11-11 15:57:27 Connection lost during connect/write to 10.6.0.14:1985
(req 29): Connection refused
2015-11-11 15:57:44 Connection lost during connect/write to 10.6.0.15:1985
(req 30): Connection refused
The proxy servers are 4.3.10. The development server is 4.3.21. The main
server is also 4.3.10, and it runs a fetch without issue, to other
clients.
The clients are 4.3.10 (CentOS 5) and 4.3.21 (CentOS 6).
I am working on upgrading the proxy servers in OS (CentOS 5 -> 6) and
Xymon (to 4.3.21). But not quite there yet. Another subject, but sending
data from a proxy to another proxy does not work. So, when I have
everything else, I may end up putting it in place, and hoping the proxy
worksâ¦.
Any ideas here? It seems like such a simple thing.
Does seem a bit odd. Either xymonfetch is not paying attention to
pulldata, or it seems to want to reconnect back to the original host
incorrectly for the client (config) reply. Can you try --debug on the
xymonfetch process, or alternatively strace it, so we can see at which
phase of the transaction that write is failing at?
On the second issue, I know xymonproxy is capable of doing proxy-proxy
submission, as we used it pretty heavily for that (albeit with caveats at
scale when dealing with TCP packet loss), does a 'ping' make it through at
all when going on that path?
-jc
This communication is the property of CenturyLink and may contain
confidential or privileged information. Unauthorized use of this
communication is strictly prohibited and may be unlawful. If you have
received this communication in error, please immediately notify the sender
by reply e-mail and destroy all copies of the communication and any
attachments.
This communication is the property of CenturyLink and may contain
confidential or privileged information. Unauthorized use of this
communication is strictly prohibited and may be unlawful. If you have
received this communication in error, please immediately notify the sender
by reply e-mail and destroy all copies of the communication and any
attachments.