Converting a xymon client to a server 🔗 link

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

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.

I note that xymongrep '*' will get anything with ANY tag. But it will not match a line with NO tags - I tried with a line like
0.0.0.0 bogus # 
vs
0.0.0.0 bogus # dork

and xymongrep '*' found the dork, but not the tagless one. :-)

(I quickly removed that after testing, so the server might not notice them, which it didn't, which saved cleaning up some mess)

A line with no tags is not perhaps a super likely thing, but not impossible. IMO, both an --all functionality (get everything, don't specify any tags) and a test negation functionality (like -v for regular grep) would both be handy.

Here's what I did to build the server - on Solaris 11 (SPARC, not that that matters); your details will vary a bit. On Solaris, the default "make" is NOT GNU make, although the latter is available as gmake; that's one thing that may vary; it'd just be "make" on Linux. pcre (perl style regular expression matching library) openssl, and openldap if you want it libraries and include files need to be installed. fping should be installed too, although I think one is included if you don't have it; remember to fix the path below if it's not in /usr/bin. I didn't actually need openldap support, but I may go crazy (for home, that'd be crazy) and set that up one day, so it's there if I want it then. The prerequisite libraries (if shared) need to be on BOTH build system and target server system, if they're not the same machine.

export MAKE=gmake
./configure --server --fping /usr/bin/fping --pcreinclude /usr/include/pcre --sslinclude /usr/include/openssl --ldapinclude /usr/include/openldap

I built my server ON the server system (in a build directory at the same level as the server directory); if you're not doing that, I suppose you could install it where you build it, and tar up the server directory and startup files and transfer the tar files to the system you want to make into the server. It might be more sensible to have two tar files, one for the startup files (which need to be right for the target distro, if that differs from the build system) with absolute paths, and one for the ~xymon/server directory, which should probably be relative to ~xymon (i.e. just be in ~xymon and tar up the server directory). The startup files have to be installed as root. You'd think the server files could be installed as xymon, but some directories have to have group id and group-writable for the web server, whatever it runs as, so you'll probably have to install them as root too. So either your xymon and web server UIDs and GIDs are the same on build and target server systems, or you'll have to fix up owner and group after untar-ing the files.

Then of course there's the question of setting up the web server process on the xymon server system, with the appropriate additions to a basic Apache (if that's what you're using) config. I'm NOT going to talk about that...except that it makes sense to me that the web server process should start BEFORE the xymon server process.

The rest below pertains to the client side.

If you use the tar files to distribute the client software (automatically after the first time a client is set up), among other things they should be relative to $XYMONCLIENTHOME; so if ~xymon is /export/home/xymon, then $XYMONCLIENTHOME is probably /export/home/xymon/client. A list of my tar file for Linux looks like:
./
./runclient.sh
./local/
./local/README
./tmp/
./ext/
./ext/volmgt
./ext/faults
./logs/
./bin/
./bin/xymonclient-freebsd.sh
./bin/xymonclient-sunos.sh
./bin/xymonclient-osf1.sh
./bin/logfetch
./bin/xymonclient-sco_sv.sh
./bin/xymon
./bin/xymonclient.sh
./bin/msgcache
./bin/xymonclient-linux.sh
./bin/xymoncfg
./bin/xymonlaunch
./bin/xymonclient-aix.sh
./bin/xymoncmd
./bin/orcaxymon
./bin/xymongrep
./bin/xymonclient-hp-ux.sh
./bin/xymonclient-unixware.sh
./bin/xymonclient-irix.sh
./bin/xymonclient-openbsd.sh
./bin/xymonclient-darwin.sh
./bin/xymonclient-netbsd.sh
./bin/xymondigest
./bin/clientupdate
./etc/
./etc/clientversion.cfg
./etc/clientlaunch.cfg
./etc/smartctl_disks.cfg
./etc/xymonclient.cfg
./etc/localclient.cfg

That means if doing it by hand the first time, you want to do (as xymon):

mkdir -p ~/client
cd ~/client
tar xvf ../OS_CPU_xymonVersion_updateversion.tar

I named the tar files something like that to keep them straight, with all the different OS and CPU combos I had; the updateversion part is if I update the tar file say to include a changed ext script, without actually compiling a new version of xymon client. If you do the autoupdate, remember the matching clientversion for a client (in client-local.cfg on the server) has to be the same as the tar file name minus .tar suffix.

Note that I had some client side ext scripts; those were included. I created the tar files with logs and tmp directories cleaned out, which is a good idea.

Remember what I said, build client software on the client with the OLDEST OS version for a given OS and CPU architecture; most OS's are backwards compatible enough that the older code should run fine on the newer version of the same OS, but code built on a newer OS will usually NOT run on an older one. Of course if you have different OSs (usually different Linux distributions are ok as the same OS) or different CPU architectures (x86 32-bit, x86/64 only, SPARC, ARM, whatever), you need to build for each OS/CPU combination on the oldest OS version.

On Sep 22, 2020, at 08:39, Gabby Gibbons <user-920f9e87cd7f@xymon.invalid> wrote:
 
So, I am trying to build from source, but basically what I want to do is distribute a pre-installed xymon to multiple computers on a network, and then for the single computer that should be the server I want to be able to write a script to install the extra, server unique, packages. Can I just rerun the configure script and specify server instead and then use make to rebuild? I'm not all that familiar with building packages from source.