Beiträge von kk

Hallo,

mit Blick auf LiveConfig v2.7.0 und der Unterstützung von PHP-FPM möchte ich auf zwei wichtige Informationen hinweisen:

1. PHP-FPM unterstützt aufgrund seiner Architektur keine zend_extension-Anweisung pro Vertrag. Das ist keine Einschränkung von LiveConfig, sondern von PHP (siehe #73408).
   Erweiterungen, die via zend_extension geladen werden müssen (z.B. xdebug oder IonCube-Loader) müssen also in eine "echte" php.ini aufgenommen werden und sind somit global aktiv. Der sauberste Weg hierfür ist es, im jeweiligen "conf.d"-Verzeichnis (z.B. /etc/php/X.Y/fpm/conf.d, /opt/php-X.Y/etc/conf.d) eine Datei wie "ioncube.ini" anzulegen und darin die notwendige zend_extension-Anweisung einzutragen.
   LiveConfig erzeugt derzeit in der jeweiligen FPM-Pool-Konfigurationsdatei die "php_admin_value[zend_extension]"-Anweisung, die wird aber ignoriert (wir werden die künftig also gar nicht erst rausschreiben).
   Das bedeutet: wir empfehlen, individuelle zend_extension-Anweisungen aus der php.ini-Verwaltung von LiveConfig zu entfernen und die Erweiterungen statt dessen global (via conf.d/###.ini) zu aktivieren - somit gibt es keinen Unterschied in der PHP-Umgebung wenn man zwischen FastCGI und FPM umschaltet.
2. LiveConfig wird während des Upgrades auf v2.7.0-r5082 zwei weitere Einstellungen in die php.ini-Verwaltung aufnehmen: opcache.file_cache=%HOME%/tmp und opcache.lockfile_path=%HOME%/tmp. Das ist zwingend notwendig, um Dateien innerhalb des gemeinsamen Caches von Opcache sauber voneinander zu trennen.
   Architekturbedingt teilen sich nämlich alle PHP-FPM-Prozesse einen gemeinsamen Shared-Memory-Cache (also über Kunden/Vertragsgrenzen hinweg). Bis Anfang 2017 war das sogar ein akutes Sicherheitsrisiko (siehe ausführliche Diskussion bei #69090).
   Mit FastCGI (mod_fcgid) gab/gibt es dieses Problem nicht, das betrifft nur FPM.
   Die von uns bereitgestellten PHP-Pakete enthalten in der Datei conf.d/opcache.ini ab sofort zusätzlich die Anweisung "opcache.validate_permission=1" (zur Sicherheits nochmal der Hinweis: das ist nur für FPM relevant, beim bisherigen FastCGI macht das keinen Unterschied!)
   Fazit: die von LiveConfig erstellte Opcache-Konfiguration sorgt dafür, dass die Opcache-Dateien im jeweiligen Verzeichnis der einzelnen Kunden bleiben.
   Trotzdem ist Opcache ein latentes Sicherheitsrisiko in Shared-Hosting-Umgebungen, da die Sicherheit hier auf Anwendungsebene (PHP) und nicht auf Betriebssystemebene realisiert wird. Schafft es jemand, einen PHP-FPM-Prozess zu "kapern", hat er u.U. Zugriff auf den gemeinsamen Opcache.
   Wer etwas paranoider ist, sollte ggf. die Option opcache.file_cache_only aktivieren. Dann werden PHP-Scripte nicht im Shared Memory, sondern ausschließlich auf Dateiebene gecached und sind somit sauber isoliert.

Die aktuellen PHP-Versionen (gestern gab es ein neues Release) sind eben frisch compiliert und stehen in Kürze in unseren Repositories bereit.

Viele Grüße

-Klaus Keppler

Hallo Herr Graupner,

vielen Dank für Ihre Hinweise! Bislang hatte LiveConfig OpenSUSE 15 noch nicht unterstützt, wir bauen das aber gerade ein (sollte dann mit v2.7.1 direkt unterstützt werden).

Viele Grüße

-Klaus Keppler

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.

Zitat von RB-Media-Group

wurde an der SSL Auswahl was verändert? Gemäß GUI wurde das richtige SSL Zertifikat ausgewählt, aber Apache wählt das SSL Zertifikat darunter.

An der Auswahl wurde nichts geändert, aber an der Konfigurationserzeugung. Fehler wird gerade behoben, Update folgt in wenigen Minuten...

Die Preview wurde eben noch mal aktualisiert (v2.7.0-r5075).

Wir testen derzeit noch die Umstellung von bestehenden Verträgen auf PHP-FPM - wenn nichts dazwischen kommt, erfolgt das Release noch diese Woche.

Viele Grüße

-Klaus Keppler

Catchall könnten wir über eine LCDEFAULTS-Einstellung global abschaltbar machen (ist ein überschaubarer Aufwand).

Was die externen Weiterleitungen betrifft: hier ist tatsächlich eine Blacklist geplant, um insbesondere Ziele bei gmail.com, t-online.de etc. zu blockieren, da Weiterleitungen dorthin häufig sehr problematisch sind.

Wir haben inzwischen in einer Testumgebung einen Vertrag mit mehreren tausend vHosts erzeugt und in dieser Konfiguration verschiedene Profiling-Analysen durchgeführt.
Wir werten die Daten aktuell aus, Anfang kommender Woche gibt's dann ein Update zu dem Thema.

Viele Grüße

-Klaus Keppler

Zitat von marinal

• Detected 'Debian GNU/Linux 7.11 (wheezy)'

Debian 7 ist End-of-Life und sollte NICHT mehr genutzt werden. Ich empfehle wärmstens, auf Debian 8 zu aktualisieren (tut auch gar nicht weh

Zitat

Laut App-installationsdatei ist nur PHP5.3 notwendig. Wo ist der Fehler? Muss das Installationsskript von PHP5.6 ausgeführt werden?

Die im Installer-Script angegebene Mindest-Version wird bislang weder gepflegt noch ausgewertet - die Angabe sagt also nichts aus.
ownCloud braucht mind. PHP 5.6.
Der AppInstaller führt /usr/bin/php aus - Sie könnten also /usr/bin/php in /usr/bin/php-5.5 umbenennen und einen Symlink von /usr/bin/php auf /opt/php-5.6/bin/php erstellen.

Viele Grüße

-Klaus Keppler

Sie könnten evtl. mal eine vHost-Konfiguration aktualisieren lassen und währenddessen in einer MySQL-Konsole den Befehl "SHOW PROCESSLIST;" ausführen. Ggf. taucht dort eine relativ lang laufende Query öfters mal auf...?

Einen festen Zeitpunkt kann ich noch nicht nennen, wir planen das aber für Version 2.8.0 ein (v2.7 enthält vor allem PHP-FPM und ist bereits im "Feature-Freeze"). Also etwa Herbst 2018.

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.