Beiträge von kk

Zitat von mhagge

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

Sehr gut - geben Sie einfach Bescheid falls da was von LiveConfig drin auftaucht!

Zitat von mhagge

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

Wir werden mal ein Testsystem aufsetzen und versuchen das zu reproduzieren (inkl. ACME-Zertifikate). Dauert aber vermutlich 2-3 Tage, bis wir soweit sind.

Zitat

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?

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.

Zitat

Mir fällt ansonsten gerade noch auf, dass im /conf/acme-Verzeichnis fast 13000 Dateien sind - muss das so sein?

Sie können alle alten ACME-Authz problemlos löschen:

find conf/acme -type f -mtime +30 -delete

Ich dachte eigentlich dass LiveConfig das erledigt, werden wir prüfen...

Zitat von mhagge

[...] dauert es bei einer "Schreibezeit" von 2-3 Minute pro webx.conf also minimum 20 Minuten, eher mehr,[...]

Da scheint mir an dem System eher grundsätzlich etwas nicht zu stimmen. Eine komplette vHost-Konfiguration ist üblicherweise in wenigen Millisekunden komplett geschrieben, auch wenn die mehrere MB groß ist.

Verwenden Sie SQLite oder MySQL als Backend-Datenbank für LiveConfig?
Wie viele VirtualHost-Abschnitte enthält eine Apache-Konfiguration bei Ihnen?

Hallo,

ab sofort steht eine erste Preview-Version von LiveConfig v2.7.0 zum Download bereit. Es sind noch nicht alle neuen Funktionen in allen Details durchgetestet, also bitte noch nicht produktiv einsetzen.

Die wohl wichtigste Neuheit ist: LiveConfig unterstützt PHP nun auch via FPM (FastCGI Process Manager). Technisch betrachtet ist FPM das selbe wie FastCGI, allerdings läuft hier der Prozessmanager (der die PHP-Instanzen nach Bedarf startet und stoppt) als separater Prozess. Bei Apache macht das wenig bis keinen Unterschied gegenüber mod_fcgi, bei NGINX wird die PHP-Kontrolle damit aber wesentlich besser.
Die konfigurierten PHP-FPM-Instanzen werden sowohl von Apache als auch von NGINX aus gemeinsam verwendet - wer bislang also beide Webserver nutzt, spart künftig viele Ressourcen ein.
Um PHP-FPM zu nutzen, muss das Apache-Modul mod_proxy_fcgi aktiviert sein - dann kann man in den Vertragseinstellungen die PHP-Ausführung auf "FPM" einstellen.
WICHTIG: beim Umstellen bestehender Verträge ist darauf zu achten, dass die aktuell ausgewählten PHP-Versionen (unter "Hosting" -> "Domains" eingestellt) auch als FPM auf dem Server verfügbar sind. Ist eine PHP-Version eingestellt, für die keine FPM-Version vorhanden ist, dann ist PHP dort sicherheitshalber deaktiviert.
(ggf. muss für die Distributions-PHP-Pakete also das Paket "php-fpm" nachinstalliert werden)
Der Aufruf von "liveconfig --diag" zeigt nun auch für jede gefundene PHP-Version separat die CGI- bzw. FPM-Variante an:

[...]
 - PHP 7.2.8 (code='php72')
   CGI/FastCGI: /opt/php-7.2/bin/php-cgi
   FPM: /opt/php-7.2/sbin/php-fpm
        pool config: /etc/php-fpm/php72-fpm.d
   default php.ini: '/opt/php-7.2/etc/php.ini'
 - PHP 5.5.38 (code='php55')
   CGI/FastCGI: /opt/php-5.5/bin/php-cgi
   default php.ini: '/opt/php-5.5/etc/php.ini'
 - PHP 7.0.30 [DEFAULT] (code='php7')
   CGI/FastCGI: /usr/bin/php-cgi
   FPM: /usr/sbin/php-fpm7.0
        pool config: /etc/php/7.0/fpm/pool.d
   default php.ini: '/etc/php/7.0/cgi/php.ini'
[...]

Die zweite große Änderung betrifft die Installation von LiveConfig: mittels AutoDeploy kann die Installation besser automatisiert werden.
Wurde zudem während der Installation kein admin-Passwort festgelegt, dann landet man ab sofort beim ersten Aufruf der LiveConfig-Oberfläche in einem separaten "Onboarding"-Menü. LiveConfig generiert ein Startpasswort (wird in /root/LiveConfig.txt gespeichert) - mit diesem müssen dann ein (sicheres) admin-Passwort, der Lizenzschlüssel und optional Kontaktdaten des Administrators eingegeben werden, bevor man sich am LiveConfig selbst anmelden kann.

Daneben gibt es noch einige kleinere Änderungen und Verbesserungen, die im Changelog aufgeführt sind.

Viele Grüße & ein schönes Wochenende

-Klaus Keppler

Das Paket "liveconfig-meta" für Debian/Ubuntu wurde eben auf Version 0.6.0 aktualisiert.
Die Änderungen sind:

• mod_http2 wird automatisch aktiviert (inklusive Umstellung von mpm_prefork/mpm_worker auf mpm_event)
  WICHTIG: falls mod_php aktiviert sein sollte, wird nur eine Warnung ausgegeben (HTTP/2 bzw. mpm_event verträgt sich nicht mit mod_php).
• mod_proxy_fcgi wird automatisch aktiviert (wird für PHP-FPM benötigt, was LiveConfig ab der kommenden Version 2.7.0 unterstützt)

(siehe Quellcode)

Viele Grüße

-Klaus Keppler

Die PHP-Pakete wurden erneut aktualisiert (5.6.37-5, 7.0.31-4, 7.1.20-4, 7.2.8-4).
Folgende Änderungen gibt es mit dem Update:

• für PHP-FPM-Logs wird Logrotate konfiguriert (/etc/logrotate.d/php##-fpm)
• in die Lua-Konfigurationsdateien (/etc/liveconfig/lua.d/php##.lua) wurden die FPM-Parameter "start" und "stop" aufgenommen (in manchen Fällen muss LiveConfig die Prozesse ausdrücklich neu starten können)

Das war's auch schon.

Handelt es sich um ein Upgrade von Debian 8 auf Debian 9?

Wenn ja, dann wurde vermutlich "apt full-upgrade" nicht ausgeführt...

Die Fehlermeldung ist ja ziemlich klar: die mysql-Extension ist nicht verfügbar (aus welchem Grund auch immer).

Hatten Sie PHP-Pakete aus unseren "debian-test"-Repositories installiert? Wenn ja, dann einfach noch mal neu installieren, z.B.

apt purge php-7.0-opt && apt install php-7.0-opt

Ausführliche Infos zu unseren neuen PHP-Paketen: hier.

Zitat von dominikde

LiveConfig speichert in der Tabelle MAILBOXES in der Spalte MB_PASSWORD die Passwörter der Mail-Benutzer ab.

Ja, aber nur wenn entweder die "Selbstverwaltung"-Option aktiviert ist (also dass sich der Postfachbenutzer am LiveConfig anmelden darf), oder wenn das Postfach noch nicht auf dem Server angelegt ist. In allen anderen Fällen (also wenn LiveConfig selbst das Passwort nicht mehr braucht) wird es aus der Datenbank gelöscht. Prinzip Datensparsamkeit.

Zitat

Weiß jemand, in welchem Format (MD5, ...?) das Passwortformat ist?

Wesentlich komplexer. Da für den Mail-Service das Passwort im Klartext vorliegen muss (sonst funktionieren keine Challenge-Response-Verfahren) wird es Blowfish-verschlüsselt gespeichert. Der Schlüssel dazu ist recht komplex und nur LiveConfig selbst zugänglich.

Zitat

Hintergrund ist, ich möchte diese Benutzernamen und Kennwörter mit einer anderen Anwendung auslesen und abgleichen. Oder gibt es eine andere Art, an das Kennwort zukommen?

Über die Datenbank wird man (hoffentlich ;-)) nicht an das Passwort kommen, zudem es in vielen Fällen dort gar nicht für immer stehen wird.
Der allersauberste Weg wäre, direkt den Authentifizierungsservice von Dovecot zu nutzen (SASL) - die SMTP-Authentifikation vom Postfix läuft schließlich genauso ab.

Danke für den Hinweis, wurde eben behoben.
Das AppInstaller-Repo wurde am Freitag aktualisiert, der ownCloud-Installer wurde dabei offenbar versehentlich vergessen.

Zitat von sTeaLth

Ich habe die "alten" Debian Packete unter "Ubuntu 14.04.5 LTS" genutzt.

Für Ubuntu 14 haben wir nie PHP-Pakete angeboten - falls die da funktioniert haben sollten, war das purer Zufall (& viel Glück).
Sie können durchaus versuchen, die neuen Pakete manuell zu installieren (das geht vermutlich nur mit Download der einzelnen .deb-Dateien und dann "dpkg -i", evtl mit einer --force-Option). Aber alles ohne Garantie - das wird von uns NICHT unterstützt.

Compiliert wurden die "neuen" Pakete auf den selben Servern wie bisher. Das neue Packaging von Debian/Ubuntu nimmt die Abhängigkeiten allerdings viel genauer in die Paketinformationen mit auf.

Zitat von mhagge

es dauert eine Weile die .conf-Datei zu schreiben (runde 3 Minuten, trotz SSD).

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.

Zitat

Deswegen ist meine Vermutung ein Timing-Problem, vermutlich wird die Verifizierung versucht wenn die Konfiguration noch nicht verfügbar ist.

Nach dem Erstellen eines ACME-"Auftrags" werden automatisch ein CSR erzeugt sowie die ACME-Challenges beauftragt - das geschieht quasi in Echtzeit. Die Challenges werden anschließend in die Webserver-Konfigurationen übernommen und ein Reload angetriggert.
Frühestens 90 Sekunden nach dem Aktualisieren der Konfigurationsdateien wird dann bei Let's Encrypt die Prüfung der Challenges angestoßen (der Apache-Reload findet ja "normalerweise" nach max. 60 Sekunden statt). Bei größeren Werten für RELOAD_MAX müsste das (wenn ich mich richtig erinnere) entsprechend auch höher sein (also RELOAD_MAX+30sek).
In der Tat kann es dann also zu Timing-Problemen kommen, wenn der tatsächliche Reload entsprechend länger dauert. Wurde ein Challenge-Request mit einer endgültigen (also nicht temporären!) Fehlermeldung beantwortet, erfolgt keine automatische Wiederholung. In der Regel müsste es aber genügen, bei den Zertifikaten einfach erneut auf "speichern" zu klicken, dann müsste LC offene Challenges erneut anstoßen.

Wir haben bereits einen Konfigurations-Prototypen entwickelt, mit dem die Challenges ohne Reload des Apache verwaltet werden können (während gleichzeitig sichergestellt ist, dass Challenges nur für die jeweiligen Domains erreichbar sind). In LiveConfig v2.7 werden wir das nicht mehr hinein bekommen, aber bis v2.8 (Herbst) sollte es fertig sein.

Zitat von Mercator1972

Call to undefined function json_decode()

Die Extension "json" scheint nicht geladen zu sein.
Stammte die vorherige PHP-Version eventuell aus unserem "debian-test"-Repository?
Welche PHP-Version ist betroffen, und auf welcher Distribution genau?
Existiert die Datei /opt/php-#.#/etc/conf.d/json.ini?

Falls nicht, dann deinstallieren Sie das betroffene Paket komplett ("apt purge php-#.#-opt") und installieren es anschließend erneut.

Viele Grüße

-Klaus Keppler

Zitat von lulatsch66

Mangels pecl lässt sich so z.B. xdebug nicht mehr installieren. Gibt es dafür einen Grund bzw. einen workaround?

Der Grund ist: pecl macht nur dann Sinn, wenn man auch Entwicklertools (gcc usw.) auf dem Server installiert hat. In manchen Hostingumgebungen ist das nicht erwünscht.
Deshalb stecken pecl (sowie alle notwendigen Header etc.) nun in separaten "-dev"-Paketen, also z.B. "php-7.2-opt-dev". :cool:

Viele Grüße

-Klaus Keppler

Zitat von robby

Da muss ich direkt mal fragen. "Eigene" PHP-Versionen kann man aber trotzdem nach wie vor nutzen, auch mit FPM dann?

Ja, natürlich. In der Wiki-Seite ist beschrieben, wie die Registrierung dann ablaufen muss (Beispielcode php56.lua) - also lediglich ein komplexerer Parameter beim Aufruf der Funktion LC.web.addPHP()

Nicht dass hier ein Mißverständnis vorliegt: wir reden hier nicht von Tests.

Die neuen PHP-Pakete sind - wie bei uns üblich - zuerst im "debian-test"-Repository gelandet und wurden von dort aus durch uns und einige einzelne Kunden ausführlich durchgetestet.
Nachdem wir keine Probleme haben feststellen können, haben wir die Pakete in das normale Repository übernommen.

Die Hinweise sind nur für den Fall, dass irgendwo Probleme auftauchen sollten, die in unseren Umgebungen nicht aufgetreten sind.

Zitat von bfal

Ich hoffe die 50 Server sind nur Testsysteme

Warum? Haben Sie irgendwelche Probleme mit den neuen PHP-Paketen festgestellt?

Die neuen PHP-Pakete sind ab sofort freigegeben:
https://www.liveconfig.com/de/…-31-7-1-20-7-2-8)?p=16306

Hallo,

ab sofort stehen neue Versionen unserer PHP-Pakete für Debian/Ubuntu zum Download bereit (PHP-Version 5.6.37, 7.0.31, 7.1.20 und 7.2.8).

Bei diesen Paketen gibt es einige grundlegende Neuerungen:

• die Pakete werden nun komplett als "ordentliche" PHP-Pakete gebaut, d.h. alle Konfigurationsdateien (u.a. /opt/php-X.X/etc/) werden als solche verwaltet.
  Während des Upgrades wird mittels Prüfsummen verglichen, ob die .ini-Dateien früherer Installationen unverändert sind und dann ggf. stillschweigend ersetzt, ansonsten wird während des Upgrades gefragt, ob eine neuere Version davon installiert werden soll.
• die PHP-Pakete enthalten viele weitere Extensions, und viele bisherige Extensions sind nun als separate Module (Shared Objects) ausgelagert - die können somit einzeln aktiviert/deaktiviert werden.
• PHP 5.6 steht nun auch für Ubuntu 16.04 und 18.04 bereit
• APCu und ImageMagick steht nun auch für alle 7.x-Versionen zur Verfügung
• alle Pakete ab PHP 5.6 registrieren sich nun selbständig am LiveConfig (via /etc/liveconfig/lua.d), ein Eintrag in die custom.lua ist somit nicht mehr notwendig. Für ältere Pakete (5.5, 5.4, 5.3, evtl 4.4) wird das voraussichtlich in den nächsten Wochen folgen.
• die neuen Pakete (PHP 5.6/7.0/7.1/7.2) installieren nun ein Init-Script und ggf. einen systemd-Service, mit dem künftig PHP-FPM-Instanzen automatisch gestartet werden können. Die nächste LiveConfig-Version (v2.7) wird nämlich FPM unterstützen. (Daher ist dieses PHP-Update für LiveConfig wichtig, da für FPM eine etwas komplexere Registrierung an LiveConfig erforderlich ist)

Im Wiki folgt in Kürze noch eine Beschreibung, wie man zusätzliche PHP-Versionen unter CentOS bequem hinzufügen kann.

Sollte es während des Updates Probleme geben, schicken Sie uns bitte alle Bildschirmmeldungen die während des "apt upgrade" aufgetreten sind.
Im Notfall hilft es, die jeweilige PHP-Version komplett vom Server zu entfernen ("apt purge php-X.X-opt") und neu zu installieren.
Wir haben die Upgrades auf allen unterstützten Distributionen manuell durchgetestet und keine Fehler oder Warnungen dabei erhalten.
AUSNAHME: wer vorher eine PHP-Version aus dem "debian-test"-Repository installiert hatte, muss i.d.R. nach dem Update die Datei /opt/php-X.X/etc/conf.d/xml.ini löschen.

Um zu testen, ob eine bestimmte PHP-Version korrekt ausgeführt werden kann (inkl. aller Module), einfach wie folgt aufrufen: /opt/php-X.X/bin/php -v

Viele Grüße

-Klaus Keppler

Zitat von Mercator1972

Das Paket aus stable php-7.0-opt-imagick_3.4.3-1+stretch1_amd64.deb steckt die imagick.so nach /opt/php-7.0/lib/imagick.so

Ich habe das sicherheitshalber eben mal geprüft und kann das nicht bestätigen.
Das Paket php-7.0-opt-imagick_3.4.3-1+stretch1_amd64.deb (MD5: c9f3406347d603983006d5d4274e92b0) installiert die imagick.so an den richtigen Ort:

/opt/php-7.0/lib/php/extensions/no-debug-non-zts-20151012/imagick.so
(MD5: 89a1531cc2d86cd620fd3950a80657bf)

Handelt es sich vielleicht noch um eine veraltete Datei aus einer früheren Installation/Version?