I think that might be influenced by whether they're prepackaged, or whether you're compiling yourself. Prepackaged, go with however the packages do it (probably separate). DIY, do what you want.
While it's possible to have each launched separately, it saves at least one process if the client is NOT launched separately on the server, but the server is configured to also launch its own client processes. As I read it, by default the server tasks.cfg launches the client processes for itself too. So that assumes that installing server also installs (ideally matching) client.
If you use the ability of the server to distribute client side updates, you need to prepare one tar bundle per OS/CPU architecture combo, compiled on the OLDEST representative OS version. I have both CentOS and Ubuntu happily using the same tar file; Solaris 10, 11.3, and 11.4 (x86) happily using their own, MacOS 10.6, 10.14, and 10.15 using one, and SPARC Solaris 9, 10, and 11.3 using one, all by in each case, building the tar bundle on the oldest for that OS/CPU architecture combo. And those go in the downloads directory, and client-local.cfg needs to define classes (and sometimes to define per-system overrides, I needed that with the Solaris SPARC vs x86, or was it that one dang SPARC Linux that had to be done separately I had in addition to two CentOS/x86-64 and one Ubuntu/ x86-64), with the tar file minus .tar identified as clientversion in client-local.cfg (server). It mostly works well; you just build the new tar bundles, put them in downloads on the server, and update the affected clientversion lines in clients-local.cfg. But if you get it wrong, it'll whack some of the clients by "updating" them to the wrong version; done that...now I think about it, it was the SPARC Linux that I had to fool with to keep that from happening.
One cool thing about having it distribute the updates and defining clientversion, is that the client version is shown, I think in the raw clientlog column at or near the bottom. So that serves as a reminder to keep them up to date. You do NOT have to keep them perfectly in sync with the server, it's harmless enough (give or take security updates!) if they're a bit different. For clients that are UP ONLY, the following script will retrieve that info if it exists (clientlog is not kept for those that are not up, so for those or clients that don't actually report but only are probed by server, the version will be blank):
#! /bin/bash
server=xymon.example.com # update this!
while read ip name junk do case "${ip}" in [0-9]*) vers="$(${HOME}/server/bin/xymoncmd ${HOME}/server/bin/xymon ${server} "clientlog ${name} section=clientversion"|fgrep -v '[clientversion]')" printf "%-15s %s\n" "${name}" "${vers}" ;; sac done <${HOME}/server/etc/hosts.cfg
IF there's a tag on all hosts of interest, xymongrep might be a better source for such a script than reading hosts.cfg directly, esp. if there are includes in hosts.cfg. QUESTION FOR THE MAINTAINERS: why isn't there an --all option for xymongrep, such that no tag is needed then (but other options like --no-down still apply)? That would make such a script clean, in that it wouldn't matter whether some one specific tag was on all hosts of interest.
On Sep 21, 2020, at 14:43, Gabby Gibbons via Xymon <xymon at xymon.com> wrote:
From: Gabby Gibbons <gabby.gibbons at yahoo.com> Subject: Converting a xymon client to a server Date: September 21, 2020 at 14:43:20 EDT To: "xymon at xymon.com" <xymon at xymon.com>
Hello,
I'm wondering if it is possible to convert a xymon client into a server? It seems like a server is just a client with an added on server directory which was making me wonder if this is possible? If not, what would be the best way, just uninstall the client and then reinstall as a server?
Thanks
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon