Beiträge von kk

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.1.23 und 7.2.11 aktualisiert.

Viele Grüße

-Klaus Keppler

Der Fehler wurde gefunden. Die Datei /sbin/start-stop-daemon ist 0 Bytes groß (da ist vermutlich während der Installation irgendwas schief gelaufen). Das führte zu dem merkwürdigen Verhalten, dass man proftpd zwar direkt starten konnte, nicht aber über das Init-Script... (der start-stop-daemon hat einfach nichts gemacht, wurde aber "fehlerfrei" ausgeführt...)

Zitat von Marco

Das zu Grunde liegende Problem ist wohl, dass die Änderungen laut ChangeLog auf dem System vorgenommen werden, aber eine Aktualisierung der "liveconfig.conf" unterbleibt.

In die Richtung könnte es gehen. Das Upgrade-Script modifiziert mittels "sed"-Befehl die /etc/apache2/conf-enabled/liveconfig.conf. Wird aber ein zu großer Upgrade-Schritt gemacht (konkret also: von einer Apache-Installation, bei der die liveconfig.conf erst von /etc/apache2/conf.d/liveconfig.conf nach /etc/apache2/conf-enabled/ verschoben wird), dann kann das bei falscher Reihenfolge dazu führen, dass LiveConfig zuerst die Datei patchen will, die vom Apache-Upgrade aber erst danach verschoben wird...

Leider fehlt die Information, was genau auf den Servern aktualisiert wurde, und von welcher alten auf welche neue Version.

Zitat

In den aktualisierten Systemen steht die Zeile:
CustomLog "||/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats" LiveConfig

Bei der Neukonfiguration steht jedoch:
CustomLog "||/usr/lib/liveconfig/lclogsplit -i -w" LiveConfig

Die "neue" Zeile (wo also nur die Parameter "-i -w" verwendet werden) ist die aktuellere - diese gilt ab LiveConfig v2.6.0 (siehe Changelog, unter dem Abschnitt für v2.6 der Hinweis "Aktionen während eines Upgrades von älteren LiveConfig-Installationen")

Zitat

Neuerdings scheint die Datei "liveconfig.conf" falsch gesetzt zu werden. Bei einer Neuinstallation liegt diese direkt in dem Ordner "/etc/apache2/conf-enabled".

Das wird mit einem der nächsten Updates korrigiert; rein praktisch macht das keinen Unterschied - die Symlink-Lösung ist halt ordentlicher.

service proftpd stop
service proftpd start

Unsere PHP-Pakete sind "vanilla" - am Sourcecode wird nichts gepatched.
Lediglich für den Build-/Paketierungsprozess müssen wir in einigen Fällen kleinere Anpassungen vornehmen (z.B. damit die ganzen Extensions nicht auch noch als statische Bibliotheken (.a) mit eingepackt werden).

Die Hauptarbeit auf unserer Seite liegt also in der Automatisierung des Packagings - spezielle Source-Pakete gibt es daher nicht.

Viele Grüße

-Klaus Keppler

Kann man ja auch machen.
Wichtig ist, beim Anlegen der Subdomain für einen reinen TXT-Record im Tab "Webspace" das Häkchen bei der Checkbox "Webspace aktivieren" zu entfernen.

Also:

1. Button "neue Subdomain" anklicken
2. im Tab "Webspace" die Checkbox "Webspace aktivieren" deaktivieren
3. im Tab "eigene DNS-Einträge" einen DNS-Eintrag vom Typ "TXT" hinzufügen
4. dort die gewünschten Daten eingeben (TTL, Wert) und auf "speichern" klicken.

Kommt ganz darauf an, was für eine Subdomain (bzw. genauer: was für ein DNS-Resource-Record) angelegt werden soll.
In A/AAAA-Records sind keine Unterstriche erlaubt. CNAME, SRV oder TXT-Records mit Unterstrichen sind in LiveConfig aber möglich.

Viele Grüße

-Klaus Keppler

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 5.6.38, 7.0.32, 7.1.22 und 7.2.10 aktualisiert.
Tatsächlich gab es einige dieser Versionen schon vor ein paar Tagen, wir haben mit einem erneuten Update aber noch einen Fehler in der opcache.ini behoben - da wurde versehentlich opcache.validate_permissions noch nicht gesetzt - siehe Hinweise zu FPM in diesem Thread.
Außerdem gab es in den Ubuntu-Paketen oft noch eine Fehlermeldung beim Laden einer Extension (da konnte die PCRE-Bibliothek nicht geladen werden) - das ist nun auch behoben.

Viele Grüße

-Klaus Keppler

Hallo,

aufgrund eines Umzugs in neue Räume (innerhalb des Gebäudes) sind wir heute nur sehr eingeschränkt erreichbar. Wir gehen davon aus, dass die Technik bis ca. 15:00 umgezogen und wieder einsatzbereit ist.
Ich bitte also noch um ein klein wenig Geduld für aktuelle Tickets.
Anschrift und Telefonnummern bleiben unverändert.

Viele Grüße

-Klaus Keppler

Welche Ubuntu-Version genau verwenden Sie? Ubuntu 16 bringt PHP 7.0.30 mit, Ubuntu 18 PHP 7.2.7.
Zudem hat liveconfig-meta keine Abhängigkeit von PHP 7.1...

Zum Opcache-Fehler: ist das Paket "libpcre3" installiert?

Welche Fehlermeldung exakt meldet APT?

Zitat von antondollmaier

Dort ergibt PHP-FPM aber IMHO - selbst mit "ondemand" - wenig Sinn.

ACK. Shared Hosting ist mit FastCGI und den vielen "exotischen" Ansprüchen wesentlich entspannter (der eine Kunde braucht IonCube, der andere ZendGuard, der dritte sonstwas - und die sind bisweilen zueinander inkompatibel...).
FPM macht insbesondere bei Projekt-Servern Sinn, da FPM einfach eleganter skaliert als FastCGI. Schneller ist es nicht (auch wenn das immer wieder hartnäckig behauptet wird).
Mass Shared Hosting mit NGINX macht auch keinen Sinn (die Performance, die ein NGINX bietet, kann ein Shared Webspace gar nicht vernünftig nutzen, und man benötigt irre viel "Tuning", um handelsübliche CMS zum Laufen zu bringen...). Aber ich glaube ich schweife ab...

Zitat von antondollmaier

Die Alternative dazu ist, für jeden Benutzer einen komplett eigenen PHP-FPM-Prozess (und nicht nur einen eigenen Pool) zu erstellen.

Das hatten wir uns natürlich auch schon überlegt
Mit systemd und "socket activation" bekommt man das sogar halbwegs sauber hin, ohne dass hunderte idle-Pools die Prozessliste zumüllen. Aber leider eben nur mit systemd. Und übersichtlicher wird das ganze dann auch nicht. Die Idee behalten wir mal im Hinterkopf, bei "normalem" Mass-Shared-Hosting schießt das eher über's Ziel hinaus.

Und noch ein kurzer Nachtrag: FPM bietet gegenüber Apache mod_fcgid kaum nennenswerte Vorteile, lediglich die Skalierbarkeit lässt sich etwas besser konfigurieren. Die Kommunikation zwischen den Prozessen (Apache <-> PHP) ist bei beiden Verfahren sogar identisch.
Lediglich mit NGINX macht FPM aufgrund des eigenen Prozessmanagers das Leben erheblich einfacher.

Wer sich etwas tiefer mit Control Panels, Shared Hosting und FPM beschäftigt wird feststellen, dass FPM und insbesondere Caching (nicht nur Opcache, sondern auch APC) hierbei ein ernstzunehmendes Problem darstellen. Es gibt Control Panels, denen das völlig Schnuppe ist - LiveConfig zählt nicht dazu.

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.