Cross compilation 🔗 link

Hi,

Will someone please give me pointers for how I can cross compile Xymon client?

I've got some old AIX 5.3 systems that I'm using a hack to run the xymonclient-aix.sh (from memory) and piping that into a script that prefixes it with a header and connects to port 1984 of the Xymon server.

I'd like to some client version of Xymon or older Hobbit compiled for AIX 5.3.

I'm mostly after the xymonlaunch / hobbitlaunch binary for AIX 5.3.  I think the bulk of the data comes from the xymonclient-aix.sh script. But I'd like to start leveraging log file monitoring, which seems to need the *launch binary.

Thank you and have a good day.


-- 
Grant. . . .

Hi Grant

The log monitoring only requires the logfetch binary, which does three
things: fetch the logs since the last time (and keep track of log file
position), fetch file/dir status (permissions, ownership, hash if
configured), and get the date and time of the client. You don't need
xymonlaunch for monitoring logs. Although, if running in central mode, you
do need to capture the output of the xymon command that sends the client
data message to the server, and save it to a file, because that's the
config file for logfetch.

I re-implemented the logfetch behaviour in my xymon-rcient.sh script (see
Xymonton), consisting of about 3 functions and a bit of wrapper code, so
it's possible to do without the binary if that option seems useful.

Alternatives for xymonlaunch are:
- run xymonclient.sh from cron (perhaps via flock, or similar behaviour to
ensure you don't ever get a backlog of client instantiations consuming
system resources)
- run via ssh from Xymon server to client, like:

TMP=`mktemp`; echo "$MACHINE.$OSTYPE" > "$TMP" && ssh $MACHINE
~xymon/client/bin/xymonclient.sh && $XYMON 127.1 @ < "$TMP" >/dev/null; rm
-f "$TMP"

(untested; also could do with flock or similar)

This can be run from a script launched by xymonlaunch on the Xymon server,
rather than requiring a launcher on the client.

Cheers
Jeremy


On Sun, 2 Jun 2024 at 09:05, Grant Taylor via Xymon <xymon at xymon.com> wrote:

---------- Forwarded message ----------
From: Grant Taylor <user-86150bc7e4bb@xymon.invalid>
To: Xymon discuss <xymon at xymon.com>
Cc:
Bcc:
Date: Sat, 1 Jun 2024 17:55:09 -0500
Subject: Cross compilation

---------- Forwarded message ----------
From: Grant Taylor via Xymon <xymon at xymon.com>
To: Xymon discuss <xymon at xymon.com>
Cc:
Bcc:
Date: Sat, 1 Jun 2024 17:55:09 -0500
Subject: [Xymon] Cross compilation

On 6/2/24 18:11, Jeremy Laidman wrote:

Hi Grant

Hi Jeremy,

Thank you for your reply.

The log monitoring only requires the logfetch binary, which does three things: fetch the logs since the last time (and keep track of log file position), fetch file/dir status (permissions, ownership, hash if configured), and get the date and time of the client. You don't need xymonlaunch for monitoring logs.

Thank you for clarifying.

I hadn't noticed the lack of date and time.

Although, if running in central mode, you do need to capture the output of the xymon command that sends the client data message to the server, and save it to a file, because that's the config file for logfetch.

Please elaborate.

I re-implemented the logfetch behaviour in my xymon-rcient.sh script (see Xymonton), consisting of about 3 functions and a bit of wrapper code, so it's possible to do without the binary if that option seems useful.

I'll have to check that out.

That's what I'm doing currently.

That's largely a non-starter for my particular environment for multiple reasons.

(untested; also could do with flock or similar)

;-)

The logic makes sense to me.

This can be run from a script launched by xymonlaunch on the Xymon server, rather than requiring a launcher on the client.

So ...

Will someone please give me pointers for how I can cross compile Xymon client^W logfetch binary?


-- 
Grant. . . .

Grant

Sorry, I'm not a developer, so I can't help you with cross-compiling. Best
of luck with that!

You may have already solved this issue, but if you're doing client->server
comms to send client messages, you would typically need the "xymon" binary
to run on the client host, for sending the client message to the Xymon
server. There are alternative ways to do this, such as using netcat
(example below), or a short perl script, or even telnet (see the Xymon Tips
<https://xymon.sourceforge.io/xymon/help/xymon-tips.html#noinstall>; page
for more on this).

As far as I can tell, the date and time in the client message is only used
in the CPU test to report when the system clock is significantly different
from that on the Xymon server. If this is not important to you (eg if you
have an alternative check for this) then you can do without the date and
time. But if you need message monitoring, you can't easily do without the
thing that gives the time and date anyway, so this isn't all that helpful
to you.

To elaborate on the capturing of Xymon client output for central mode, the
client can run in either local mode (if run with "--local" as the first
parameter) or central mode (the default). In client mode, it gets its
configuration from the localclient.cfg file stored on the client. In
central mode, it gets its configuration from the server, as a post-script
to the transmission of the client data. In central mode, when
xymonclient.sh sends a "client" type message to the Xymon server, the
server fetches any relevant sections from its own clientlocal.cfg file that
are appropriate for the client (ie matching the OS type, class, and
hostname). For example, if I have a Linux Xymon client machine called
x-client.example.com, and in clientlocal.cfg (on the Xymon server) I have:

[linux]
log:/var/log/messages:10240
[x-client.example.com]
# my Linux box
dir:/usr/local/some-app

Then if I run (typically by xymonclient.sh) this command:

$XYMON $XYMSRV "client x-client.example.com.linux linux"

or even something like:

echo "client x-client.example.com.linux linux" | netcat xymon-server 1984

then not only will this send a client message to the server (in this case
an empty one) but it will also output this:

log:/var/log/messages:10240
# my Linux box
dir:/usr/local/some-app

(note that even the comments in clientlocal.cfg are included)

The xymonclient.sh script grabs this output and sends it to a file in
$XYMONTMP called "logfetch.$MACHINEDOTS.cfg". Every time a client message
is sent, this file is updated. This file becomes the configuration file for
logfetch, and is used on the next execution of xymonclient.sh.

The xymon client and the netcat equivalent shown above produce these
snippets from clientlocal.cfg for the logfetch config file, but only
because they wait for remote data transmission after closing the local end
of the socket. If using a telnet-based replacement for the Xymon client,
you won't see the snippets, so this can't be used to configure the logfetch
binary.

If you want to run in central mode, you can discard the output of the xymon
command that sends the client message, and just hard-code whatever settings
you want in the client system's localclient.cfg file.

Hope this explainifies this sufficiently for you.

It should be noted that the logfetch binary will execute anything in
backticks in a file: or log: entry that comes from the Xymon server. This
provides a way for someone with write access to the xymonclient.cfg file on
the Xymon server to execute arbitrary code on any and all Xymon clients.
This presents a security risk, and as such, running logfetch in local mode
may be preferable, or run with the "--noexec" option. For some situations,
running logfetch at all is too much of a risk, and the loss of logfile
monitoring is an acceptable cost.

Cheers
Jeremy

On Tue, 4 Jun 2024 at 10:01, Grant Taylor via Xymon <xymon at xymon.com> wrote:

Date: Mon, 3 Jun 2024 18:59:17 -0500
Subject: Re: [Xymon] Cross compilation

;-)

Date: Mon, 3 Jun 2024 18:59:17 -0500
Subject: Re: [Xymon] Cross compilation