- Xymon - Xymon mailman web

web page sounds
by kspringer＠innovateteam.com 12 Jan '22

12 Jan '22

Google it. Browsers have been blocking sounds for a while now. You're gonna have to use different code. The old ea sy ways don't work anymore. -----Original Message----- From: "White, Tracey via Xymon" <xymon at xymon.com> Reply-To: "White, Tracey" <White-Tracey at aramark.com> To: xymon at xymon.com <xymon at xymon.com> Subject: [Xymon] web page sounds Date: Wed, 12 Jan 2022 14:14:06 +0000 _______________________________________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

1 0

web page sounds
by White-Tracey＠aramark.com 12 Jan '22

12 Jan '22

I have the web page configured so there is a sound when an alert is triggered. This has worked fine in I.E. for years. The sound does not work with Firefox or Edge. This is the code I have. Has anyone seen this and know how to get the sounds to work in other web browsers other than I.E. <audio autoplay id="bgsound"> <source src="&XYMONSKIN/../sounds/&XYMWEBBACKGROUND.wav" type="audio/wav"> </audio>

1 0

$XYMONSERVERS vs $XYMONSERVER: Typo in xymongrep(1) man page?
by abe＠deuxchevaux.org 10 Jan '22

10 Jan '22

Hi, I just noticed that while everywhere $XYMONSERVERS (plural, with an "S" at the end) is used as variable, the xymongrep(1) man page refers to a $XYMONSERVER variable (without trailing "S"): --loadhostsfromxymond xymongrep will normally attempt to load the HOSTSCFG file by itself when searching for lines to transmit. If the file is unreadable, it will exit out. With this option, it will query the xymond server (set via the XYMONSERVER environment) for the hosts file. This can be used if you're running this on a client or remote system and can't or don't want to have the hosts.cfg file synchronized across your servers. I assume this is a typo, right? Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/

2 1

[patch] honour client hostname from /etc/default/xymon-client
by zechner＠vrvis.at 23 Dec '21

23 Dec '21

Hi, I've encountered a rather annoying bug when using local mode on clients on Debian [1], but I am sure it's also a problem on other Linux distros. When the machine is set to LOCALMODE="yes" in /etc/xymon/xymonclient.cfg, it stops using the hostname provided by /etc/default/xymon-client set via CLIENTHOSTNAME= there and instead uses "hostname -f". It does this because in the Debian init script it checks for a variable called MACHINEDOTS (which only exists on xymon servers, not clients) and uses "hostname -f" as a fallback. In my opinion, a client in local mode should still honour the client hostname set in the /etc/default/xymon-client file, so I propose the following change in xymonclient.cfg: --- A 2021-12-23 13:34:11.000000000 +0100 +++ B 2021-12-23 13:44:37.024340994 +0100 @@ -42,6 +42,8 @@ # Local options for xymond_client (Ignored when not in local mode) LOCAL_CLIENTOPTS="" +# honour hostname set in /etc/default/xymon-client +MACHINEDOTS=$CLIENTHOSTNAME # Compatibility settings HOBBITCLIENTHOME="$XYMONCLIENTHOME" Setting the MACHINEDOTS variable like this ensures it still uses the one defined in /etc/default/xymon-client thus behaving like expected. Please let me know if this solution is acceptable for you or if we should resolve this matter in another way. Thanks in advance! Best regards Christoph Zechner [1] OS: Debian 10/11 stable

1 0

Apache log4j2 vulnerability
by malcolm.r.hunter＠gmail.com 13 Dec '21

13 Dec '21

Not unless you have a 3rd party agent running it. On Mon, 13 Dec 2021 at 17:07, White, Tracey via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: "White, Tracey" <White-Tracey at aramark.com> > To: "xymon at xymon.com" <xymon at xymon.com> > Cc: > Bcc: > Date: Mon, 13 Dec 2021 17:06:34 +0000 > Subject: Apache log4j2 vulnerability > > Does anyone know if Xymon is effected Apache log4j2 vulnerability CVE-2021-44228? > > > > > > > > ---------- Forwarded message ---------- > From: "White, Tracey via Xymon" <xymon at xymon.com> > To: "xymon at xymon.com" <xymon at xymon.com> > Cc: > Bcc: > Date: Mon, 13 Dec 2021 17:06:34 +0000 > Subject: [Xymon] Apache log4j2 vulnerability > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

1 0

Apache log4j2 vulnerability
by White-Tracey＠aramark.com 13 Dec '21

13 Dec '21

Does anyone know if Xymon is effected Apache log4j2 vulnerability CVE-2021-44228?

1 0

Wrong interfaces in if_load test
by colin.coe＠gmail.com 05 Dec '21

05 Dec '21

Hey all Running Xymon (Teribithia) v4.3.30 along with DEVMON. Recently we've found that RRD files are present for completely wrong interfaces for many devices polled by DEVMON. For example, I'm seeing if_load.StackPort1.rrd files for 110 devices we only have two stacks. Even some routers have this rrd file present. Has anyone else seen this. Happy to provide more info. Thanks

2 2

Xymond Oversize data/client on Xymon 4.3.30
by tp6891＠att.com 25 Nov '21

25 Nov '21

Hi, I am running Xymon 4.3.30 on Redhat 7.9 and I still get "Oversize data/client msg" under xymond and xymond.log. I have followed the advicean MAN page to modify the xymonserver.cfg file with no luck. I have increased MAXMSG_CLIENT, MAX, MSG_STATUS MAXMSG_USER & MAXMSG_DATA. Any ideas or am I missing something? Error: Oversize data/client msg from x.x.x.x truncated (n=894639, limit 524288) First line: somehost.mynetwork.com|sunos|sunos| xymonserver.cfg MAXMSG_CLIENT=1024 # clientdata messages (default=512k) MAXMSG_CLICHG=$MAXMSG_CLIENT # client change messages (default=MAXMSG_CLIENT) MAXMSG_STATUS=1024 # general "status" messages (default=256k) MAXMSG_STACHG=$MAXMSG_STATUS # status change messages (default=MAXMSG_STATUS) MAXMSG_PAGE=$MAXMSG_STATUS # page messages (default=MAXMSG_STATUS) #MAXMSG_ENADIS=1024 # enable and disable control messages (default=32k) MAXMSG_USER=1024 # "user" messages (default=128k) MAXMSG_DATA=1024 # "data" messages, if enabled (default=256k) #MAXMSG_NOTES=256 # "notes" messages, if enabled (default=256k Tim

4 4

4.3.30 core dumps with directory directive in hosts.cfg
by zak.beck＠accenture.com 03 Nov '21

03 Nov '21

Hi I?m using 4.3.30 and I?m experiencing core dumps on some servers using the directory directive in hosts.cfg. The contents of my directory sometimes change and this sometimes leads to a core dump. In hosts.cfg I have: directory /home/xymon/server/etc/include_xxxxx/xxxxx/ this directory contains one file per host which contain something like this: 0.0.0.0 a_unique_name # noconn NOCOLUMNS:conn,info,trends nonongreen A cron job adds/removes files from this directory periodically, however, the directory should contain at least one file at all times. It?s been a long time since I did any C but I think I?ve been able to track this down a bit with gdb and --debug on xymond. Here?s some xymond debug output: 5315 2021-11-03 12:08:45.037113 File /home/xymon/server/etc/include_xxxxx/xxxxx//xxxxxxxxx new timestamp 16223 2021-11-03 12:08:45.037136 -> save_checkpoint 5315 2021-11-03 12:08:45.037218 Opening file /home/xymon/server/etc/hosts.cfg 5315 2021-11-03 12:08:45.040573 Opening file /home/xymon/server/etc/include_xxxxx/xxxxx//xxxxxxxxxx .. (opens all the files) 5315 2021-11-03 12:08:45.047109 -> handle_dropnrename 5315 2021-11-03 12:08:45.047128 -> posttochannel 5315 2021-11-03 12:08:45.047144 Posting message 13651 to 1 readers 5315 2021-11-03 12:08:45.047155 <- posttochannel 5315 2021-11-03 12:08:45.047159 -> posttochannel 5315 2021-11-03 12:08:45.047168 Posting message 4683 to 1 readers 5315 2021-11-03 12:08:45.047176 <- posttochannel 5315 2021-11-03 12:08:45.047179 -> posttochannel 5315 2021-11-03 12:08:45.047188 Posting message 1367 to 1 readers 5315 2021-11-03 12:08:45.047195 <- posttochannel 5315 2021-11-03 12:08:45.047199 -> posttochannel 5315 2021-11-03 12:08:45.047207 Posting message 1905 to 1 readers 5315 2021-11-03 12:08:45.047214 <- posttochannel 5315 2021-11-03 12:08:45.047218 -> posttochannel 5315 2021-11-03 12:08:45.047221 Dropping message - no readers 5315 2021-11-03 12:08:45.047225 -> posttochannel 5315 2021-11-03 12:08:45.047228 Dropping message - no readers 5315 2021-11-03 12:08:45.047232 -> posttochannel 5315 2021-11-03 12:08:45.047240 Posting message 785 to 1 readers 5315 2021-11-03 12:08:45.047247 <- posttochannel 5315 2021-11-03 12:08:45.047251 -> posttochannel 5315 2021-11-03 12:08:45.047259 Posting message 6 to 1 readers 5315 2021-11-03 12:08:45.047266 <- posttochannel 5315 2021-11-03 12:08:45.047269 -> posttochannel 5315 2021-11-03 12:08:45.047273 Dropping message - no readers 5315 2021-11-03 12:08:45.047287 -> free_log_t 5315 2021-11-03 12:08:45.047300 <- free_log_t 5315 2021-11-03 12:08:45.047308 <- handle_dropnrename 5315 2021-11-03 12:08:45.047312 -> handle_dropnrename 16223 2021-11-03 12:08:45.240284 <- save_checkpoint 2021-11-03 12:09:00.061085 Whoops ! Failed to send message (timeout) 2021-11-03 12:09:00.061303 -> On the last handle_dropnrename, the core dump occurs: Program terminated with signal 6, Aborted. #0 0x00007f39f751e387 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55 55 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00007f39f751e387 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007f39f751fa78 in __GI_abort () at abort.c:90 #2 0x0000000000415f63 in sigsegv_handler (signum=<optimized out>) at sig.c:57 #3 <signal handler called> #4 __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38 #5 0x000000000040a5ac in handle_dropnrename (cmd=cmd at entry=CMD_DROPSTATE, sender=sender at entry=0x425e3c "xymond", hostname=0x0, n1=n1 at entry=0x0, n2=n2 at entry=0x0) at xymond.c:2511 #6 0x0000000000403eb1 in main (argc=<optimized out>, argv=<optimized out>) at xymond.c:5702 What is interesting is that handle_dropnrename appears to be passed an empty hostname or null pointer if I understand gdb correctly. In handle_dropnrename strlen is called on hostname and I think this causes the core dump? (xymond.c line 2511): char *msgbuf = (char *)malloc(20 + strlen(hostname) + (n1 ? strlen(n1) : 0) + (n2 ? strlen(n2) : 0)) I _think_ handle_dropnrename is being called around line 5700 of xymond.c: else if (hostinfo(hwalk->hostname) == NULL) { /* Remove all state info about this host. This will NOT remove files. */ handle_dropnrename(CMD_DROPSTATE, "xymond", hwalk->hostname, NULL, NULL); What am I doing wrong ? Thanks Zak ________________________________ 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 0

smtp test - how/what does it actually do?
by jeremy＠laidman.org 28 Oct '21

28 Oct '21

Ian On Thu, 28 Oct 2021 at 23:08, Ian Diddams via Xymon <xymon at xymon.com> wrote: > > we ahve a client configured thus > > 10.108.249.162 colt # ssh ntp MAINTNC:linux smtp > > This smtp c > heck has been green for ever - literally. It has suddenly alerted > overnight and is remaining so > > > Service smtp on colt is not OK : Service listening but unavailable > (connect timeout) > Seconds: 0.001814000 > > "listening" means it's accepting TCP connections. > I can telnet from the xymon server on port 25 fine. > "connect timeout" means xymonnet was waiting for something that didn't come in time. I wonder if you have an "expect" string in the [smtp] section of protocols.cfg, causing xymonnet to wait for a string containing "220" but that never arrives. postfix services on colt are working seemingly correctly (eg i can send a > mail successfully from a client that uses colt as a smtp server) > > So Im now trying to find out what it is that this smtp check atually does > in order to find out why it now thinks it cant do it. > > The error suggests indeed its a timeout issue - but the telnet test > connects immeditaely (no obvious lag anyway) > > thoughts/ > > ian > Maybe check your Postfix logs to see if something is happening there. Have you upgraded/reconfigured Postfix recently? In some configurations, Postfix has been known to reject "pipelining" which is sending multiple commands (eg "mail" and then "quit") without waiting for a response after each command. When this happens, Postfix rejects the command, but doesn't send a "220" nor does it close the connection. Or it might be as simple as your Xymon server being removed from Postfix's allowed senders lists. Here's the [smtp] section from the standard protocols.cfg: [smtp] send "mail\r\nquit\r\n" expect "220" options banner port 25 Compare with yours. You could do a packet capture to see what the dialog looks like, and compare it to the send/expect in protocols.cfg. You could try simulating the "send" string from protocols.cfg (after telnetting to port 25) and see if you get a 220 response. You could comment out the expect string in protocols.cfg and see if it starts working. You could take a look at (and perhaps even share here) the banner displayed in the smtp check status page, as that might give a clue as to what's not right. I seem to recall a discussion about SMTP pipelining on this list, only a few weeks ago. Perhaps re-read that discussion to see if there are any nuggets of wisdom that could help. Cheers Jeremy

1 0