Beiträge von mhagge

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)

Leider nicht sehr ergiebig - MySQLtuner beschwert sich zwar weiterhin über

[!!] Joins performed without indexes: 3981

und

"Adjust your join queries to always utilize indexes"

(der Server ist wegen eines Kernel-Updates gestern Morgen mal neu gestartet worden, das sind also Zahlen für etwa 24 Stunden Laufzeit)

aber in den Logfiles schlägt sich das nicht nieder

Ich hab mal das Slow-Query-Log und "Log queries not using indexes" aktiviert, vielleicht hilft das bei der Suche nach der Ursache

Zitat von kk

Auf den ersten Blick vermute ich, dass irgendeine SQL-Abfrage, die zum Aufbau der vHost-Konfiguration verwendet wird, langsam ist. Eine "durchschnittliche" vHost-Konfiguration hat ja nur eine überschaubare Zahl an VirtualHosts, daher fällt es meistens nicht auf wenn vielleicht ein Datenbankindex fehlt.

Das könnte hinkommen - mysqltuner beschwert sich über eine hohe Zahl von "Joins performed without indexes" und schlägt vor, das zu optimieren

Zitat von mhagge

Hallo Herr Kepler,
Backend ist MySQL (um genau zu sein MariaDB, ist ein Debian9-System), es sind runde 2600 VHosts in der webx.conf

Als Ergänzung: 4 Kerne Intel CPU (also 8 virtuelle Kerne) und 36 GB Speicher. Das System rennt ansonsten wie eine 1, keinerlei Probleme mit Geschwindigkeit oder Auslastung (die Domains gehören zu einem Webbaukasten-System, welches ich hoste. Dessen Datenbanken sind allerdings auf einem anderen Server, nicht auf dem gleichen, dort ist nur "Web") - nur eben halt an dieser einen Stelle hakelt es.