- Xymon - Xymon mailman web

Converting a xymon client to a server
by rlhamil2＠gmail.com 22 Sep '20

22 Sep '20

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 <gabby.gibbons at yahoo.com> 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.

1 0

Converting a xymon client to a server
by rlhamil2＠gmail.com 22 Sep '20

22 Sep '20

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

1 1

Converting a xymon client to a server
by gabby.gibbons＠yahoo.com 21 Sep '20

21 Sep '20

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

1 0

Weird problem with PORTS and PROCS false positives
by rodrigoborgespereira＠gmail.com 21 Sep '20

21 Sep '20

Hello, I'm finding that on occasion Xymon issues false positives for PORTS or PROCS. On closer inspection, it's possible to identify in those alerts that the recorded client data is correct, containing the netstat and ps listings with the expected ports and processes. However, Xymon will still alert. When this happens, it will happen for a bunch of hosts at the same time. There's no specific pattern. It's not very frequent (maybe twice a week), but enough to be annoying, as it can affect a few dozens of hosts. Given that the client data seems complete, it doesn't seem to be a buffer issue (at least not a configurable one), so I'm at a loss at what may be the issue here. Also, there's been no version change, (still) running 4.3.27, or any other major change to the system (it's a CentOS 7 VM). I welcome any hints/speculations about what could be causing this! Thanks everyone.

1 0

Making xymon.html update more frequently
by john.thurston＠alaska.gov 18 Sep '20

18 Sep '20

On 9/18/2020 4:51 AM, Eric Robert via Xymon wrote: > II've noticed that sometimes I can click into a test and see that the > status is something different than what is showing on the front page > (xymon.html). The front page can take over a minute to update even if I > can manually see that the status has changed already. Is there any way > to make that front page update more frequently? Xymon is not of this century. It works like a web app from the '90s, by batch updates. Hit F5 all you want, and it still won't affect the contents of the web page. If you want the contents of that page to update more frequently, you need to run xymongen more frequently. Look in your tasks.cfg and change the INTERVAL on xymongen -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska

1 0

Making xymon.html update more frequently
by erobertt30＠yahoo.com 18 Sep '20

18 Sep '20

Hello, II've noticed that sometimes I can click into a test and see that the status is something different than what is showing on the front page (xymon.html). The front page can take over a minute to update even if I can manually see that the status has changed already. Is there any way to make that front page update more frequently?

1 0

semop failed, Invalid argument - Ubuntu
by zak.beck＠accenture.com 17 Sep '20

17 Sep '20

Hi Sorry for resurrecting this but I get this periodically too and it's really annoying ? 2020-09-17 01:45:23.945832 semop failed, Invalid argument 2020-09-17 01:45:23.945839 Dropping message due to semaphore error One particular server just started doing this about 10 days having not done it for months. It's Ubuntu 16.04 LTS, 4.4.0-189-generic, x64. I have other Ubuntu 16.04 servers where it does not happen or at least, has not happened recently. I turned on debug logging but I'm not too familiar with the server code so it doesn't really say much to me. Here are the additional debug entries: 18723 2020-09-17 01:45:23.945758 Beginning conn_t cleanup 18723 2020-09-17 01:45:23.945762 conn_t cleanup complete 18723 2020-09-17 01:45:23.945783 -> do_message/1 (362 bytes): status+60m awdhrprtldb5.sessions clear Thu Sep 17 01:45:23 MDT 2020 18723 2020-09-17 01:45:23.945790 -> update_statistics 18723 2020-09-17 01:45:23.945793 <- update_statistics 18723 2020-09-17 01:45:23.945797 -> get_hts 18723 2020-09-17 01:45:23.945809 <- get_hts 18723 2020-09-17 01:45:23.945813 ->handle_status 18723 2020-09-17 01:45:23.945818 posting to status channel 18723 2020-09-17 01:45:23.945823 -> posttochannel 2020-09-17 01:45:23.945832 semop failed, Invalid argument 2020-09-17 01:45:23.945839 Dropping message due to semaphore error 18723 2020-09-17 01:45:23.945844 <-handle_status 18723 2020-09-17 01:45:23.945864 <- do_message/1 Xymond eventually falls over and needs restarting. Can anyone help me with this - I can't be the only one with it! Zak Beck -----Original Message----- From: Xymon <xymon-bounces at xymon.com> On Behalf Of John Horne Sent: 12 November 2019 19:22 To: xymon at xymon.com Subject: [External] Re: [Xymon] semop failed, Invalid argument This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments. On Tue, 2019-11-12 at 17:03 +0000, Rothlisberger, John R. via Xymon wrote: > > Does anyone have any helpful ideas? > ... > > 2019-11-01 11:45:07.083973 semop failed, Invalid argument > 2019-11-01 11:45:07.083982 Dropping message due to semaphore error > Not really I'm afraid. The actual error is the invalid argument bit. It refers to a call to 'semop'. A very quick look at the xymond code seems to indicate that it would be the semaphore id that it is objecting to - basically it doesn't exist or the id is less than zero. How that came about though, I have no idea. It may be that the code is being called when it shouldn't be - perhaps a lack of argument checking. It would require much further checking of the code to see what is happening. Maybe running xymond is debug mode will give more information. John. -- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK ________________________________ [https://urldefense.proofpoint.com/v2/url?u=http-3A__www.plymouth.ac.uk_imag… ]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.plymouth.ac.uk_worl… <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.plymouth.ac.uk_worl…> > This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form. _______________________________________________ Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.xymon.com_mailman… ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy. ______________________________________________________________________________________ www.accenture.com

1 1

Adding a description to custom columns
by Eric.Robert＠americansystems.com 16 Sep '20

16 Sep '20

Hello, I was wondering if it is possible to add a description to custom columns in Xymon? I want it to be like the default columns where you click on the name and it shows you a description. It looks like by default when you click on the name of a custom column a page comes up that just says "No match". Eric Robert Info Security Engr, Assoc AMERICAN SYSTEMS phone: +1 (401) 619-7331 | mobile: | fax: Eric.Robert at americansystems.com | AmericanSystems.com LEGAL DISCLAIMER: The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited and may be unlawful.

4 3

Xymon client on MacOS Catalina (10.15)
by Brian.Scott＠bunyatech.com.au 05 Sep '20

05 Sep '20

Hi list, Has anyone had experience with running the xymon client on the latest Macos? My particular problem is that the handling of disk mounts and capacities has gone seriously weird. First exhibit - output from the mount command: # mount /dev/disk1s1 on / (apfs, local, read-only, journaled) devfs on /dev (devfs, local, nobrowse) /dev/disk1s2 on /System/Volumes/Data (apfs, local, journaled, nobrowse) /dev/disk1s5 on /private/var/vm (apfs, local, journaled, nobrowse) map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse) All volumes are either marked nobrowse or read-only so no disks are selected by xymonclient-darwin.sh. This has the immediate kick on effect of causing a bash set command to dump all set variables because the filesystem list is empty. Ignoring this because we actually want to select some filesystems, the question is which ones. Looking at the output from df: # df -P -H Filesystem????? Size?? Used? Avail Capacity? Mounted on /dev/disk1s1??? 1.0T??? 11G??? 92G??? 11%??? / devfs?????????? 345k?? 345k???? 0B?? 100%??? /dev /dev/disk1s2??? 1.0T?? 893G??? 92G??? 91%??? /System/Volumes/Data /dev/disk1s5??? 1.0T?? 3.2G??? 92G???? 4%??? /private/var/vm map auto_home???? 0B???? 0B???? 0B?? 100%??? /System/Volumes/Data/home It looks like /dev/disk1s1, s2 and s5 are all the same real partition but account for different space from it, i.e. total size = 1.0T, Used = 11G+893G+3.2G=907.2G, Avail=92G. This would suggest that a reasonable thing to monitor would be one of these entries ('/' makes some sense) and derive used as size-avail (1.0T-92G). This then falls down when I plug an extra disk in (in this case a FAT32 USB drive) adding: /dev/disk2s1 on /Volumes/NO NAME (msdos, local, nodev, nosuid, noowners) and /dev/disk2s1???? 15G?? 137M??? 15G???? 1%??? /Volumes/NO NAME Which looks a lot more like conventional drives on a normal unix-style system. Fortunately (?) for me, the server I'm trying to monitor only has a single disk so this isn't a further complicating issue. Has anyone already done anything to make sense of all this in a modified version of xymonclient-darwin.sh? Is there a cutoff point in macos versions where the existing script was good and a new one is needed? I haven't had to deal with a Mac server before so haven't particularly cared about what xymon made of it until now. Cheers, stay safe, Brian Scott

2 2

Renaming default columns
by Eric.Robert＠americansystems.com 04 Sep '20

04 Sep '20

Hi, I was wondering if it is at all possible to rename the default column names in Xymon? I would like to make some of the names more descriptive if possible. Eric Robert Info Security Engr, Assoc AMERICAN SYSTEMS phone: +1 (401) 619-7331 | mobile: | fax: Eric.Robert at americansystems.com | AmericanSystems.com LEGAL DISCLAIMER: The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited and may be unlawful.

3 2