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 `'