Hi Stef,
Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.
I noticed the monitoring page (cpu,disk, memory) for the said client is not populated aside from the standard monitors coming off the server (conn,info,ssh,trends). the client log is throwing "Whoops ! Failed to send message (timeout)". I send in a debug for test to the server from the client, which is also timing out. Please advise.
/xymon/logs # tail -10 xymonclient.log 2016-05-18 15:51:47.497327 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:51:47.497375 -> 1st line: 'client aixadm.aix aix' 2016-05-18 15:56:51.683098 Whoops ! Failed to send message (timeout) 2016-05-18 15:56:51.683283 -> 2016-05-18 15:56:51.683308 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:56:51.683352 -> 1st line: 'client aixadm.aix aix' 2016-05-18 16:01:56.124743 Whoops ! Failed to send message (timeout) 2016-05-18 16:01:56.127297 -> 2016-05-18 16:01:56.127323 -> Recipient '172.31.2.131', timeout 15 2016-05-18 16:01:56.127371 -> 1st line: 'client aixadm.aix aix'
/xymon/bin # ./xymon --debug 172.31.2.131 test 9568302 2016-05-18 15:58:27.133743 Transport setup is: 9568302 2016-05-18 15:58:27.133913 xymondportnumber = 1984 9568302 2016-05-18 15:58:27.133926 xymonproxyhost = NONE 9568302 2016-05-18 15:58:27.133940 xymonproxyport = 0 9568302 2016-05-18 15:58:27.133953 Recipient listed as '172.31.2.131' 9568302 2016-05-18 15:58:27.133967 Standard protocol on port 1984 9568302 2016-05-18 15:58:27.133995 Will connect to address 172.31.2.131 port 1984 9568302 2016-05-18 15:58:42.134223 Timeout while talking to Xymon daemon at 172.31.2.131:1984 - retrying 9568302 2016-05-18 15:58:43.134348 Will connect to address 172.31.2.131 port 1984 9568302 2016-05-18 15:58:58.134561 Timeout while talking to Xymon daemon at 172.31.2.131:1984 - retrying 9568302 2016-05-18 15:58:59.134657 Will connect to address 172.31.2.131 port 1984 9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'
Thank you.
On Thu, 19 May 2016, 07:27 Wonder fo <wonderfoo2 at gmail.com> wrote:
Hi Stef,
Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.
...
Will connect to address 172.31.2.131 port 1984
9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'
It looks like a connectivity problem. Timeouts are usually caused by something n the path between the end points, invariably either a routing problem or a firewall problem. Note that a firewall can be on either host (eg iptables, ipfw, pf, etc).
Check that you can ping from client to server. If so, routing is ok. Then check that you can telnet to the server on port 1984. If not, suspect a firewall.
J
The client and server are both inside the firewall sitting on the local network. No issue with either end points to reach one another in terms of routing. The standard monitoring attributes like conn, info,ssh,trends serving through the server for the client page works, but I can't seem to get the *cpu,disk, memory* status from the client to the server to report.
xymonclient.log from the client host is consistently throwing "Whoops ! Failed to send message (timeout)"
*bbd* <http://stlxymon01/xymon-cgi/columndoc.sh?bbd> *clientlog* <http://stlxymon01/xymon-cgi/columndoc.sh?clientlog> *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *cpu* <http://stlxymon01/xymon-cgi/columndoc.sh?cpu> *disk* <http://stlxymon01/xymon-cgi/columndoc.sh?disk> *files* <http://stlxymon01/xymon-cgi/columndoc.sh?files> *http* <http://stlxymon01/xymon-cgi/columndoc.sh?http> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *inode* <http://stlxymon01/xymon-cgi/columndoc.sh?inode> *memory* <http://stlxymon01/xymon-cgi/columndoc.sh?memory> *msgs* <http://stlxymon01/xymon-cgi/columndoc.sh?msgs> *ports* <http://stlxymon01/xymon-cgi/columndoc.sh?ports> *procs* <http://stlxymon01/xymon-cgi/columndoc.sh?procs> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends> *xymond* <http://stlxymon01/xymon-cgi/columndoc.sh?xymond> *xymongen* <http://stlxymon01/xymon-cgi/columndoc.sh?xymongen> *xymonnet* <http://stlxymon01/xymon-cgi/columndoc.sh?xymonnet>
server [image: bbd:green:15d02h36m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=bbd> [image: clientlog:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=clientlog> [image: conn:green:14d22h02m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=conn> [image: cpu:green:6d02h08m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=cpu> [image: disk:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=disk> [image: files:clear:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=files> [image: http:green:2d00h06m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=http> [image: info:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=info> [image: inode:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=inode> [image: memory:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=memory> [image: msgs:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=msgs> [image: ports:green:6d02h40m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ports> [image: procs:green:3d05h33m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=procs> [image: ssh:green:8d22h29m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ssh> [image: trends:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=trends> [image: xymond:green:1d23h14m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymond> [image: xymongen:green:9d23h50m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymongen> [image: xymonnet:green:20h22m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymonnet> ADMIN *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends>
client [image: conn:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=conn> [image: info:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=info> [image: ssh:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=ssh> [image: trends:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=trends>
On Wed, May 18, 2016 at 5:19 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On Thu, 19 May 2016, 07:27 Wonder fo <wonderfoo2 at gmail.com> wrote:
Hi Stef,
Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.
...
Will connect to address 172.31.2.131 port 1984
9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'
It looks like a connectivity problem. Timeouts are usually caused by something n the path between the end points, invariably either a routing problem or a firewall problem. Note that a firewall can be on either host (eg iptables, ipfw, pf, etc).
Check that you can ping from client to server. If so, routing is ok. Then check that you can telnet to the server on port 1984. If not, suspect a firewall.
J
What is the output from: client$ telnet 172.31.2.131 1984
On Thu, May 19, 2016 at 3:31 PM, Wonder fo <wonderfoo2 at gmail.com> wrote:
The client and server are both inside the firewall sitting on the local network. No issue with either end points to reach one another in terms of routing. The standard monitoring attributes like conn, info,ssh,trends serving through the server for the client page works, but I can't seem to get the *cpu,disk, memory* status from the client to the server to report.
xymonclient.log from the client host is consistently throwing "Whoops ! Failed to send message (timeout)"
*bbd* <http://stlxymon01/xymon-cgi/columndoc.sh?bbd> *clientlog* <http://stlxymon01/xymon-cgi/columndoc.sh?clientlog> *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *cpu* <http://stlxymon01/xymon-cgi/columndoc.sh?cpu> *disk* <http://stlxymon01/xymon-cgi/columndoc.sh?disk> *files* <http://stlxymon01/xymon-cgi/columndoc.sh?files> *http* <http://stlxymon01/xymon-cgi/columndoc.sh?http> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *inode* <http://stlxymon01/xymon-cgi/columndoc.sh?inode> *memory* <http://stlxymon01/xymon-cgi/columndoc.sh?memory> *msgs* <http://stlxymon01/xymon-cgi/columndoc.sh?msgs> *ports* <http://stlxymon01/xymon-cgi/columndoc.sh?ports> *procs* <http://stlxymon01/xymon-cgi/columndoc.sh?procs> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends> *xymond* <http://stlxymon01/xymon-cgi/columndoc.sh?xymond> *xymongen* <http://stlxymon01/xymon-cgi/columndoc.sh?xymongen> *xymonnet* <http://stlxymon01/xymon-cgi/columndoc.sh?xymonnet>
server [image: bbd:green:15d02h36m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=bbd> [image: clientlog:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=clientlog> [image: conn:green:14d22h02m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=conn> [image: cpu:green:6d02h08m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=cpu> [image: disk:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=disk> [image: files:clear:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=files> [image: http:green:2d00h06m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=http> [image: info:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=info> [image: inode:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=inode> [image: memory:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=memory> [image: msgs:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=msgs> [image: ports:green:6d02h40m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ports> [image: procs:green:3d05h33m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=procs> [image: ssh:green:8d22h29m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ssh> [image: trends:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=trends> [image: xymond:green:1d23h14m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymond> [image: xymongen:green:9d23h50m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymongen> [image: xymonnet:green:20h22m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymonnet> ADMIN *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends>
client [image: conn:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=conn> [image: info:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=info> [image: ssh:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=ssh> [image: trends:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=trends>
On Wed, May 18, 2016 at 5:19 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On Thu, 19 May 2016, 07:27 Wonder fo <wonderfoo2 at gmail.com> wrote:
Hi Stef,
Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.
...
Will connect to address 172.31.2.131 port 1984
9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'
It looks like a connectivity problem. Timeouts are usually caused by something n the path between the end points, invariably either a routing problem or a firewall problem. Note that a firewall can be on either host (eg iptables, ipfw, pf, etc).
Check that you can ping from client to server. If so, routing is ok. Then check that you can telnet to the server on port 1984. If not, suspect a firewall.
J
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Hi Jeremy,
telnet is disabled by default on xymon server (running Centos 7.2.1511).
Below is probably an expected output consider the security risk of clear text protocol ?
telnet 172.31.2.131 1984
Trying...
*oliver* ohemming at gmail.com <xymon%40xymon.com?Subject=Re%3A%20%5BXymon%5D%20xymon%20for%20AIX&In-Reply-To=%3CCAOAEFMW2t%2B8SPaBvAH1NcmwSM2qG1tH3xiQA8%3DNRzH1AJUKk%3Dg%40mail.gmail.com%3E> *Thu May 19 22:41:32 CEST 2016*
- Previous message: [Xymon] xymon for AIX <http://lists.xymon.com/archive/2016-May/043502.html>
- Next message: [Xymon] Xymon Ticket <http://lists.xymon.com/archive/2016-May/043455.html>
- *Messages sorted by:* [ date ] <http://lists.xymon.com/archive/2016-May/date.html#43503> [ thread ] <http://lists.xymon.com/archive/2016-May/thread.html#43503> [ subject ] <http://lists.xymon.com/archive/2016-May/subject.html#43503> [ author ] <http://lists.xymon.com/archive/2016-May/author.html#43503>
What is the output from: client$ telnet 172.31.2.131 1984
On Thu, May 19, 2016 at 2:31 PM, Wonder fo <wonderfoo2 at gmail.com> wrote:
The client and server are both inside the firewall sitting on the local network. No issue with either end points to reach one another in terms of routing. The standard monitoring attributes like conn, info,ssh,trends serving through the server for the client page works, but I can't seem to get the *cpu,disk, memory* status from the client to the server to report.
xymonclient.log from the client host is consistently throwing "Whoops ! Failed to send message (timeout)"
*bbd* <http://stlxymon01/xymon-cgi/columndoc.sh?bbd> *clientlog* <http://stlxymon01/xymon-cgi/columndoc.sh?clientlog> *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *cpu* <http://stlxymon01/xymon-cgi/columndoc.sh?cpu> *disk* <http://stlxymon01/xymon-cgi/columndoc.sh?disk> *files* <http://stlxymon01/xymon-cgi/columndoc.sh?files> *http* <http://stlxymon01/xymon-cgi/columndoc.sh?http> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *inode* <http://stlxymon01/xymon-cgi/columndoc.sh?inode> *memory* <http://stlxymon01/xymon-cgi/columndoc.sh?memory> *msgs* <http://stlxymon01/xymon-cgi/columndoc.sh?msgs> *ports* <http://stlxymon01/xymon-cgi/columndoc.sh?ports> *procs* <http://stlxymon01/xymon-cgi/columndoc.sh?procs> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends> *xymond* <http://stlxymon01/xymon-cgi/columndoc.sh?xymond> *xymongen* <http://stlxymon01/xymon-cgi/columndoc.sh?xymongen> *xymonnet* <http://stlxymon01/xymon-cgi/columndoc.sh?xymonnet>
server [image: bbd:green:15d02h36m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=bbd> [image: clientlog:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=clientlog> [image: conn:green:14d22h02m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=conn> [image: cpu:green:6d02h08m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=cpu> [image: disk:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=disk> [image: files:clear:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=files> [image: http:green:2d00h06m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=http> [image: info:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=info> [image: inode:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=inode> [image: memory:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=memory> [image: msgs:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=msgs> [image: ports:green:6d02h40m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ports> [image: procs:green:3d05h33m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=procs> [image: ssh:green:8d22h29m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ssh> [image: trends:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=trends> [image: xymond:green:1d23h14m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymond> [image: xymongen:green:9d23h50m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymongen> [image: xymonnet:green:20h22m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymonnet> ADMIN *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends>
client [image: conn:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=conn> [image: info:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=info> [image: ssh:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=ssh> [image: trends:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=trends>
On Wed, May 18, 2016 at 5:19 PM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On Thu, 19 May 2016, 07:27 Wonder fo <wonderfoo2 at gmail.com> wrote:
Hi Stef,
Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.
...
Will connect to address 172.31.2.131 port 1984
9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'
It looks like a connectivity problem. Timeouts are usually caused by something n the path between the end points, invariably either a routing problem or a firewall problem. Note that a firewall can be on either host (eg iptables, ipfw, pf, etc).
Check that you can ping from client to server. If so, routing is ok. Then check that you can telnet to the server on port 1984. If not, suspect a firewall.
J
That's just a quick check to see if you can get through to port 1984, which is where Xymon is listening. If 1984 is being blocked somewhere between client and server, no reports will get through.
Ralph Mitchell
On Tue, May 24, 2016 at 2:13 PM, Wonder fo <wonderfoo2 at gmail.com> wrote:
Hi Jeremy,
telnet is disabled by default on xymon server (running Centos 7.2.1511).
Below is probably an expected output consider the security risk of clear text protocol ?
telnet 172.31.2.131 1984
Trying...
*oliver* ohemming at gmail.com <xymon%40xymon.com?Subject=Re%3A%20%5BXymon%5D%20xymon%20for%20AIX&In-Reply-To=%3CCAOAEFMW2t%2B8SPaBvAH1NcmwSM2qG1tH3xiQA8%3DNRzH1AJUKk%3Dg%40mail.gmail.com%3E> *Thu May 19 22:41:32 CEST 2016*
- Previous message: [Xymon] xymon for AIX <http://lists.xymon.com/archive/2016-May/043502.html>
- Next message: [Xymon] Xymon Ticket <http://lists.xymon.com/archive/2016-May/043455.html>
- *Messages sorted by:* [ date ] <http://lists.xymon.com/archive/2016-May/date.html#43503> [ thread ] <http://lists.xymon.com/archive/2016-May/thread.html#43503> [ subject ] <http://lists.xymon.com/archive/2016-May/subject.html#43503> [ author ] <http://lists.xymon.com/archive/2016-May/author.html#43503>
What is the output from: client$ telnet 172.31.2.131 1984
On Thu, May 19, 2016 at 2:31 PM, Wonder fo <wonderfoo2 at gmail.com> wrote:
The client and server are both inside the firewall sitting on the local network. No issue with either end points to reach one another in terms of routing. The standard monitoring attributes like conn, info,ssh,trends serving through the server for the client page works, but I can't seem to get the *cpu,disk, memory* status from the client to the server to report.
xymonclient.log from the client host is consistently throwing "Whoops ! Failed to send message (timeout)"
*bbd* <http://stlxymon01/xymon-cgi/columndoc.sh?bbd> *clientlog* <http://stlxymon01/xymon-cgi/columndoc.sh?clientlog> *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *cpu* <http://stlxymon01/xymon-cgi/columndoc.sh?cpu> *disk* <http://stlxymon01/xymon-cgi/columndoc.sh?disk> *files* <http://stlxymon01/xymon-cgi/columndoc.sh?files> *http* <http://stlxymon01/xymon-cgi/columndoc.sh?http> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *inode* <http://stlxymon01/xymon-cgi/columndoc.sh?inode> *memory* <http://stlxymon01/xymon-cgi/columndoc.sh?memory> *msgs* <http://stlxymon01/xymon-cgi/columndoc.sh?msgs> *ports* <http://stlxymon01/xymon-cgi/columndoc.sh?ports> *procs* <http://stlxymon01/xymon-cgi/columndoc.sh?procs> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends> *xymond* <http://stlxymon01/xymon-cgi/columndoc.sh?xymond> *xymongen* <http://stlxymon01/xymon-cgi/columndoc.sh?xymongen> *xymonnet* <http://stlxymon01/xymon-cgi/columndoc.sh?xymonnet>
server [image: bbd:green:15d02h36m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=bbd> [image: clientlog:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=clientlog> [image: conn:green:14d22h02m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=conn> [image: cpu:green:6d02h08m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=cpu> [image: disk:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=disk> [image: files:clear:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=files> [image: http:green:2d00h06m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=http> [image: info:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=info> [image: inode:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=inode> [image: memory:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=memory> [image: msgs:green:6d03h03m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=msgs> [image: ports:green:6d02h40m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ports> [image: procs:green:3d05h33m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=procs> [image: ssh:green:8d22h29m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=ssh> [image: trends:green:172.31.2.131] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=trends> [image: xymond:green:1d23h14m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymond> [image: xymongen:green:9d23h50m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymongen> [image: xymonnet:green:20h22m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=stlxymon01.huttig.com&SERVICE=xymonnet> ADMIN *conn* <http://stlxymon01/xymon-cgi/columndoc.sh?conn> *info* <http://stlxymon01/xymon-cgi/columndoc.sh?info> *ssh* <http://stlxymon01/xymon-cgi/columndoc.sh?ssh> *trends* <http://stlxymon01/xymon-cgi/columndoc.sh?trends>
client [image: conn:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=conn> [image: info:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=info> [image: ssh:green:10d20h30m] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=ssh> [image: trends:green:172.31.0.13] <http://stlxymon01/xymon-cgi/svcstatus.sh?HOST=aixadm.huttig.com&SERVICE=trends>
On Wed, May 18, 2016 at 5:19 PM, Jeremy Laidman <jlaidman at rebel-it.com.au
wrote:
On Thu, 19 May 2016, 07:27 Wonder fo <wonderfoo2 at gmail.com> wrote:
Hi Stef,
Your last tip was helpful to get through with the hump on getting the AIX client compiled and initial install.
...
Will connect to address 172.31.2.131 port 1984
9568302 2016-05-18 15:59:14.134814 Closing connection 2016-05-18 15:59:14.134870 Whoops ! Failed to send message (timeout) 2016-05-18 15:59:14.135049 -> 2016-05-18 15:59:14.135099 -> Recipient '172.31.2.131', timeout 15 2016-05-18 15:59:14.135185 -> 1st line: 'test'
It looks like a connectivity problem. Timeouts are usually caused by something n the path between the end points, invariably either a routing problem or a firewall problem. Note that a firewall can be on either host (eg iptables, ipfw, pf, etc).
Check that you can ping from client to server. If so, routing is ok. Then check that you can telnet to the server on port 1984. If not, suspect a firewall.
J
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:
Hi Jeremy,
telnet is disabled by default on xymon server (running Centos 7.2.1511).
As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet.
As an aside, telnet can be secured using kerberos.
Below is probably an expected output consider the security risk of clear text protocol ?
Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible.
For kicks, try using it to connect to the ssh port on the Centos server, from itself.
telnet 127.1 22
If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.)
Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.
telnet 172.31.2.131 1984
Trying...
This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined.
Cheers Jeremy
This sounds like a firewall issue. Search for open poet firewall centos 7 and the command should come up. I just had the same issue. On May 24, 2016 6:46 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:
Hi Jeremy,
telnet is disabled by default on xymon server (running Centos 7.2.1511).
As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet.
As an aside, telnet can be secured using kerberos.
Below is probably an expected output consider the security risk of clear text protocol ?
Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible.
For kicks, try using it to connect to the ssh port on the Centos server, from itself.
telnet 127.1 22
If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.)
Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.
telnet 172.31.2.131 1984
Trying...
This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined.
Cheers Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
In case you need them, here are the firewall commands I used:
[root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=80/tcp success [root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=1984/tcp success [root at xymontest rc3.d]# firewall-cmd --reload
I also just created a service file for startup/shutdown. This may be helpful to you down the road so you won't have to re-invent the wheel. It took me a while and asking a CentOS mailing list to find the answer:
"/usr/lib/systemd/system/xymon.service" 27L, 816C
xymonlaunch.service
systemd file for Fedora 18 and up, or RHEL 7 and up
[Unit] Description=Xymon systems and network monitor Documentation=man:xymon(7) man:xymonlaunch(8) man:xymon(1) After=network.target
[Install]
Compatibility with "xymon" and "xymon-client"
Alias=xymon.service Alias=xymon-client.service WantedBy=multi-user.target
[Service] #EnvironmentFile=/etc/sysconfig/xymonlaunch User=xymon
We wrap in xymoncmd to eliminate the need for the bulk of the old init
script ExecStart=/home/xymon/server/bin/xymoncmd /home/xymon/server/bin/xymonlaunch --no-daemon $XYMONLAUNCHOPTS Type=simple
Kill xymonlaunch, but don't send kills to the underlying procs, since they
might be doing important things (like writing checkpoints and flushing
caches) KillMode=process
SendSIGHUP=yes
SendSIGKILL=no
######################################## - next run the commands below after creating this service file systemctl enable xymon.service systemctl start xymon.service
I had issues where it would only stop or only start. It was not obvious how to write this. Hope you find this helpful
John
On Tue, May 24, 2016 at 6:49 PM, John Langbein <bigbandjohn at gmail.com> wrote:
This sounds like a firewall issue. Search for open poet firewall centos 7 and the command should come up. I just had the same issue. On May 24, 2016 6:46 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:
Hi Jeremy,
telnet is disabled by default on xymon server (running Centos
7.2.1511).
As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet.
As an aside, telnet can be secured using kerberos.
Below is probably an expected output consider the security risk of clear text protocol ?
Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible.
For kicks, try using it to connect to the ssh port on the Centos server, from itself.
telnet 127.1 22
If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.)
Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.
telnet 172.31.2.131 1984
Trying...
This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined.
Cheers Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Thank you all for the valuable input! Appreciate it. The netcat to port 1984 seems to have went through/connected ok based on below output:
nc -v 172.31.2.131 1984
Ncat: Version 6.40 ( http://nmap.org/ncat )Ncat: Connected to 172.31.2.131:1984. p.s: The client pages are still not visible for AIX clients. Thanke!
On Wednesday, May 25, 2016 9:25 AM, John Langbein <bigbandjohn at gmail.com> wrote:In case you need them, here are the firewall commands I used:
[root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=80/tcp success [root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=1984/tcp success [root at xymontest rc3.d]# firewall-cmd --reload
I also just created a service file for startup/shutdown. This may be helpful to you down the road so you won't have to re-invent the wheel. It took me a while and asking a CentOS mailing list to find the answer:
"/usr/lib/systemd/system/xymon.service" 27L, 816C
xymonlaunch.service
systemd file for Fedora 18 and up, or RHEL 7 and up
[Unit] Description=Xymon systems and network monitor Documentation=man:xymon(7) man:xymonlaunch(8) man:xymon(1) After=network.target
[Install]
Compatibility with "xymon" and "xymon-client"
Alias=xymon.service Alias=xymon-client.service WantedBy=multi-user.target
[Service] #EnvironmentFile=/etc/sysconfig/xymonlaunch User=xymon
We wrap in xymoncmd to eliminate the need for the bulk of the old init script
ExecStart=/home/xymon/server/bin/xymoncmd /home/xymon/server/bin/xymonlaunch --no-daemon $XYMONLAUNCHOPTS Type=simple
Kill xymonlaunch, but don't send kills to the underlying procs, since they
might be doing important things (like writing checkpoints and flushing caches)
KillMode=process
SendSIGHUP=yes
SendSIGKILL=no
######################################## - next run the commands below after creating this service file systemctl enable xymon.service systemctl start xymon.service
I had issues where it would only stop or only start. It was not obvious how to write this. Hope you find this helpful
John
On Tue, May 24, 2016 at 6:49 PM, John Langbein <bigbandjohn at gmail.com> wrote:
This sounds like a firewall issue. Search for open poet firewall centos 7 and the command should come up. I just had the same issue.On May 24, 2016 6:46 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote:
On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:
Hi Jeremy,
telnet is disabled by default on xymon server (running Centos 7.2.1511). As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet.As an aside, telnet can be secured using kerberos.> Below is probably an expected output consider the security risk of clear text protocol ?Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible.For kicks, try using it to connect to the ssh port on the Centos server, from itself.# telnet 127.1 22If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.)Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.> # telnet 172.31.2.131 1984 Trying...This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined.Cheers
Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Check the “Ghost Clients” report under the Reports menu. If they are there, you may need to add CLIENT:<whatevername> to your hosts.cfg to make it clear that the client name is different than what the server expected. My Solaris clients were like this — they return the short name to Xymon. Probably this could be fixed automatically in the distribution, actually.
On May 25, 2016, at 2:44 PM, L Foo <wonderfoo2 at gmail.com> wrote:
Thank you all for the valuable input! Appreciate it.
The netcat to port 1984 seems to have went through/connected ok based on below output:
nc -v 172.31.2.131 1984
Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 172.31.2.131:1984.
p.s: The client pages are still not visible for AIX clients.
Thanke!
On Wednesday, May 25, 2016 9:25 AM, John Langbein <bigbandjohn at gmail.com> wrote:
In case you need them, here are the firewall commands I used:
[root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=80/tcp success [root at xymontest rc3.d]# firewall-cmd --permanent --zone=public --add-port=1984/tcp success [root at xymontest rc3.d]# firewall-cmd --reload
I also just created a service file for startup/shutdown. This may be helpful to you down the road so you won't have to re-invent the wheel. It took me a while and asking a CentOS mailing list to find the answer:
"/usr/lib/systemd/system/xymon.service" 27L, 816C
xymonlaunch.service
systemd file for Fedora 18 and up, or RHEL 7 and up
[Unit] Description=Xymon systems and network monitor Documentation=man:xymon(7) man:xymonlaunch(8) man:xymon(1) After=network.target
[Install]
Compatibility with "xymon" and "xymon-client"
Alias=xymon.service Alias=xymon-client.service WantedBy=multi-user.target
[Service] #EnvironmentFile=/etc/sysconfig/xymonlaunch User=xymon
We wrap in xymoncmd to eliminate the need for the bulk of the old init script
ExecStart=/home/xymon/server/bin/xymoncmd /home/xymon/server/bin/xymonlaunch --no-daemon $XYMONLAUNCHOPTS Type=simple
Kill xymonlaunch, but don't send kills to the underlying procs, since they
might be doing important things (like writing checkpoints and flushing caches)
KillMode=process
SendSIGHUP=yes
SendSIGKILL=no
######################################## - next run the commands below after creating this service file systemctl enable xymon.service systemctl start xymon.service
I had issues where it would only stop or only start. It was not obvious how to write this. Hope you find this helpful
John
On Tue, May 24, 2016 at 6:49 PM, John Langbein <bigbandjohn at gmail.com> wrote: This sounds like a firewall issue. Search for open poet firewall centos 7 and the command should come up. I just had the same issue. On May 24, 2016 6:46 PM, "Jeremy Laidman" <jlaidman at rebel-it.com.au> wrote: On 25/05/2016 4:14 AM, "Wonder fo" <wonderfoo2 at gmail.com> wrote:
Hi Jeremy,
telnet is disabled by default on xymon server (running Centos 7.2.1511).
As it should be, the telnet daemon is disabled. But not the telnet client. The centos should not allow anyone to connect to it, but shouldn't stop you connecting from it to other devices that use telnet. As an aside, telnet can be secured using kerberos.
Below is probably an expected output consider the security risk of clear text protocol ? Actually, no, it's not. Here, you are using the telnet command for something other than the telnet protocol. This is an old sysadmin trick. The telnet command primarily just connects to a TCP service, but that doesn't have to be the telnet service, it can be practically any TCP service. It might be a bit confusing at first, but it works; it's as if the command is really called "socket", and just happens to connect on the telnet port by default. But specify another service port, and you have a primitive tcp client for that other service. In fact people have even used telnet in place of a xymon client binary on systems where compiling or installing binaries is not possible. For kicks, try using it to connect to the ssh port on the Centos server, from itself.
telnet 127.1 22
If you run an ssh service on the Centos server, then the above command will successfully connect, and also give you an ssh protocol banner. (To disconnect, press ctrl-] and type quit.) Here, we are using telnet like netcat (aka nc). Netcat is a generic socket connection tool that is much more flexible than the telnet client, but telnet is more universally available, which is why it's so popular as a socket test tool in the sysadmin's toolbox.
telnet 172.31.2.131 1984
Trying... This should say "connected" almost instantly. The fact that it says neither "connected" nor "refused" tells me that there's a firewall dropping packets. As you say, there's no firewall between the client and server. So the most likely cause is a firewall /on/ the client or server. That would be something like iptables (technically called netfilter) on the Centos Xymon server, restricting incoming connections on port 1984, or something like TCP/IP filters on the AIX Xymon client, restricting outbound connections. Try running "iptables-save" on the Xymon server to see if there are rules defined; try running "lsfilt" on the Xymon client to see if there are rules defined. Cheers Jeremy
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
--
|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'
On Thu, May 26, 2016 at 4:44 AM L Foo <wonderfoo2 at gmail.com> wrote:
The netcat to port 1984 seems to have went through/connected ok based on below output:
nc -v 172.31.2.131 1984
Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 172.31.2.131:1984.
You ran this on the AIX host? If this works, then telnet should have also worked, and so should the xymon client.
Can you please try the following (on the AIX host):
echo "ping" | nc 127.31.2.131 1984
That should return the xymon version details of the Xymon server.
Then try this:
/xymon/bin/xymon 172.31.2.131 ping
You should see the same thing. Or maybe a timeout
If this doesn't work, then can you try this:
truss -f /xymon/bin/xymon 172.31.2.131 ping
I'm particularly interested in the output around socket() and connect() calls, and what responses codes are given.
I'm wondering if you have some sort of kernel-based binary restrictions in place, such as Trusted AIX, TCB or Trusted Execution. From what I can tell, these tools allow one to lock down a server so that no unauthorized binaries can execute, or they might be able to execute but cannot perform certain functions.
An alternative to all of this is to use my xymon-rclient script, available on xymonton.org, or http://tools.rebel-it.com.au/xymon-rclient. Essentially it allows for an clientless client by pushing the Xymon client script to the target from the Xymon server (typically over ssh) and grabs the client data directly. In this way, it doesn't rely on a xymon client binary. There are some limitations, which is why it's better to try to get your client working, but it may be easier to get something going this way.
Cheers Jeremy
Thanks for ALL your valuable feedback! The hint from Ryan seemed to have cured the client page reporting issues. As it turned out, the AIX clients in questioned showed up in 'Ghost Clients' list on in short hostname as opposed to it's real FQDN hostname. I've since updated the xymon server side configuration's files for the said AIX clients from FQDN hostname to short hostnames, the client pages were getting proper updates now. Thank you Ryan!!!
On Thursday, May 26, 2016 12:05 AM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:On Thu, May 26, 2016 at 4:44 AM L Foo <wonderfoo2 at gmail.com> wrote:
The netcat to port 1984 seems to have went through/connected ok based on below output:
nc -v 172.31.2.131 1984
Ncat: Version 6.40 ( http://nmap.org/ncat )Ncat: Connected to 172.31.2.131:1984.
You ran this on the AIX host? If this works, then telnet should have also worked, and so should the xymon client. Can you please try the following (on the AIX host):
echo "ping" | nc 127.31.2.131 1984
That should return the xymon version details of the Xymon server. Then try this:
/xymon/bin/xymon 172.31.2.131 ping
You should see the same thing. Or maybe a timeout If this doesn't work, then can you try this:
truss -f /xymon/bin/xymon 172.31.2.131 ping
I'm particularly interested in the output around socket() and connect() calls, and what responses codes are given. I'm wondering if you have some sort of kernel-based binary restrictions in place, such as Trusted AIX, TCB or Trusted Execution. From what I can tell, these tools allow one to lock down a server so that no unauthorized binaries can execute, or they might be able to execute but cannot perform certain functions. An alternative to all of this is to use my xymon-rclient script, available on xymonton.org, or http://tools.rebel-it.com.au/xymon-rclient. Essentially it allows for an clientless client by pushing the Xymon client script to the target from the Xymon server (typically over ssh) and grabs the client data directly. In this way, it doesn't rely on a xymon client binary. There are some limitations, which is why it's better to try to get your client working, but it may be easier to get something going this way. CheersJeremy
You are most welcome.
So here’s some followup: many of us have had this problem before, and it seems OS-specific. Is there any way to get this more right by default? I see that many/most of my entries in hosts.cfg have CLIENT:<hostname> specified. My server is Solaris 10, my clients are a mixture of things.
On May 31, 2016, at 5:10 PM, L Foo <wonderfoo2 at gmail.com> wrote:
Thanks for ALL your valuable feedback!
The hint from Ryan seemed to have cured the client page reporting issues. As it turned out, the AIX clients in questioned showed up in 'Ghost Clients' list on in short hostname as opposed to it's real FQDN hostname. I've since updated the xymon server side configuration's files for the said AIX clients from FQDN hostname to short hostnames, the client pages were getting proper updates now. Thank you Ryan!!!
On Thursday, May 26, 2016 12:05 AM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On Thu, May 26, 2016 at 4:44 AM L Foo <wonderfoo2 at gmail.com> wrote: The netcat to port 1984 seems to have went through/connected ok based on below output:
nc -v 172.31.2.131 1984
Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 172.31.2.131:1984.
You ran this on the AIX host? If this works, then telnet should have also worked, and so should the xymon client.
Can you please try the following (on the AIX host):
echo "ping" | nc 127.31.2.131 1984
That should return the xymon version details of the Xymon server.
Then try this:
/xymon/bin/xymon 172.31.2.131 ping
You should see the same thing. Or maybe a timeout
If this doesn't work, then can you try this:
truss -f /xymon/bin/xymon 172.31.2.131 ping
I'm particularly interested in the output around socket() and connect() calls, and what responses codes are given.
I'm wondering if you have some sort of kernel-based binary restrictions in place, such as Trusted AIX, TCB or Trusted Execution. From what I can tell, these tools allow one to lock down a server so that no unauthorized binaries can execute, or they might be able to execute but cannot perform certain functions.
An alternative to all of this is to use my xymon-rclient script, available on xymonton.org, or http://tools.rebel-it.com.au/xymon-rclient. Essentially it allows for an clientless client by pushing the Xymon client script to the target from the Xymon server (typically over ssh) and grabs the client data directly. In this way, it doesn't rely on a xymon client binary. There are some limitations, which is why it's better to try to get your client working, but it may be easier to get something going this way.
Cheers Jeremy
--
|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'
On 05/31/2016 11:27 PM, Ryan Novosielski wrote:
You are most welcome.
So here’s some followup: many of us have had this problem before, and it seems OS-specific. Is there any way to get this more right by default? I see that many/most of my entries in hosts.cfg have CLIENT:<hostname> specified. My server is Solaris 10, my clients are a mixture of things. In theory, a hostname contains no domain suffix. So you should never have a FQDN in your hosts.cfg
Stef
On Wed, Jun 1, 2016 at 5:11 PM Stef Coene <stef.coene at docum.org> wrote:
On 05/31/2016 11:27 PM, Ryan Novosielski wrote:
So here’s some followup: many of us have had this problem before, and it seems OS-specific. Is there any way to get this more right by default? I see that many/most of my entries in hosts.cfg have CLIENT:<hostname> specified. My server is Solaris 10, my clients are a mixture of things.
In theory, a hostname contains no domain suffix.
Yes, possibly. What the xymon client uses as a "hostname" when it creates
a client message is $MACHINEDOTS, which the output of uname -n. POSIX
defines this as the "network node name" which doesn't really say if it's
the FQDN or the shortname.
So you should never have a FQDN in your hosts.cfg
So what if you have www.internal.example.com <http://www.in.telstra.com> and www.example.com? It seems to me that the primary attribute for a hostname is for it to be unique. On the Internet, that generally means FQDN.
J
Hi,
I think, the default is to use FQDN. It is defined in xymonserver.cfg:
General settings
FQDN="TRUE" # Use fully-qualified hostnames internally. Keep it TRUE unless you know better.
So you should never have a FQDN in your hosts.cfgSo what if you have www.internal.example.com <http://www.in.telstra.com> and www.example.com <http://www.example.com>? It seems to me that the primary attribute for a hostname is for it to be unique. On the Internet, that generally means FQDN.
Regards, Dirk
Absolutely true. Also from the Xymon message format documentation:
http://xymon.sourceforge.net/xymon/help/manpages/man1/xymon.1.html
"XYMON MESSAGE SYNTAX
This section lists the most commonly used messages in the Xymon protocol.
Each message must begin with one of the Xymon commands. Where a HOSTNAME is specified, it must have any dots in the hostname changed to commas if the Xymon FQDN setting is enabled (which is the default). So the host "www.foo.com", for example, would report as "www,foo,com”." —
I took a look at the clientlog test on my equipment, under the first [collector] stanza, for all of my equipment: it is FQDN on almost all of my Linux machines, and it is hostname-only on almost all of my Solaris machines.
On Jun 1, 2016, at 5:29 AM, Dirk Kastens <dirk.kastens at uni-osnabrueck.de> wrote:
Hi,
I think, the default is to use FQDN. It is defined in xymonserver.cfg:
General settings
FQDN="TRUE" # Use fully-qualified hostnames internally. Keep it TRUE unless you know better.
So you should never have a FQDN in your hosts.cfg
So what if you have www.internal.example.com <http://www.in.telstra.com> and www.example.com <http://www.example.com>? It seems to me that the primary attribute for a hostname is for it to be unique. On the Internet, that generally means FQDN.
--
|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'
On 5/31/2016 11:11 PM, Stef Coene wrote:
On 05/31/2016 11:27 PM, Ryan Novosielski wrote:
You are most welcome.
So here’s some followup: many of us have had this problem before, and it seems OS-specific. Is there any way to get this more right by default? I see that many/most of my entries in hosts.cfg have CLIENT:<hostname> specified. My server is Solaris 10, my clients are a mixture of things.
In theory, a hostname contains no domain suffix. So you should never have a FQDN in your hosts.cfg
{bangs head on desk} This approach is so 1998 . . .
Moving from Big Brother to Xymon was so liberating because we finally got consistent "fully qualified domainn name" (FQDN) support. There is no reason not to use FQDN in your hosts.cfg. Use them. It is silly not to.
All of the hosts in my Xymon are defined with FQDN. But there are several which also have "CLIENT:" tags defined with their "short" name. These are generally:
- Hosts running scripts from our BB days before we had FQDN support
- Windows hosts whose admins don't know how to configure the client
- Editors who blindly copy some other line from hosts.cfg and assume they must have a CLIENT: tag
IMHO, anyone using truncated host names in their hosts.cfg should have to justify each of those entries in writing. FQDNs work. Make the world a better place; use them.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska
There were two issues that seemed to have resolved - related to the AIX clients. Both were resolved through the tips provided along these threads. One was opening up the Centos server firewall ports AND the suggestion provided by Ryan to cure the state with client web pages not getting updates - shown as 'Ghost Clients' under 'Reports' (no updates until the short hostnames were populated in host cfg on the xymon server). All of our *NIX hosts were of FQDN hostnames in this environment.
Hope that clarify the 'mystery' surrounding AIX client for xymon on this thread.
Thank you ALL!
On Tue, May 31, 2016 at 4:27 PM, Ryan Novosielski <novosirj at rutgers.edu> wrote:
You are most welcome.
So here’s some followup: many of us have had this problem before, and it seems OS-specific. Is there any way to get this more right by default? I see that many/most of my entries in hosts.cfg have CLIENT:<hostname> specified. My server is Solaris 10, my clients are a mixture of things.
On May 31, 2016, at 5:10 PM, L Foo <wonderfoo2 at gmail.com> wrote:
Thanks for ALL your valuable feedback!
The hint from Ryan seemed to have cured the client page reporting issues. As it turned out, the AIX clients in questioned showed up in 'Ghost Clients' list on in short hostname as opposed to it's real FQDN hostname. I've since updated the xymon server side configuration's files for the said AIX clients from FQDN hostname to short hostnames, the client pages were getting proper updates now. Thank you Ryan!!!
On Thursday, May 26, 2016 12:05 AM, Jeremy Laidman < jlaidman at rebel-it.com.au> wrote:
On Thu, May 26, 2016 at 4:44 AM L Foo <wonderfoo2 at gmail.com> wrote: The netcat to port 1984 seems to have went through/connected ok based on below output:
nc -v 172.31.2.131 1984
Ncat: Version 6.40 ( http://nmap.org/ncat ) Ncat: Connected to 172.31.2.131:1984.
You ran this on the AIX host? If this works, then telnet should have also worked, and so should the xymon client.
Can you please try the following (on the AIX host):
echo "ping" | nc 127.31.2.131 1984
That should return the xymon version details of the Xymon server.
Then try this:
/xymon/bin/xymon 172.31.2.131 ping
You should see the same thing. Or maybe a timeout
If this doesn't work, then can you try this:
truss -f /xymon/bin/xymon 172.31.2.131 ping
I'm particularly interested in the output around socket() and connect() calls, and what responses codes are given.
I'm wondering if you have some sort of kernel-based binary restrictions in place, such as Trusted AIX, TCB or Trusted Execution. From what I can tell, these tools allow one to lock down a server so that no unauthorized binaries can execute, or they might be able to execute but cannot perform certain functions.
An alternative to all of this is to use my xymon-rclient script, available on xymonton.org, or http://tools.rebel-it.com.au/xymon-rclient. Essentially it allows for an clientless client by pushing the Xymon client script to the target from the Xymon server (typically over ssh) and grabs the client data directly. In this way, it doesn't rely on a xymon client binary. There are some limitations, which is why it's better to try to get your client working, but it may be easier to get something going this way.
Cheers Jeremy
--
|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'
On Wed, Jun 1, 2016 at 7:10 AM L Foo <wonderfoo2 at gmail.com> wrote:
Thanks for ALL your valuable feedback!
I'm glad you sorted it out.
The hint from Ryan seemed to have cured the client page reporting issues.
As it turned out, the AIX clients in questioned showed up in 'Ghost Clients' list on in short hostname as opposed to it's real FQDN hostname.
This explanation doesn't fit with this symptom:
/xymon/logs # tail -10 xymonclient.log ... 2016-05-18 15:56:51.683098 Whoops ! Failed to send message (timeout)
nor this:
/xymon/bin # ./xymon --debug 172.31.2.131 test ... 9568302 2016-05-18 15:58:42.134223 Timeout while talking to Xymon daemon at 172.31.2.131:1984 - retrying
If your client cannot talk to the Xymon server, it cannot create a ghost client entry. The cause of the above symptoms remains a mystery (to me).
J
On Jun 1, 2016, at 5:08 AM, Jeremy Laidman <jlaidman at rebel-it.com.au> wrote:
On Wed, Jun 1, 2016 at 7:10 AM L Foo <wonderfoo2 at gmail.com> wrote: Thanks for ALL your valuable feedback!
I'm glad you sorted it out.
The hint from Ryan seemed to have cured the client page reporting issues. As it turned out, the AIX clients in questioned showed up in 'Ghost Clients' list on in short hostname as opposed to it's real FQDN hostname.
This explanation doesn't fit with this symptom:
/xymon/logs # tail -10 xymonclient.log ... 2016-05-18 15:56:51.683098 Whoops ! Failed to send message (timeout)
nor this:
/xymon/bin # ./xymon --debug 172.31.2.131 test ... 9568302 2016-05-18 15:58:42.134223 Timeout while talking to Xymon daemon at 172.31.2.131:1984 - retrying
If your client cannot talk to the Xymon server, it cannot create a ghost client entry. The cause of the above symptoms remains a mystery (to me).
Might have been both problems? Didn’t he also make some firewall changes or something (I was skimming the earlier messages — I could be wrong).
--
|| \\UTGERS, |---------------------------*O*--------------------------- ||_// the State | Ryan Novosielski - novosirj at rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark `'
participants (9)
-
bigbandjohn＠gmail.com
-
dirk.kastens＠uni-osnabrueck.de
-
jlaidman＠rebel-it.com.au
-
john.thurston＠alaska.gov
-
novosirj＠rutgers.edu
-
ohemming＠gmail.com
-
ralphmitchell＠gmail.com
-
stef.coene＠docum.org
-
wonderfoo2＠gmail.com