Xymon Mailing List Archive search

xymon for AIX

26 messages in this thread

list Lih Eng Foo · Fri, 6 May 2016 15:00:08 -0500 · 
Greetings!

I just stood up an xymon server on Centos 7.2.1511 and I am in the process
of gathering information to facilitate with the install/setup of AIX7 xymon
clients. i can't seem to locate a central site centric to AIX client
software download/installation/setup for xymon. Kindly point me to the
right direction.


Thanks in advance!
list Stef Coene · Wed, 11 May 2016 08:41:59 +0200 ·
▸ quoted from Lih Eng Foo
On 05/06/2016 10:00 PM, Lih Eng Foo wrote:
Greetings!

I just stood up an xymon server on Centos 7.2.1511 and I am in the
process of gathering information to facilitate with the install/setup of
AIX7 xymon clients. i can't seem to locate a central site centric to AIX
client software download/installation/setup for xymon. Kindly point me
to the right direction.
As far as I know, there is no xymon client lpp.
I compile the AIX client on a development box and deploy it to other 
servers by just copying over the folder. It works fine across different 
AIX levels and releases.


Stef
list Wonder fo · Fri, 13 May 2016 12:48:15 -0500 · 
Thanks for your feedback, Stef.

Follow up on xymon for AIX. Here's what I have gotten on the client host
running AIX7.1

1.  xymon-4.3.27
2.   pcre                        8.32-1    C     R    Perl-compatible
regular
3.  make-4.0-1
          lrwxrwxrwx    1 root     system           27 Jul 24 2014
 /usr/bin/gmake@ ../../opt/freeware/bin/make*


Here's the output with configure.client:

# MAKE=gmake ./configure.client

Configuration script for Xymon client

This script asks a few questions and builds a Makefile to compile Xymon

Checking your make-utility
Xymon normally keeps all of the client configuration files
on the Xymon server. If you prefer, it is possible to use
a local client configuration file instead - if so, answer
'client' to the next question.
NB: Local configuration requires the PCRE libs on each host.

Server side client configuration, or client side [server] ?
client

Checking for the PCRE libraries
Checking for PCRE ...
gmake: cc: Command not found
Makefile.test-pcre:4: recipe for target 'test-compile' failed
gmake: *** [test-compile] Error 127
ERROR: Cannot compile using PCRE library.
gmake: cc: Command not found
Makefile.test-pcre:7: recipe for target 'test-link' failed
gmake: *** [test-link] Error 127
ERROR: Cannot link with PCRE library.
Missing PCRE include- or library-files. These are REQUIRED for xymond
PCRE can be found at http://www.pcre.org/
If you have PCRE installed, use the "--pcreinclude DIR" and "--pcrelib DIR"
options to configure to specify where they are.


Wonder if anything else I missed? Is pcre-devel also a pre-req for xymon
client?


Thanks!
list Stef Coene · Sat, 14 May 2016 10:52:16 +0200 ·
▸ quoted from Wonder fo
On 05/13/2016 07:48 PM, Wonder fo wrote:
Thanks for your feedback, Stef.

Follow up on xymon for AIX. Here's what I have gotten on the client host
running AIX7.1

1.  xymon-4.3.27
2.   pcre                        8.32-1    C     R    Perl-compatible
regular
3.  make-4.0-1
           lrwxrwxrwx    1 root     system           27 Jul 24 2014
  /usr/bin/gmake@ ../../opt/freeware/bin/make*


Here's the output with configure.client:

# MAKE=gmake ./configure.client

Configuration script for Xymon client

This script asks a few questions and builds a Makefile to compile Xymon

Checking your make-utility
Xymon normally keeps all of the client configuration files
on the Xymon server. If you prefer, it is possible to use
a local client configuration file instead - if so, answer
'client' to the next question.
NB: Local configuration requires the PCRE libs on each host.

Server side client configuration, or client side [server] ?
client
Normally you use server, not client.
So all configuration is done on the server.
And I think in that case you don't need pcre.


Stef
list Wonder fo · Wed, 18 May 2016 16:14:19 -0500 · 
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.
list Jeremy Laidman · Wed, 18 May 2016 22:19:59 +0000 ·
▸ quoted from Wonder fo
On Thu, 19 May 2016, 07:27 Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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
list Wonder fo · Thu, 19 May 2016 14:31:01 -0500 · 
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 <user-71895fb2e44c@xymon.invalid>
▸ quoted from Jeremy Laidman
wrote:

On Thu, 19 May 2016, 07:27 Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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
list Oliver · Thu, 19 May 2016 16:41:32 -0400 · 
What is the output from:
client$ telnet 172.31.2.131 1984
▸ quoted from Wonder fo

On Thu, May 19, 2016 at 3:31 PM, Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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 <user-71895fb2e44c@xymon.invalid>
wrote:

On Thu, 19 May 2016, 07:27 Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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
list Wonder fo · Tue, 24 May 2016 13:13:26 -0500 · 
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* user-c44cbd0c692f@xymon.invalid
<xymon%40xymon.com?Subject=Re%3A%20%5BXymon%5D%20xymon%20for%20AIX&In-Reply-To=user-e797b2cf0dc4@xymon.invalid%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>;
▸ quoted from Oliver


What is the output from:
client$ telnet 172.31.2.131 1984


On Thu, May 19, 2016 at 2:31 PM, Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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 <user-71895fb2e44c@xymon.invalid>
wrote:

On Thu, 19 May 2016, 07:27 Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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
list Ralph Mitchell · Tue, 24 May 2016 16:02:04 -0400 · 
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
▸ quoted from Wonder fo


On Tue, May 24, 2016 at 2:13 PM, Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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* user-c44cbd0c692f@xymon.invalid
<xymon%40xymon.com?Subject=Re%3A%20%5BXymon%5D%20xymon%20for%20AIX&In-Reply-To=user-e797b2cf0dc4@xymon.invalid%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 <user-8a0f7702e6b1@xymon.invalid> 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 <user-71895fb2e44c@xymon.invalid
wrote:
On Thu, 19 May 2016, 07:27 Wonder fo <user-8a0f7702e6b1@xymon.invalid> 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
list Jeremy Laidman · Wed, 25 May 2016 09:46:33 +1000 ·
▸ quoted from Wonder fo
On 25/05/2016 4:14 AM, "Wonder fo" <user-8a0f7702e6b1@xymon.invalid> 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.
▸ quoted from Ralph Mitchell
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
list John Langbein · Tue, 24 May 2016 18:49:53 -0500 · 
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.
▸ quoted from Jeremy Laidman
On May 24, 2016 6:46 PM, "Jeremy Laidman" <user-71895fb2e44c@xymon.invalid> wrote:

On 25/05/2016 4:14 AM, "Wonder fo" <user-8a0f7702e6b1@xymon.invalid> 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
list John Langbein · Wed, 25 May 2016 09:25:41 -0500 · 
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 <user-029cb4cdcfef@xymon.invalid>
▸ quoted from John Langbein
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" <user-71895fb2e44c@xymon.invalid>
wrote:

On 25/05/2016 4:14 AM, "Wonder fo" <user-8a0f7702e6b1@xymon.invalid> 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
list L Foo · Wed, 25 May 2016 18:44:30 +0000 (UTC) · 
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!
▸ quoted from John Langbein

    On Wednesday, May 25, 2016 9:25 AM, John Langbein <user-029cb4cdcfef@xymon.invalid> 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 <user-029cb4cdcfef@xymon.invalid> 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" <user-71895fb2e44c@xymon.invalid> wrote:

On 25/05/2016 4:14 AM, "Wonder fo" <user-8a0f7702e6b1@xymon.invalid> 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
list Ryan Novosielski · Wed, 25 May 2016 21:30:47 +0000 · 
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.
▸ quoted from L Foo
On May 25, 2016, at 2:44 PM, L Foo <user-8a0f7702e6b1@xymon.invalid> 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 <user-029cb4cdcfef@xymon.invalid> 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 <user-029cb4cdcfef@xymon.invalid> 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" <user-71895fb2e44c@xymon.invalid> wrote:
On 25/05/2016 4:14 AM, "Wonder fo" <user-8a0f7702e6b1@xymon.invalid> 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


--
____

|| \\UTGERS,  	 |---------------------------*O*---------------------------
||_// the State	 |         Ryan Novosielski - user-46c89e614701@xymon.invalid
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
     `'
list Jeremy Laidman · Thu, 26 May 2016 05:05:14 +0000 ·
▸ quoted from L Foo
On Thu, May 26, 2016 at 4:44 AM L Foo <user-8a0f7702e6b1@xymon.invalid> 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
list L Foo · Tue, 31 May 2016 21:10:25 +0000 (UTC) · 
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!!!
▸ quoted from Jeremy Laidman


    On Thursday, May 26, 2016 12:05 AM, Jeremy Laidman <user-71895fb2e44c@xymon.invalid> wrote:
 

 On Thu, May 26, 2016 at 4:44 AM L Foo <user-8a0f7702e6b1@xymon.invalid> 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
list Ryan Novosielski · Tue, 31 May 2016 21:27:04 +0000 · 
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.
▸ quoted from L Foo
On May 31, 2016, at 5:10 PM, L Foo <user-8a0f7702e6b1@xymon.invalid> 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 <user-71895fb2e44c@xymon.invalid> wrote:


On Thu, May 26, 2016 at 4:44 AM L Foo <user-8a0f7702e6b1@xymon.invalid> 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 - user-46c89e614701@xymon.invalid
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
     `'
list Stef Coene · Wed, 1 Jun 2016 09:11:44 +0200 ·
▸ quoted from Ryan Novosielski
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
list Jeremy Laidman · Wed, 01 Jun 2016 09:08:00 +0000 · 
On Wed, Jun 1, 2016 at 7:10 AM L Foo <user-8a0f7702e6b1@xymon.invalid> wrote:

Thanks for ALL your valuable feedback!

I'm glad you sorted it out.
▸ quoted from Ryan Novosielski

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:
▸ quoted from Wonder fo

/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
list Jeremy Laidman · Wed, 01 Jun 2016 09:19:18 +0000 ·
▸ quoted from Stef Coene
On Wed, Jun 1, 2016 at 5:11 PM Stef Coene <user-dbffe946c0f4@xymon.invalid> 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
list Dirk Kastens · Wed, 1 Jun 2016 11:29:54 +0200 · 
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.
▸ quoted from Jeremy Laidman
    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
▸ quoted from Jeremy Laidman
a hostname is for it to be unique.  On the Internet, that generally
means FQDN.
Regards,
Dirk
list Ryan Novosielski · Wed, 1 Jun 2016 19:04:42 +0000 ·
▸ quoted from Jeremy Laidman
On Jun 1, 2016, at 5:08 AM, Jeremy Laidman <user-71895fb2e44c@xymon.invalid> wrote:

On Wed, Jun 1, 2016 at 7:10 AM L Foo <user-8a0f7702e6b1@xymon.invalid> 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).
▸ quoted from Ryan Novosielski

--
____
|| \\UTGERS,  	 |---------------------------*O*---------------------------
||_// the State	 |         Ryan Novosielski - user-46c89e614701@xymon.invalid
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
     `'
list Ryan Novosielski · Wed, 1 Jun 2016 19:51:43 +0000 · 
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.
▸ quoted from Dirk Kastens
On Jun 1, 2016, at 5:29 AM, Dirk Kastens <user-e4253f8fc63b@xymon.invalid> 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 - user-46c89e614701@xymon.invalid
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
     `'
list John Thurston · Wed, 01 Jun 2016 12:52:48 -0800 ·
▸ quoted from Stef Coene
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    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Wonder fo · Thu, 2 Jun 2016 12:46:41 -0500 · 
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 <user-46c89e614701@xymon.invalid>
▸ quoted from 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.

On May 31, 2016, at 5:10 PM, L Foo <user-8a0f7702e6b1@xymon.invalid> 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 <
user-71895fb2e44c@xymon.invalid> wrote:


On Thu, May 26, 2016 at 4:44 AM L Foo <user-8a0f7702e6b1@xymon.invalid> 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 - user-46c89e614701@xymon.invalid
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS
Campus
||  \\    of NJ  | Office of Advanced Research Computing - MSB C630, Newark
     `'