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:
---------- Forwarded message ---------- From: Grant Taylor <gtaylor at tnetconsulting.net> To: xymon at xymon.com Cc: Bcc: Date: Mon, 3 Jun 2024 18:59:17 -0500 Subject: Re: [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.
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)
That's what I'm doing currently.
- 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"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. . . .
---------- Forwarded message ---------- From: Grant Taylor via Xymon <xymon at xymon.com> To: xymon at xymon.com Cc: Bcc: Date: Mon, 3 Jun 2024 18:59:17 -0500 Subject: Re: [Xymon] Cross compilation
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
participants (1)
-
jeremy＠laidman.org