December 2023 - Xymon - Xymon mailman web

Possible bug in xymon svcstatus causing segfault (buffer overrun?)
by jeremy＠laidman.org 31 May '24

31 May '24

Hi all I'm not a C programmer by any stretch, so I'm seeking confirmation that my working is sound. At our site we run 4.3.30-1 from Terabithia RPM. For most hosts, the "trends" page displays just fine, but for some hosts, the webserver gives a CGI error, and when I manually run the CGI directly it crashes with a seg fault. This seems to be more likely for hosts with a lot of entries on the trends page, but some with more trends graphs are OK than others with fewer. I believe I've tracked the issue down to the last few lines of code in svcstatus-trends.c, where a URL is constructed for one graph entry, before being added to the list of trends in a buffer. My reading of the code suggests that it first pre-allocates (using malloc()) a 16k buffer for the trends data, then sequentially appends trend strings (which include a URL) into the buffer, until the length of a string would exceed the size of the buffer. In that case, an extra 4k of memory is added to the buffer (using realloc()), and then the string is added to the buffer. The problem with the code, as I see it, is that the string might be more than 4k long, in which case, adding string would cause a buffer overrun. I don't really know what's in each string, so I don't know if it's ever likely to be 4k, but we're seeing the process dumping core immediately after this bit of code, so that's the suspicion. Here's the bit of code, which is attempting to add the string "onelink" to the buffer, after seeing if it's going to exceed the buffer, and extending the buffer if required: if ((buflen + strlen(onelink)) >= allrrdlinks_buflen) { SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+4096); allrrdlinksend = allrrdlinks + buflen; } allrrdlinksend += snprintf(allrrdlinksend, (allrrdlinks_buflen - (allrrdlinksend - allrrdlinks)), "%s", onelink); Elsewhere in other code, the SBUF_REALLOC macro is used to add extra bufferspace by calculating a new buffer size of [existing buffer size plus 4k plus the length of the string being added]. So if the string to be added had 20 bytes, SBUF_REALLOC would be used to add 4k+20 bytes to the buffer size. Notably, the size of the string is included in the calculation. For example this bit of code elsewhere in the same file does a similar buffer extension: if ((strlen(rrdlink) + strlen(partlink) + 1) >= rrdlink_buflen) { SBUF_REALLOC(rrdlink, rrdlink_buflen + strlen(partlink) + 4096); } strncat(rrdlink, partlink, (rrdlink_buflen - strlen(rrdlink))); Note the extra "+ strlen(<stringvar>)" bit in the extra memory being allocated that isn't there in the first block of code above. So my thinking is that the SBUF_REALLOC() needs to take the string's size into account, like so: SBUF_REALLOC(allrrdlinks, allrrdlinks_buflen+strlen(onelink)+4096); Is anyone with C skills able to confirm that this does indeed look like a bug, and also that my proposed change is a suitable fix? After applying this change and recompiling, we haven't yet seen a seg fault from this bit of code, so I'm hoping it's all fixed, and without negative side effects. Cheers Jeremy

3 3

Update on 4.4 (Alpha1 release)
by tom＠4schmidts.com 15 May '24

15 May '24

J.C., Thank you again J.C. for reviving the updates for Xymon. I am willing to help update it as well, even though I am now retired and only have a small install of Xymon 4.3.30 at home for my home network. I have contributed to Xymon several times in the past when I had it installed in a large corporate environment before I retired. J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux 8.8 (server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings. I have not fully tested 4.4-alpha1 yet, but wanted to get these first patches released for 4.4-alpha2. Tom Schmidt On Wed, Sep 20, 2023 at 2:38?PM J.C. Cleaver <cleaver at terabithia.org> wrote: > Hello all! Just wanted to update everyone on a few things. > > Going through the 4.x codebase re-familiarizing myself again with the > state of everything, I recalled that I'd actually built a release artifact > before development was paused, including a testing RPM that has actually > been running unbeknownst on a VM for quite a while. Unfortunately, while > validating that compiles from source worked I ran into what looked like > showstopper bugs. These weren't showing up in the package, so I had to > pore through a lot more code* than I expected to try to figure out where > the package was accidentally fixing it. > > (*message-sending code, which changes a lot in 4.4 to support compression, > TLS, HTTP, and size-prefixed messages) > > Fortunately, it ended up being a relatively simple issue (isn't it > always?), with easy-enough validation and workaround (given below). > Although more fixes could be put in (and I'm sure will be needed!), I > believe there's some benefit to having a stable starting point using a > build artifact from 2019. > > As a result, I'm pleased to announce the first alpha for Xymon 4.4! As > this is an alpha release, this is absolutely NOT suitable for production > use and is intended mainly for smoketesting by source users. (And I expect > there will be smoke.) The release tarball is available now at: > > > https://sourceforge.net/projects/xymon/files/Xymon/4.4-alpha/xymon-4.4-alph… > > > Major improvements are too many to list here but are noted in the Changes > and RELEASENOTES files. README documents for compression, TLS, and IPv6 > are in progress. > > Some of the changes and improvements other than TLS support have been in > the Terabithia packages (to some extent) for a while, so there will be > less of a delta for those users to this alpha. > > For the moment, I'd like to focus on source tarball users and others > running xymon from scratch to help fix underlying issues and any smoketest > failures, which I expect may crop up particularly on untested non-Linux > platforms. Once the lower-hanging fruit is fixed and more patches are > upstreamed and cleaned up, I'll release an alpha2 release at which point > packages may be released to help with testing iteration and downstream > distributors. > > Please flag bug reports or patches as related to "alpha1" in the subject > line to help keep things clear. > > > Thank you to everyone in the community for remaining part of it -- and > xymon users! -- during this interregnum. Restarting development has been a > process, but I'm glad to take this important first step to our next > release. > > > Regards, > -jc > > > > *** KNOWN ISSUES -- IMPORTANT *** > > The configure script is likely setting XYMONHOME/XYMONCLIENTHOME and > XYMSRV/XYMSERVERS/XYMONSERVERS incorrectly, which will prevent xymonlaunch > from correctly launching anything. Double check the xymon environment > files (xymonserver/xymonclient.cfg) before starting either the server or > client. > > The tools/xymon-client.default and tools/xymonlaunch files may be placed > into /etc/{sysconfig,default}/{xymon-client,xymonlaunch} to more easily > set $XYMONSERVERS > > Revealed by the above issue is a bug causing a crash in the client (or > anywhere) when given an empty string as the destination argument (instead > of 0, 127.0.0.1 or no variable set). Don't do this --> [ xymon '' "ping" ] > > The client and logfetch binary may be being re-compiled during 'make > install' > > Compilation may fail if c-ares and at least one compression library is not > present (lzo/lz4/zlib are all options). xxHash libraries are also highly > recommended as the plan is for xxhash to replace md5 for checksumming > functionality. libtirpc may be necessary on some platforms, and it's > possible the build code is still expecting traditional (Sun) RPC > > > > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

5 6

Is this thing on? SUMMARY UPDATE and POC
by bruno.manzoni＠ubi-network.ch 29 Jan '24

29 Jan '24

Hi every one *I did a POC on GitHub! *- https://github.com/xymon-monitoring To include/manage the summary of problem (I did previously on this mailing list). The mailing list is not really good to follow problems that take a long time to be resolved (my point of view) This summary also evolve with some more details (but mainly from me) and take a also new form for a better follow up (I hope so) : https://github.com/xymon-monitoring/problem-solving This is only a POC so not official at all, but just for you to see what I did/what could be done (currently limited by my poor skills) You are invited to help me to improve this POC, so to be a member of this GitHub organization: *let me know your GitHub name* Remark: - *Let me know what you think!* - *Focus on the general ideas*: *the support (GitHub)* and *the form* I choose and not to much in the content (I try to make also a good content, but for sure this will need many more work, I would like first to add latest feedback: WIP) - Constructive comment about anything is always welcome! - And as English is not my language: do not hesitate also to correct it. - Positive feedback also motivate... *We still have an urgent problem: the mailing list *(see detail on the POC or in this mailing list) Bruno

4 10

Ordering of yellow vs. red messages in <hostname>:msgs alert e-mails
by earle＠isolar.DynDNS.ORG 30 Dec '23

30 Dec '23

This has been bugging me for awhile now, and I'm annoyed enough to ask about it. My Xymon server is also my syslog server, so the messages file gets tons of messages from everywhere. As such, I'm constantly getting Subject: Xymon [long #] xymonserver:msgs CRITICAL (RED) e-mail alerts. As we all know, they look something like -- red Fri Dec 29 08:31:45 PST 2023 - Log files NOT ok &red Critical entries in <a href="/xymon-cgi/svcstatus.sh?CLIENT=mipl&SECTION=msgs:/var/log/messages">/var/log/messages</a> [... lots of "&yellow" entries here ...] [... some "&red" entries here ...] <B>Full log:</B> <a href=/xmon-cgi/svcstatus.sh?[... elided ...]> <...SKIPPED...> [... more syslog stuff here ...] -- I keep having to scroll down through all the "&yellow" alerts I don't really care much about to get down to the "&red" ones I do care about. Is there some knob somewhere I can twiddle to get the ordering reversed; i.e. to have the &red ones appear first at the top, before all the &yellow ones? A quick scan through the *.cfg files didn't turn up any likely candidates. (Bonus points: put a blank line between the two "&red" and "&yellow" sections.) Thanks!

2 1

Need client for Mac hosts
by support＠ionetworkadmin.com 23 Dec '23

23 Dec '23

Anyone have a modern xymon-client script or app that will run on Mac? I'm aware of the macport method, but that's a large footprint and heavy handed solution to the simple need of collecting performance data and uploading it to the Server. Thank You,Kris Springer?I/O Network Administrationhttps://www.ionetworkadmin.com

6 12

Powershell client maintainer
by stef.coene＠docum.org 20 Dec '23

20 Dec '23

Hi, Who is the current maintainer of the Windows powershell client? It lives in the sandbox tree of the of the xymon project, but I think it deserves some more credits :) I patched the client quit a lot and want to share the patches. Who can I contact fot this? Stef

2 4

Missing support for HTTP/2 ?
by ingeborg.hellemo＠uit.no 18 Dec '23

18 Dec '23

xymon at xymon.com said: > Anything in your xymonnet.log file? I just got the same error, after > upgrading my xymon server from FreeBSD 13.2 to 14.0. Turns out that OpenSSl > 3.0, which is included in FreeBSD 14.0 doesn't support TLS 1.0 > out-of-the-box. My old switches only support TLS 1.0. Nothing in xymonnet.log. TLS version is not the issue. (Well, yes the server offers deprecated TLS versions, but this has never thrown xymon-errors before) Just ran testssl.sh and things seem normal: Testing protocols via sockets except NPN+ALPN SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 offered (deprecated) TLS 1.1 offered (deprecated) TLS 1.2 offered (OK) TLS 1.3 offered (OK): final NPN/SPDY not offered ALPN/HTTP2 not offered Testing cipher categories NULL ciphers (no encryption) not offered (OK) Anonymous NULL Ciphers (no authentication) not offered (OK) Export ciphers (w/o ADH+NULL) not offered (OK) LOW: 64 Bit + DES, RC[2,4] (w/o export) not offered (OK) Triple DES Ciphers / IDEA not offered Obsolete CBC ciphers (AES, ARIA etc.) offered Strong encryption (AEAD ciphers) offered (OK) Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 PFS is offered (OK) TLS_AES_256_GCM_SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA TLS_AES_128_GCM_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA Elliptic curves offered: prime256v1 secp384r1 X25519 Testing server preferences Has server cipher order? yes (OK) -- TLS 1.3 and below Negotiated protocol TLSv1.3 Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Cipher order TLSv1: ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA TLSv1.1: ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA TLSv1.2: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 Testing server defaults (Server Hello) TLS extensions (standard) "status request/#5" "renegotiation info/#65281" "server name/#0" "supported versions/#43" "key share/#51" "extended master secret/#23" Session Ticket RFC 5077 hint no -- no lifetime advertised SSL Session ID support yes Session Resumption Tickets no, ID: no TLS clock skew 0 sec from localtime Signature Algorithm ECDSA with SHA256 Server key size EC 256 bits Server key usage Digital Signature Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication Serial E665ABF3E5755447429FF75312C192DF (OK: length 16) Fingerprints SHA1 AEED932E3A8A750A5D12ACC9E8A265FBFBAAFCE3 SHA256 F54A156CD0BDBC06479BB4497CA09E1BC1D771D4E6 DC78542EB4E701163F0415 Common Name (CN) removed (request w/o SNI didn't succeed, usual for EC certificates) subjectAltName (SAN) removed Issuer GEANT OV ECC CA 4 (GEANT Vereniging from NL) Trust (hostname) Ok via SAN (SNI mandatory) Chain of trust Ok EV cert (experimental) no ETS/"eTLS", visibility info not present Certificate Validity (UTC) expires < 60 days (50) (2023-02-06 00:00 --> 2024-02-06 23:59) # of certificates provided 3 Certificate Revocation List http://GEANT.crl.sectigo.com/GEANTOVECCCA4.crl OCSP URI http://GEANT.ocsp.sectigo.com OCSP stapling offered, not revoked OCSP must staple extension -- DNS CAA RR (experimental) not offered Certificate Transparency yes (certificate extension) Testing HTTP header response @ "/" HTTP Status Code 200 OK HTTP clock skew 0 sec from localtime Strict Transport Security 365 days=31536000 s, just this domain Public Key Pinning -- Server banner (no "Server" line in header, interesting!) Application banner -- Cookie(s) (none issued at "/") Security headers Cache-Control: private Reverse Proxy banner -- Testing vulnerabilities Heartbleed (CVE-2014-0160) not vulnerable (OK), no heartbeat extension CCS (CVE-2014-0224) not vulnerable (OK) Ticketbleed (CVE-2016-9244), experiment. not vulnerable (OK), no session ticket extension ROBOT Server does not support any cipher suites that use RSA key transport Secure Renegotiation (RFC 5746) OpenSSL handshake didn't succeed Secure Client-Initiated Renegotiation not vulnerable (OK) CRIME, TLS (CVE-2012-4929) not vulnerable (OK) BREACH (CVE-2013-3587) potentially NOT ok, "gzip" HTTP compression detected. - only supplied "/" tested Can be ignored for static pages or if no secrets in the page POODLE, SSL (CVE-2014-3566) not vulnerable (OK), no SSLv3 support TLS_FALLBACK_SCSV (RFC 7507) Rerun including POODLE SSL check. Downgrade attack prevention NOT supported SWEET32 (CVE-2016-2183, CVE-2016-6329) not vulnerable (OK) FREAK (CVE-2015-0204) not vulnerable (OK) DROWN (CVE-2016-0800, CVE-2016-0703) not vulnerable on this host and port (OK) no RSA certificate, thus certificate can't be used with SSLv2 elsewhere LOGJAM (CVE-2015-4000), experimental not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2 BEAST (CVE-2011-3389) TLS1: ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA VULNERABLE -- but also supports higher protocols TLSv1.1 TLSv1.2 (likely mitigated) LUCKY13 (CVE-2013-0169), experimental potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches RC4 (CVE-2013-2566, CVE-2015-2808) no RC4 ciphers detected (OK) Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ------------------------------------------------------------------------------- ---------------------------------------------- x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 384 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 xc024 ECDHE-ECDSA-AES256-SHA384 ECDH 384 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 xc00a ECDHE-ECDSA-AES256-SHA ECDH 384 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 xc009 ECDHE-ECDSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA Running client simulations (HTTP) via sockets Android 6.0 TLSv1.2 ECDHE-ECDSA-AES128-GCM-SHA256, 256 bit ECDH (P-256) Android 7.0 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit ECDH (P-256) Android 8.1 (native) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Android 9.0 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Android 10.0 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Android 11 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Android 12 (native) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Chrome 79 (Win 10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Chrome 101 (Win 10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Firefox 66 (Win 8.1/10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Firefox 100 (Win 10) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) IE 6 XP No connection IE 8 Win 7 TLSv1.0 ECDHE-ECDSA-AES256-SHA, 384 bit ECDH (P-384) IE 8 XP No connection IE 11 Win 7 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) IE 11 Win 8.1 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) IE 11 Win Phone 8.1 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) IE 11 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Edge 15 Win 10 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Edge 101 Win 10 21H2 TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Safari 12.1 (iOS 12.2) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Safari 13.0 (macOS 10.14.6) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Safari 15.4 (macOS 12.3.1) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Java 7u25 TLSv1.0 ECDHE-ECDSA-AES128-SHA, 256 bit ECDH (P-256) Java 8u161 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Java 11.0.2 (OpenJDK) TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256) Java 17.0.3 (OpenJDK) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) go 1.17.8 TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) LibreSSL 2.8.3 (Apple) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) OpenSSL 1.0.2e TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) OpenSSL 1.1.0l (Debian) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) OpenSSL 1.1.1d (Debian) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) OpenSSL 3.0.3 (git) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Apple Mail (16.0) TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit ECDH (P-384) Thunderbird (91.9) TLSv1.3 TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519)

1 0

Alerts.cfg
by Neil.Simmonds＠studio.co.uk 16 Dec '23

16 Dec '23

Hi folks, Beyond having the script check in critical.cfg for the alerting server/test combination is there any other way to configure an option in alerts.cfg so that only alerts that are red and on the Critical config page will trigger the action. I know I can use COLOR=RED but there doesn't seem to be a PAGE option that equates to the Critical page. Thanks, Neil SImmonds Studio is a trading name of Studio Retail Trading Limited (Company no. 03994833), which is an introducer of credit not a lender. Studio Pay is provided by Frasers Group Financial Services Limited (Registered Company no. 00718151), which is authorised and regulated by the Financial Conduct Authority (FRN 311908) for consumer credit and general insurance and a member of the Finance and Leasing Association. Both companies are registered in England and their registered office is: Church Bridge House Henry Street Accrington BB5 4EE. NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. The recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Any views or opinions presented are solely those of the author and do not necessarily represent those of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. Studio Retail Trading Ltd and Frasers Group Financial Services Ltd reserve the right to monitor all e-mail communications through their internal and external networks. If you have received this email in error please let us know. You can find our available contact details by going to help.studio.co.uk and clicking 'Contact Us'.

2 1

Missing support for HTTP/2 ?
by urb＠twe.net 15 Dec '23

15 Dec '23

On 2023-11-08 13:14, Ingeborg Hellemo via Xymon wrote: > tom at 4schmidts.com said: >> HTTP/2 support is currently not in xymon, including in the 4.4alpha1 >> development tree. I did a little testing, and sites like google that support >> HTTP/2 still pass the xymonnet checks as seen below: > As you pointed out HTTP/2 is not part of the equation. (We turned it off > completely on the server just to be sure). > > But I'm not any closer to resolving the issue. As I said, webpage in browser - > no errors, curl - no errors, 'openssl s_client' no errors. > > > ~/server/bin/xymonnet --debug --no-update <servername> > > 35422 2023-11-08 13:06:06.168385 1 status messages merged into 1 transmissions > Address=[IP]:443, open=1, res=0, err=5, connecttime=0.000303, > totaltime=0.002631, > httpstatus = -5, open=1, errcode=5, parsestatus=0 > Response: > (no headers) > URL : https://<servername>/ > HTTP status : -5 > HTTP headers > (NULL) > HTTP output > (NULL) > > > > Any ideas? Anything in your xymonnet.log file? I just got the same error, after upgrading my xymon server from FreeBSD 13.2 to 14.0. Turns out that OpenSSl 3.0, which is included in FreeBSD 14.0 doesn't support TLS 1.0 out-of-the-box. My old switches only support TLS 1.0. The xymonnet.log have these entries: 2023-12-15 21:03:49.454627 Unspecified SSL error in SSL_connect to https (47873/tcp) on host 192.168.1x1.2x3: error:0A000152:SSL routines::unsafe legacy renegotiation disabled Of course, if your test tools use the same OpenSSL library as xymon, they ought fail as well, but it sounds like an incompatible cipher issue. -- Med venlig hilsen - Sincerely Uffe R. B. Andersen - mailto:urb at twe.net http://blog.andersen.nu/

1 0

xymon.org cloudFlare is expired
by abe＠deuxchevaux.org 11 Dec '23

11 Dec '23

Hi Henrik, On Mon, Dec 11, 2023 at 09:37:11PM +0100, Henrik Juul St?rner via Xymon wrote: > > Does the Xymon team/Henrik/etc have access to xymon.org ? > > https://xymon.org gives a CloudFlare error. > > I had it registered, but since it had never been used I decided to let it > expire. well, "never been used" seems wrong to me. It existed and worked. That alone, plus the fact that people guessed it, sufficed for it being used in the wild. Additionally many open source folks think that an open source project's website should sport the non-commerical .org TLD instead of .com and as xymon.org worked, they linked to it without thinking further that there might have been a redirect in it. Luckily I so far only found one occurrence in a Debian package ? which I just fixed. In my humble opinion, if you ever buy a domain, you're responsible for it not becoming a link spammer farm for more or less forever. Which means that you should probably never let it expire... And yes, that costs a small bit of money. P.S.: Thanks to Josh for noticing and reporting! 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