On latest version as of today (daily update).
I have an issue that’s been going on for a while now, and seems to be getting exacerbated.
The issue is that I’m monitoring 3x LDAP DC’s via LDAPS, specifically monitoring the presented SSL Certificate expiry on each host.
For some reason I cannot find or fathom, one of them keeps getting checked every hour of every day, whereas the other 2x DCs get checked wayyyyyyy lower frequency. They each seem to have their own frequency, and I don’t know why. I don’t believe I set any setting for frequency of this nature.
Anyways, I thought the problem was related to the version of OpenSSL 1.1.1(whatever letter) as the LibreNMS System was on Ubuntu 20.04, and I upgraded it to 22.04. However it’s checking frequently, and now I think may be temporarily banned from that DC for checking too frequently.
I’ll probably go and get it unbanned at some point, but does anyone know wtf could be going on here? :s
So as of right now I have removed the service monitor config for the “problematic” DC, and re-added it. The problem seems to have immediately returned. As a result, I have disabled (but left in-place) the service config to monitor this DC’s LDAPS cert. The other cert checks (2x LDAPs and 2x HTTPs) are still active. And those remaining ones do not appear to have the “problematic frequency” behaviour. And I REAALLYYY DOOO NOT KNOW WHY!
I’m still having this problem. @murrant do you have any ideas what’s going on here?
I’m still having this problem with this single DC serving LDAPS… NOTHING ELSE does this. Can I PLEASE get some help with this???
Still having this issue… and it’s ONLY ONE of the THREE IDENTICAL systems doing this. I cannot find a reason why this is happening…
So at this point it’s actually looking to NOT be a libreNMS issue. The evidence I have in-hand is that some of the automations for the DC were firing too frequently and were interfering with the LDAPS connectivity that libreNMS was performing to check the certificate.
Since correcting the automations I have not observe this issue again with the problematic DC. It has been a handful of days. I will continue to monitor it, but right now this looks to be resolved.
Sorry for the mix-up, but at the time the only evidence I could find suggested libreNMS was the possible culprit.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.