Hallo Herr Kepler,
Backend ist MySQL (um genau zu sein MariaDB, ist ein Debian9-System), es sind runde 2600 VHosts in der webx.conf
Die SSD hatte ich neulich ja schon mal getestet, zwar nicht überragend, aber auch nicht Mega-schlecht (und auf jeden Fall deutlich schneller als eine HDD) - an der sollte es also nicht liegen. Woran könnte es noch liegen?
Mir fällt ansonsten gerade noch auf, dass im /conf/acme-Verzeichnis fast 13000 Dateien sind - muss das so sein?
Ich denke, ich weiß inzwischen wie das Problem entsteht. Und zwar passiert es immer dann, wenn Liveconfig viele Zertifikate auf einmal erneuern will - dann kommt es zu Timing-Problemen.
Das "Problem" ist, dass Liveconfig für jede einzelne Änderung die webx.conf neu schreibt. Pro SSL-Zertifikat sind das 2 Änderungen (einmal für die Domain mit www und einmal für die ohne). Werden jetzt z.B. 10 Zertifikate auf einmal erneuert dauert es bei einer "Schreibezeit" von 2-3 Minute pro webx.conf also minimum 20 Minuten, eher mehr, bis der Apache sämtliche für die Veränderung erforderlichen Config-Änderungen überhaupt erst zur Verfügung hat. Selbst mit meinem deutlich verlängerten RELOAD.min bzw. RELOAD.max fallen dann welche hintenrüber, weil bei den Domains die Konfiguration für das ACME-Challenge halt noch nicht geschrieben ist.
Ich könnte nun also entweder die Zeit nochmal deutlich verlängern (das würde theoretisch gehen, an der Config ändert sich ansonsten so häufig auch nichts, nur halt gerade dann ist es nervig so lang warten zu müssen), ich könnte einstellen, dass nie mehr als 2-3 Zertifikate auf einmal verlängert werden (das geht aber IMHO derzeit nicht) oder aber Liveconfig müsste dazu gebracht werden, die Config nicht für jede Änderung neu schreiben zu müssen (bei manuellen Änderungen kann ich das ja nachvollziehen, dass das erforderlich ist, aber bei solch Dingen wie Zertifikatsverlängerungen weiß LE doch dem Grunde nach, dass da jetzt x Änderungen aufeinmal kommen - warum werden diese Änderungen dann nicht auch auf einmal in die Config geschrieben?)
Daneben suche ich noch einen Weg, die Apache-Config zu verschlanken - ich nutze Liveconfig nur als Verwaltungs-Tool für mich selber, aus der Config könnte also allerhand entfernt werden, weil ich es gar nicht nutze (die Einträge für mod_php z.B. oder mod_compat und was da sonst noch so standardmäßig drin ist). Ich vermute mal damit liesse sich das Problem auch deutlich entschärfen. Vermutlich muss ich dafür irgendeine .lua-Funktion überschreiben, nur geht das ohne Nebenwirkungen?
Die "Überbrückung" der Weiterleitung macht ja Liveconfig, wenn ich das richtig sehe - insofern kann das mit der Basic-Version wohl so auch nicht klappen (evtl. wenn man manuell eine "Dauerausnahme" für die ACME-Konfigurations-URL in die Apache-Config schreibt, das müsste eigentlich gehen).
Das ist aber hier auch nicht das Problem, ich kann mir die ACME-Bestätigungs-URLs wenn ich sie mir aus dem Protokoll rauskopiere sogar manuell aufrufen. Nur im Moment der Verifizierung klappt das anscheinend manchmal nicht. Ich habe jetzt die RELOAD-Zeiten enorm hochgestellt ("min" auf 500), da sich da ausser den SSL-Zertifikatsverlängerungen nicht groß was ändert ist die Verzögerung akzeptabel, seit dem ist das Problem nicht mehr aufgetreten - obwohl ich mir das nach der Erklärung von Herrn Keppler so recht nicht erklären kann. Schaun wir mal.
Bitte? Da stimmt dann aber was mit der Hardware nicht...
Wir fahren mit LiveConfig auch regelmäßig mal Lasttests mit >10.000 Domains in einem Vertrag, auch da dauert die Erstellung der .conf-Dateien keine Sekunde.
Steht der Server vielleicht recht "unter Dampf"? Ein hoher I/O auf dem Server insgesamt wäre die enizige Erklärung, warum das so lange dauert.
Naja gut, er ist im laufenden Betrieb, aber hat eigentlich reichlich Reserven und mit den restlichen Systemdiensten gibt es auch keine Probleme - die .conf mit dem Web hat 12 MB Größe.
Ein Apache-Reload dauert etwa 10 Sekunden. Ich hab mal ein Tempfile mit DD geschrieben:
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 3,88818 s, 276 MB/sNicht überragend, aber auch nicht grottig schlecht würde ich sagen.
Warum hier 1 GiB keine 4 Sekunden dauert, die web.conf von Liveconfig mit 12 MB Größe aber solange braucht wüsste ich allerdings auch gerne 
Wie könnte man das genauer eruieren bzw. wo könnte da ein Ansatz für eine Bremse sein?
DNS-Einträge verändert worden? Domain umgezogen?
Nene, die habe ich unter eigener Kontrolle Die Homepage lässt sich ja auch normal aufrufen
Es gibt aber einen korrespondierenden Eintrag im Apache-Error-Log - das HTML-Fragment dürfte von einem 404er stammen. Die ACME-Challenge wird nicht gefunden, dann geht es an der Stelle natürlich nicht weiter.
Das wiederrum könnte damit zusammenhängen, dass in dem Web beinahe 3000 Domains sind - es dauert eine Weile die .conf-Datei zu schreiben (runde 3 Minuten, trotz SSD). Deswegen ist meine Vermutung ein Timing-Problem, vermutlich wird die Verifizierung versucht wenn die Konfiguration noch nicht verfügbar ist. Ich hab schon die Apache.MINLOAD und MAXLOAD-Werte angepasst bzw. deutlich höher gesetzt, der Dokumentation nach sollte das die LE-Verifizerung auch berücksichtigen, aber entweder das passiert nicht oder da ist noch ein anderer Faktor, auf den ich noch nicht gekommen bin
was ist denn die konkrete Fehlermeldung?
es gibt Fehler da hilft einfach erneut versuchen nichts
Naja, bei vielen (den meisten, würde ich sagen) hat es ja geklappt, manuell funktioniert es auch. Nur bei einigen wenigen ist da ein
Invalid response from http://domain.de/.well-known/acme-challenge/VKqmkl70BSwL40Rz63Wl3vwUdHFPqGsuRMsNsA8Xqac: "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html "(domain.de ersetzt die eche Domain)
Deswegen fürchte ich eine temporäre Überlastung (wobei es da kein anderes Anzeichen für gäbe, die Munin-Graphen z.B. sind in Ordnung und es gibt auch keine Einträge im Error-Log oder sowas) oder ein Timing-Problem oder sowas
Wobei mir gerade auffällt, dass der HTML-Code, der sich da in der Fehlermeldung andeuet nicht von der fraglichen Domain stammt, da geht es anders los.
Wenn die automatische Erneuerung der LE-Zertifikate aus welchen Gründen auch immer fehlgeschlagen ist - versucht Liveconfig das dann später nochmal oder muss ich mich manuell drum kümmern?
Hintergrund der Frage ist, dass ich hier eine Handvoll Zertifikate habe, die aus mir noch unbekannten Gründen nicht verlängert wurden - im ACME-Tab steht auch eine Fehlermeldung drin bzw. im liveconfig.log ebenfalls (das ist der Schwung von der DSGVO-"Panik" - ich hoffe nicht, dass das zuviele auf einmal waren, dann habe ich das Problem ansonsten alle 3 Monate.....
Nun sind die Zertifikate noch fast 30 Tage gültig, es ist also noch genügend Zeit. Versucht Liveconfig die Erneuerung später nochmal, oder kann / sollte ich schon manuell tätig werden (ich habe eins mal getestet, einfach nochmal auf "speichern" klicken reicht)
Hat wunderbar geklappt, vielen Dank!
@ManDal:nicht über die GUI, aber direkt über MySQL (oder ein kleines Script, was man dann wiederrum in die GUI einbauen kann) lässt sich das mit den Hinweisen relativ schnell erstellen
Ich verwende Liveconfig in einem Projekt nur für mich als "Verwaltungserleicherungstool", Kunden haben da keinen Zugriff drauf.
Nun will ich bei diesem Projekt die PHP-Version ändern und stehe vor einem Problem: wie mache ich das massenhaft und nicht nur bei einzelnen Domains. Alle Domains (es sind mehrere 100) durchzuklicken und von Hand zu ändern kann doch eigentlich nicht die Lösung sein? In der API gibt es aber, wenn ich nichts übersehen habe, auch nichts passendes.
Wie macht man das also am besten? Gibt es einen Weg über die Datenbank evtl. (Liveconfig läuft auf MySQL). Ich weiß soll man nicht (kann ich auch nachvollziehen), aber vielleicht gibt es ja einen "Hack"
[*]ca. 90 Sekunden nach dieser Änderung triggert LiveConfig bei Let's Encrypt die Prüfung dieses Tokens an (90 Sekunden deshalb, weil es bis zu 60 Sekunden dauern kann bis die neue Apache-Konfiguration aktiv ist).
Ist dieser Wert irgendwo konfigurierbar? Ich habe eine recht umfangreiche Config mit sehr vielen Domains, seit der Umstellung des webs auf FastCGI (das hat es nochmal weiter aufgebläht) scheint da der Apache länger als die 90 Sekunden zu brauchen, bis die Apache-Config aktiv wird.
Ich erhalte jedenfalls ebenfalls immer wieder die Meldung "Invalid Response" und im access.log ist auch ein Error 404 für die Abfrage zu sehen. Wenn ich "/.well-known/acme-challenge/usw" versuche manuell parallel aufzurufen lässt es sich auch im Browser nachvollziehen. Warte ich etwas, kann ich es im Browser problemlos aufrufen, aber die LE-Überprüfung ist dann bereits fehlgeschlagen - daraus schließe ich, dass es bei mir aufgrund des Umfangs der Apache-Config einfach zu lange dauert, bis diese aktiv ist.
Ich hab mir jetzt beholfen, in dem ich in der .httpd.conf im Web ein
ZitatAliasMatch "^/.well-known/acme-challenge/(.*)$" "/var/www/web1/conf/acme/$1"
aufgenommen habe - das scheint auch zu funktionieren, damit gibt es bis jetzt jedenfalls keine solchen Probleme mehr. Allerdings bin ich mir nicht ganz sicher, ob das nicht ggf. andere Nachteile mit sich bringt, wenn ich irgendwo einstellen kann dass LE einfach etwas länger mit der Überprüfung des tokens wartet fände ich das eleganter.
Sieht gut aus - der Speicherverbrauchsgraph bleibt seit dem Update gerade
Viele Dank!
Ja... super das noch jemand den Fehler hatte.. Ich hab zum Glück vor dem eigentlichem Update auf v2 ein Image des alten Systems komplett gemacht.. Nach 1 Tag war mein Server wegen zu wenig RAM nicht mehr erreichbar bis ich einen Neustart gemacht hatte.. Problem hab ich das selbige... Darauf hin hab ich dann erstmal mein v1.9 Image eingespielt, weil hab ja nicht Lust alle paar min/stunden das ding neuzustarten..
Naja, den ganzen Server muss man nicht neu starten, um das Problem (vorläufig) zu beheben - das habe ich oben nur gemacht, um irgendwelche möglichen Quereffekte des Updates auszuschließen.
Ein
/etc/init.d/liveconfig restart(notfalls per Cron alle x Stunden aufgerufen) tut es auch und alle anderen Dienste laufen ungestört weiter (und auch der "Ausfall" von Liveconfig ist sehr kurz). Der Weisheit letzter Schluß ist das natürlich aber auch nicht, besser wäre es wenn es ohne solche Maßnahmen ginge.
Wir haben da tatsächlich was im Bereich des ACME-Clients gefunden - es handelt sich aber "nur" um virtuellen Speicher (VSZ, nicht RSS). Fehler ist behoben, Update gerade in Arbeit.
Scheint leider nicht alles gewesen zu sein - ich hab das Update heute Mittag gleich eingespielt und so vor 30 Minuten etwa den Server einmal komplett neu gestartet, um irgendwelche Quereffekte oder Reste alter Prozesse auszuschließen.
Zitatps aux | grep liveconfig
root 504 0.0 0.0 4492 1524 ? Ss 20:22 0:00 /usr/lib/liveconfig/lclogparse -c /etc/liveconfig/lclogparse.conf
root 1639 0.0 0.0 4216 672 ? S 20:22 0:00 /usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats
root 2233 0.0 0.0 44928 2628 ? Ss 20:22 0:00 /usr/sbin/liveconfig
livecon+ 2237 0.0 0.2 631088 8668 ? Sl 20:22 0:00 liveconfig [server]
root 2238 0.0 0.2 267596 10560 ? Sl 20:22 0:00 liveconfig [client]
root 4375 0.0 0.0 14192 2324 pts/0 S+ 20:30 0:00 grep liveconfig5 Minuten später
root 504 0.0 0.0 4492 1588 ? Ss 20:22 0:00 /usr/lib/liveconfig/lclogparse -c /etc/liveconfig/lclogparse.conf
root 1639 0.0 0.0 4216 672 ? S 20:22 0:00 /usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats
root 2233 0.0 0.0 44928 2628 ? Ss 20:22 0:00 /usr/sbin/liveconfig
livecon+ 2237 0.0 0.2 672068 8988 ? Sl 20:22 0:00 liveconfig [server]
root 2238 0.0 0.2 267596 10960 ? Sl 20:22 0:00 liveconfig [client]
root 5429 0.0 0.0 14192 2156 pts/0 S+ 20:36 0:00 grep liveconfigDer VSZ-Wert für liveconfig [server] steigt zwar langsam, aber kontinuierlich weiter an. das ist insofern mißlich, als dass dann irgendwann auch andere Prozesse Probleme mit dem virtuellen Memory bekommen.
Dann hätte das Serverlein ziemlich viel RAM, wenn das im Peak RSS wäre 
Vielen Dank!
Auffallend ist, dass der VSZ-Wert des Serverprozesses bei jedem Aufruf leicht höher ist
Aktuell wird das hier ausgegeben:
root 479 0.0 0.0 4492 1664 ? Ss Nov18 0:03 /usr/lib/liveconfig/lclogparse -c /etc/liveconfig/lclogparse.conf
root 42132 0.0 0.0 14188 2152 pts/0 S+ 12:29 0:00 grep liveconfig
root 43288 0.0 0.0 4216 676 ? S 07:25 0:00 /usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats
root 47770 0.0 0.0 44912 2592 ? Ss Nov25 0:00 /usr/sbin/liveconfig
livecon+ 47773 0.0 0.4 7968804 18292 ? Sl Nov25 0:03 liveconfig [server]
root 47774 0.0 0.2 267580 11028 ? Sl Nov25 0:02 liveconfig [client]Kann das sein, dass Liveconfig 2.0 ein Speicherleck hat?
https://www.evernote.com/l/AAm…Xgl94_GXIgSYOkB/image.png
Das Update (von 1.9 irgendwas - die vorherige aktuelle Version) habe ich am 17.11. abends gemacht, jeder "Zacken" nach unten deckt sich mit einem /etc/init.d/liveconfig restart
Der Server ist ein Debian 8.2 mit dem liveconfig-meta-Paket von hier.
Den übertragenen Hostnamen habe ich sogar schon in das Logfile bekommen, das ist nicht so dramatisch. Die AWStats-Konfiguration wäre dann aber doch eher kniffelig, die Frage ist auch ob man dann nicht in irgendwelche Ressourcen-Probleme rennt.
Nein, die Piwik-Lösung klingt nicht schlecht. Das kann man händeln, mit Piwik habe ich soweit auch Erfahrung (wenn auch noch nicht mit der API), zur Not lässt sich das auch skalieren und ich kann das relativ problemlos einbauen
Da tendiere ich momentan auch zu, zumal Piwik ja auch eine API für die Verwaltung hat (das wusste ich bisher nicht, ich dachte das betraf immer nur den Abruf von Auswertungen, aber man kann auch per API neue Sites anlegen etc.)
Einzelne Webs aka einzelne Logfiles würden das Problem denke ich insofern nicht lösen, als dass ich damit in das Problem der zu vielen offenen Dateien für den Apachen rennen würde - da ist ein einziges "großes" Logfile durchaus sympathisch
Hmm.. Und die Info, welche Domain es betrifft steht auch im Logfile gar nicht drin, wenn ich das richtig sehe :confused:
Muss ich mal weiter nachforschen, wie man das machen könnte. Danke auf jeden Fall schon mal für den Link
Mit freundlichen Grüßen
Markus Hagge
