Messages

This is from my System: Log Files: Backend

2024-08-26T22:17:33   Error   configd.py   Timeout (120) executing : crowdsec stop   
2024-08-26T22:16:44   Error   configd.py   Timeout (120) executing : crowdsec stop   
2024-08-26T22:16:44   Error   configd.py   Timeout (120) executing : service stop 'crowdsec' ''

Hi,

I have exactly the same problem on 24.7. I don't know on which version it started. Running

Code Select Expand

kill -9 <PID of hung crowdsec process> via ssh solves the hanging and the update / reboot completes as intended.

It has been discussed before: https://forum.opnsense.org/index.php?topic=34435.msg166789#msg166789 but I can't find any solution here in the forum (seraching for crowdsec stuck or crowdsec hungs or similar) nor in the github issues for plugins.

Does anybody have a hint or link?

Hi, no. Thanks for the hint, that did the trick. I didn't see this setting, because it is hidden by default (advanced settings). May I ask, what the use case for setting this on a per server basis is? I really whish there would be a "multi edit" action for servers, locations etc.

Maybe it would be a good idea to set the resolver to "127.0.0.1, [::1]" for a HTTP Server if "None" is selected to mitigate the unnescessary warnings in the log.

Hi, in OPNsense 24.7_9 I have set the resolver to 127.0.0.1 [::1] in the GUI. The warning

... no resolver defined to resolve r10.o.lencr.org while requesting certificate status, responder: r10.o.lencr.org, certificate: "/usr/local/etc/nginx/key/[...].pem"

still spams my nginx log though.

When using Interfaces -> Diagnostics -> DNS Lookup the domain r10.o.lencr.org is resolved correctly.

Do you have any suggestions for further trouble shooting?

Habt Ihr euch dieses Issue schon mal angesehen? https://github.com/opnsense/core/issues/5630 War für mich die Lösung an nem VDSL-Anschluss von Vodafone. Kommt mit 24.7 offiziell raus.

Hi,

initially I "only" wanted to add support for update-URLs containing IPv4 and IPv6 at the same time (new service type "Custom (v4/v6)" (Issue #2053) to get it working with my INWX-account.

I ended up starting to tidy up the legacy code (PR #2053) and noticed that there are about 10 other open PRs related to dyndns (Filter open PRs) that will be affected by this because of upcoming merge conflicts.

One of the core developers replied with this feedback (link to original comment):

@Starkstromkonsument the dyndns plugin is very old and practically unmaintained, it would need a rewrite, which isn't very high on our list of things todo (I'm not convinced it needs the current level of entanglement into the system either). Adding more glue often doesn't improve the situation and decreases the chances of a rewrite, but that's just my opinion.

If you want to cleanup the existing plugin, best keep it in the same PR in this case to avoid merge conflicts. Since I personally don't want to spend a lot of time on this, it would be good to gather some people who offer to test, maybe ask around on the forum to collect some.

When a couple of users can test the new code and vouch for it, I don't mind pulling in a larger batch to solve different issues, as long as you (or anyone else) promises to look at possible new issues that emerge after releasing it to the general public.

I can open this issue and assign it to you if you like, I don't think anyone else is interested in "owning" the issue currently.

I would be really happy to keep working on this (just working on the existing plugin for now), but I can't do it on my own. Is there anybody around who would like to join in? I think help is mainly needed for reviewing and testing the code and it would be very efficient to deal with all the open PRs in one bundle.

Regards, Alex

Nabend, hab nun mal Zeit gehabt, um mich damit nochmal zu beschäftigen. Ich habe ne eigene Domain und von INWX weg wechseln wollte ich nicht unbedingt. Bin mit denen sehr zufrieden.

Es sind hier gleich mehrere Probleme:

• Der DynDNS-Host von INWX ist per IPv6 nicht erreichbar --> Können wir wenig machen, INWX möchte zum Jahresende aber umstellen.
• Der Dynamic DNS dienst von OPNsense hat einen Bug. Wenn man CURL per "Force IPv4 resolving" zwingt IPv4 zu benutzen, möchte OPNsense trotzdem noch die IPv6 vom WAN als source-IP benutzen. Das klappt natürlich nicht ... --> Lösung
• OPNsense unterstützt keine Update-URLs mit IPv4 und IPv6 gleichzeitig --> Lösung

Bei https://www.spdyn.de funktionieren IPv4 und IPv6 unabhängig voneinander. Allerdings verbrauchen sie auch zwei Hosts von den fünf freien.

Bei INWX schlägt bei mir das Update der IPv6-Adresse immer fehl ("custom"-Variante während der Tests deaktiviert). Die Domain dyndns.inwx.com ist ein CNAME auf moneypenny.inwx.net. Dafür gibt es aber nur einen A und keinen AAAA-Record. Ich vermute, dass der dyndns-client ("custom (v6)") versucht die IPv6-Adresse via IPv6 zu aktualisieren und es daher gar nicht klappt. Bei spdyn gibt es auch einen AAAA-Record und das Problem besteht nicht.

Anhand des Livelogs der Firewall konnte ich nachvollziehen, dass bei einem "Save and force update" des dyndns "custom" eine ausgehende Verbindung zu 185.181.104.220:443 (moneypenny.inwx.net:443) erfolgt. Bei "custom (v6)" bleibt eine ausgehende Verbindung aus. Die Option "Force IPv4 resolving" ändert an diesem Verhalten nichts.

Bei spdyn gibt es jeweils eine ausgehende Verbindung zu 195.4.152.239:443 bzw. [2a00:dca0:100:9:53::1]:443 (www.spdyn.de:443).

Ich hatte dazu im März 2020 Kontakt zum Support von INWX. Der DynamicDNS-Dienst von INWX ist demnach bisher noch nicht via IPv6 erreichbar. Es wird wohl auch "noch dieses Jahr andauern".

Die Frage die sich mir nun stellt ist, warum der dyndns-client an der stelle anscheinend so stur ist (wenn meine Beobachtung stimmt). Er könnte doch in jedem Fall versuchen eine Verbindung über IPv4 und IPv6 zum jeweiligen Updateserver herzustellen, oder?