Beiträge von mhagge

Moin,

mit neuem Anbieter hatte ich das probiert - ohne Erfolg.

Rückmeldung kann es bei mir insofern nicht geben, als dass ich nicht direkt gemailt hatte. Die Domain musste / sollte gestern Abend funktionieren, insofern hatte ich da keine große Wahl, als zu hoffen, dass es dann mit LC2 geht (was dann ja auch problemlos geklappt hat).

Ob es wirklich problemlos funktioniert – ich würde da empfehlen, sehr genau hinzuschauen. Dass LC3 (von der Menge her müssten es alle seit der Umstellung auf LC3 gewesen sein) die LetsEncrypt-Zertifikate nicht verlängert hat, wird dort in der Oberfläche nirgends angezeigt, das habe ich erst mit der Rückstellung auf LC2 dort in der Oberfläche gesehen – und die Umstellung ist halt hier auch bisher nicht so lange her, als dass da schon eins wirklich ausgelaufen gewesen wäre. Insofern: Ich war auch davon ausgegangen, dass soweit alles problemlos läuft, weil halt nirgendwo ein Problem angezeigt wurde.

Ich habe aber definitiv auch nach der Umstellung auf LC3 neue LetsEncrypt-Zertifikate erfolgreich beziehen können. Wenn es jetzt nicht bei dieser einen Domain, warum auch immer, nicht geklappt hätte, wäre mir das vermutlich erst aufgefallen, wenn die ersten LE-Zertifikate aufgrund fehlender Verlängerung tatsächlich ausgelaufen wären... Möglicherweise also ein Problem, was sich erst mit irgendeinem .-Update eingeschlichen hat, wobei ich, wie gesagt, bei Verlängerungen ziemlich sicher bin, dass die mit LC3 bei mir jedenfalls noch nie funktioniert haben.

Viele Grüße

Markus

Zitat von Jim

Habe jetzt mit der aktuellen Version 3.0.3 unter Debian bookworm folgendes Problem mit den Zertifikaten.

Die automatische Verlängerung von Liveconfig hat nun bei den zu verlängernden Zertifikaten den Job doppelt angelegt.

Das führt zu dem Fehler das die Verlängerung nicht ausgeführt wird und in der liveconfig.log folgender Fehler protokoliert wird.

Code

 [3519098] [2025-08-26 12:36:54.077276] [INFO] [LUA] Detected 'Debian GNU/Linux 12 (bookworm)'
[3519097] [2025-08-26 12:37:52.503274] [EMERG] Uncaught exception in ChildManager: tlsjob already exists
[3519097] [2025-08-26 12:37:52.503314] [EMERG] Got exception: WebSession::AuthRequiredException
  [ 0] 0x177fab   
  [ 1] 0x274d48   
  [ 2] 0xf7d05    /usr/lib/liveconfig/libk.so.0.9
  [ 3] 0x125eca   /usr/lib/liveconfig/libk.so.0.9
  [ 4] 0x3b0ac0   
  [ 5] 0xd44a3    /lib/x86_64-linux-gnu/libstdc++.so.6
  [ 6] 0x891f5    /lib/x86_64-linux-gnu/libc.so.6
  [ 7] 0x10989c   /lib/x86_64-linux-gnu/libc.so.6

Alles anzeigen

Alles anzeigen

Selbiges Problem hier auch – bis auf dass der Job hier nicht doppelt angelegt wird. Das Bild im Liveconfig.log ist aber das gleiche.

Domain neu abspeichern, SSL-Zertifkat neu abspeichern, Liveconfig neu starten, Server neu starten - nichts hilft.

Neu austellen von Zertifikaten hat aber auch mit Version 3 definitiv schon geklappt – ob Verlängerung auch kann ich nicht sicher sagen, denn:

Ich wusste mir jetzt nicht weiterzuhelfen, zumal ich schnell eine Lösung brauchte – also bin ich zu LC2 zurück.

Dort ist jetzt eine relativ lange Liste von SSL-Zertifikaten, die nicht verlängert wurden – die scheint LC2 gerade abzuarbeiten, wenn ich mir die liveconfig.log so anschaue

Irgendwo steckt da aber mit LC3 und LetsEncrypt noch ziemlich der Wurm drin, befürchte ich

Zitat von Systemhaus-EHST

Hallo

hast du mal die Konfigurationen neuschreiben lassen?

Laufen alle Dienste?

Vielen Dank! Nein, das war es nicht. mod_security war der Übeltäter

in die .httpd-conf des betreffenden Webs

<IfModule security2_module>
SecRuleEngine Off
</IfModule>

eintragen, dann funktioniert alles.

Hallo zusammen,

Ich habe Liveconfig mit "LetsEncrypt-Proxy" nach diesem Muster eingerichtet: https://www.liveconfig.com/en/kb/liveconfig-lets-encrypt/ und nun das Update LC2 -> LC3 durchgeführt.

Das funktioniert auch so weit, ich kann mich mit LC3 einloggen und es werden auch alle Informationen (Domaineinstellungen etc.pp) angezeigt.

Allerdings kann ich keinerlei Änderungen vornehmen, egal was ich ändern will (ob jetzt an den Einstellungen von Liveconfig, oder an Domains etc.) kommt immer eine kleine Meldung "No JSON response from server" und die Änderung wird nicht gespeichert.

Mache ich das gleiche allerdings ohne Proxy (also Aufruf über Port 8443) klappt alles reibungslos, alle Änderungen werden gespeichert.... Wäre jetzt nicht so dramatisch, weil ich der einzige Nutzer bin, aber wundern tut es mich schon (zumal ich einen 2. Server umgestellt habe, wo alles reibungslos funktioniert, auch mit Proxy - und ich kann partout keinen Unterschied zwischen der Serverkonfiguration erkennen)

Im liveconfig.log steht da nichts zu. Hat jemand evtl. eine Idee, woran das liegen könnte

Viele Grüße

Markus

Ich glaube, das geht sowieso am Thema vorbei. Eine Kündigungsmöglichkeit im Webhosting-Panel wäre zwar nett für den Kunden, geht aber am Thema vorbei und ist nicht das, was mit dem (seit 1.7. schon) verpflichtenden Kündigungsbutton gemeint ist - der darf sich nämlich nicht hinter einem Login verstecken, sondern muss öffentlich erreichbar sein. Ganz grob also ein Formular mit einem weitgehend vorgegeben Inhalt, dessen Empfang umgehend bestätigt werden muss

Details z.B. https://datenschutz-generator.de/kuendigung-button/

Das Problem scheint mir zu sein, dass LetsEncrypt "ISRG Root X1" weiterhin mit ausliefert (neben dem R3), wenn auch als abgelaufen. Da z.B. ältere Android-Geräte das nicht prüfen, ist da die Kompatibilität weiterhin gegeben.

Neuere Clients sollten in der Theorie wenn sie bemerken dass ISRG Root X1 abgelaufen ist auf R3 zurückgreifen, so dass da kein Problem entsteht. In der Praxis passiert das scheinbar nicht in jedem Fall

Kann ich bestätigen - hier war nur " 8d33f237.1 " vorhanden, nach dem löschen hat es tatsächlich wieder geklappt

Auf einem zweiten Liveconfig-Server (beides gleicher Versionsstand, von Liveconfig wie auch Debian) gab es allerdings überhaupt keine Probleme :confused:

Der Titel sagt dem Grunde nach schon alles

Ich lege Domains per API an (das klappt auch wunderbar) und würde gerne für diese Domains LetsEncrypt gleich mit beantragen / einrichten (dazu muss ich mich bislang dann doch wieder in die Liveconfig-GUI einloggen).

Nun gibt es ja seit einiger Zeit durchaus Methoden in der API dazu, z.B.

https://www.liveconfig.com/de/…ce.HostingDomainAdd.xhtml

Allerdings geht das ja davon aus, dass man man den Key, das Zertifikat und evtl. Zwischenzertifikate mit übergibt. Damit komme ich aber ja via LE so gar nicht in Berührung (und via API dass dann abrufen und wieder zu übergeben geht auch nicht, würde aber ja auch spätestens bei einer Verlängerung Probleme geben).

Insofern: habe ich da was übersehen oder gibt es da tatsächlich derzeit keinen Weg? Ich stelle mir ja einfach einen Schalter "le = true" oder sowas in der Parameterliste vor.

Das Feature gefällt mir zwar - aber: das betraf bei mir mehrere duzend LE-Zertifikate, und ich bin der einzige der auf dem Server dazu was einstellt. Was auch immer die Ursache war - doppelte Aufträge sehr sicher nicht, in dem Umfang müsste ich das wissen

Und ich stelle gerade fest, dass sich der Fehler heute morgen von alleine behoben haben muss - wöchentlich laufender Cronjob oder sowas? Ich hatte tagelang eine ziemlich lange Liste von laufenden SSL-Aufträgen in der GUI und im Liveconfig-Log war die Fehlermeldung, die von Martin Krüger beschrieben wurde. Heute morgen scheint sich das warum auch immer aufgelöst zu haben, keine entsprechende Fehlermeldung mehr im Log, die Liste im GUI ist leer und die Zertifikate wurden anscheinend nun auch alle verlängert.

Ich hab weiter nichts gemacht, keinen Dienst oder gar den Server neugestartet :confused:

Hier das gleiche Problem - doppelte Bestellungen liegen ebenfalls nicht vor

Zitat von kk

Ich tippe mal darauf, dass /tmp mit dem Flag "noexec" gemountet ist?
Da wird es dann auch bei anderen Paket-Updates krachen.

noexec - In der Tat, warum auch immer.... Vielen Dank!

Bei mir (aktuelles Debian 9) kommt nach dem apt-get upgrade da ein

Zitat

Can't exec "/tmp/liveconfig.config.IHxnTX": Keine Berechtigung at /usr/share/perl/5.24/IPC/Open3.pm line 178.
open2: exec of /tmp/liveconfig.config.IHxnTX configure 2.7.2-r5133 failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

Funktionierend (zumindestens das sichtbare) tut es aber anscheinend, Liveconfig lässt sich aufrufen und benutzen

Ah, ok - wohl das hier: https://www.liveconfig.com/de/…6667&viewfull=1#post16667

Irgendwas scheint beim Update auf 2.7.1 kaputt gegangen zu sein..

Ich erhalte beim anlegen einer Sub-Domain immer (egal was ich eingebe, selbst mit dem simplen "www") die Fehlermeldung "Ungültiger Subdomain-Name")

Das gleich passiert auch, wenn ich eine bestehende Sub-Domain bearbeiten will

Naja, aber so ein abgelaufenes Zertifikat da zu haben ist auch unschön - ausserdem ist "opportunistisches HTTPS" manchmal ja auch nützlich.

Soweit klappt das auch - nur der Schritt 4 (abspeichern) klappt nicht und da könnte ich mir vorstellen besteht sogar ein Allgemeineres Problem - das neue "Zertifikat" wird erzeigt, lässt sich aber nicht abspeichern - in der liveconfig.log steht dann

Zitat

Unknown CGI variable 'comment' -> always call initForm() before checkForm()!

Ich glaube das geht um das Default Server-Zertifikat für SSL für den Webserver - steht in der Liste der SSL-Zertifikate mit der Bemerkung "Default SSL-zertifikat für SNI"

Bei mir läuft das demnächst auch aus, insofern würde mich das auch interessieren Zumal (bei mir ist es Debian)

sudo make-ssl-cert generate-default-snakeoil --force-overwrite

und anschließendes Neustarten von Liveconfig und Apache an diesem Zeritfikat irgendwie nichts geändert hat, das steht da immer noch mit Ablaufdatum Anfang Dezember.

Zitat von kk

Preview wurde auf v2.7.0-r5076 aktualisiert, da stimmt die SSL-Zuordnung wieder.

Wir haben die Erzeugung der vHost-Konfigurationen massiv optimiert - in einem Testfall mit 3000 vHosts in einem einzelnen Vertrag (ca. 15 MB Konfigurationsdatei) dauert das aktuell nur noch 5 Sekunden statt vorher tatsächlich einigen Minuten.

Super, das freut mich!

Vielen Dank! Ist nicht dramatisch, aber doch lästig..

Viele Grüße
Markus Hagge

Gute Idee. Ich hab mal "mytop" während einer solchen Aktualiserung mitlaufen lassen.

Einer Query bin ich zwar nicht habhaft geworden, aber ich aber die Dauer zwischen den einzelnen Abfragen scheint recht lange zu sein. Es sind ständig 3 offene Verbindungen mit dem User "liveconfig" zur DB "LIVECONFIG" vorhanden - die befinden sich aber teilweise sehr lange im "Sleep"-Status, bevor sich der "Time" Wert wieder zurücksetzt (ich habe kein einziges mal unter 10 Sekunden beobachtet, meistens so im Bereich um die 15 Sekunden. Den Status "Query" für eine dieser Verbindungen habe ich dabei kein einziges mal gesehen, der einzige Anhaltspunkt dass sich auf der DB doch ewas tun muss ist, dass sich eben dieser "Time"-Wert verändert und auch wieder zurücksetzt)