Kurze Rückfrage: Aktuell ist ja 2.7.4-r5214 - ist dort der Commit r5157 (vgl https://www.liveconfig.com/de/…6889&viewfull=1#post16889) schon drin enthalten?
Nein, leider nicht - die 2.7.4 ist ein reines Sicherheits-Update und enthält diese Funktion daher noch nicht. 
Guten Morgen,
Hat jemand eine kurze und knappe Anleitung parat?
apt install php-fpmAlso im Prinzip nur die PHP-FPM-Pakete nach installieren. Die PHP-Pakete von LiveConfig enthalten jeweils bereits die FPM-Variante. Mit "liveconfig --diag" können Sie sich alle PHP-Versionen ausgeben lassen, da wird dann auch jeweils angezeigt ob diese FPM unterstützt.
ZitatMit der Umstellung auf "FPM" in den Angeboten allein ist es ja nicht getan. Es kursieren im Internet teilweise verschiedene Anleitungen, die untereinader variieren.
Was LiveConfig betrifft, genügt es normalerweise tatsächlich, die Angebote bzw. Verträge auf FPM umzustellen. Erweiterungen spielen keine Rolle (ob Extensions für CGI oder FPM installiert wurde ist egal, die liegen alle in den selben Verzeichnissen).
Wichtig ist vor allem, dass Sie FPM nur mit LiveConfig ab v2.7.4 nutzen (nur dann ist die Konfiguration sicher).
Da ich PHP7.2 laufen habe gibt es ja zum Glück kein mysql_connect mehr sondern mysqli, warum ist denn die Applikation so brutal alt?
Das ist leider die Gratwanderung...
LiveConfig unterstützt ja alle großen Distributionen auch in der LTS-Version - konkrekt z.B. CentOS 6 (PHP 5.3!) oder Ubuntu 14 (PHP 5.5). Da ist eben standardmäßig kein aktuelles PHP verfügbar.
Wir haben aber bereits auf der Roadmap, den Installer grundlegend zu überarbeiten, so dass je nach verfügbarer PHP-Version entsprechend aktuellere App-Versionen installiert werden können (damit legen wir voraussichtlich ab April/Mai los).
ZitatKann ich die irgendwo selber einspielen oder werden die extern bezogen?
Contao wird heutzutage meistens über den "Contao Manager" per Shell installiert (mit "composer"). Achten Sie ggf. darauf, das opcache-Modul zu deaktivieren oder die php.ini-Option "opcache.file_cache_only=On" zu setzen - siehe Contao-Manager Issue #347.
Für alle CMS-Entwickler die hier eines Tages mal mitlesen: es ist BAD PRACTICE, mittels .htaccess in die Serverkonfiguration einzugreifen. Der Schutz via SetHandler ist nett gemeint, verpufft aber sobald man z.B. NGINX einsetzt. Letztendlich wird zudem nur am Symptom herumgepfuscht (Ausführung von Dateien, die irgendwie im Webspace gelandet sind) als die eigentliche Ursache zu vermeiden (durch eine anständige Architektur, z.B. Speicherung reiner Nutzdaten außerhalb des Webspace-Roots).
Achtung: NEOS ist auch betroffen, dort wird der SetHandler auch verwendet
Danke für den Hinweis, wir werden das mit in die Doku aufnehmen.
Hmm, der Befehl FcgidWrapper ist ärgerlicherweise bei Apache nicht in den FileInfo-Overrides dokumentiert, sonst hätten wir den mit aufgenommen.
Am einfachsten dürfte es sein, wenn Sie die Datei /usr/lib/liveconfig/lua/apache.lua bearbeiten und in Zeile 135 den Befehl "SubstituteMaxLineLength" durch "FcgidWrapper" ersetzen (*). Danach müssten Sie LiveConfig neu starten und den betroffenen Vertrag neu speichern (damit die vHost-Konfiguration aktualisiert wird).
Wir werden FcgidWrapper beim nächsten Update auch mit in diese Liste aufnehmen (die Änderung ist daher quasi "updatesicher").
Sicherheitstechnisch spricht aktuell nichts gegen FcgidWrapper, da hier die "normalen" suexec-Schutzmechanismen greifen.
Viele Grüße
-Klaus Keppler
*) es hilft NICHT, die Anweisung "FcgidWrapper" einfach an die Liste anzufügen - nein, dafür muss leider ein anderer Eintrag dran glauben. Es gibt vermutlich einen Bug in Apache, welcher die maximale Länge der Zeile "AllowOverrideList" implizit begrenzt (laut Doku kann eine einzelne Config-Zeile max. 16MB groß sein, in der Praxis wird sie aber irgendwo klammheimlich (ohne Log-Meldung) abgeschnitten. Mehr als das, was LiveConfig aktuell rausschreibt, ist offenbar nicht drin.
auf dem Testserver ist und war bereits 2.7.4 r5214 installiert. Wir werden es weiterhin beobachten.
Dann war aber trotzdem irgendeine frühere Testversion aus dem Repo (r5210 oder r5212) mal installiert, sonst wäre das o.g. Problem nicht aufgetreten.
Es werden nun nicht nur SET HANDLER bemängelt, sondern auch:
AddDefaultCharSet
FileETag
Dann haben Sie eine frühere LiveConfig-Version aus dem Test-Repo installiert (vermutlich v2.7.4 <r5214).
Das Test-Repository kann immer wieder mal instabile Versionen enthalten, wir raten daher DRINGEND davon ab, dieses Repository für die "regulären" Server zu nutzen.
In diesem Fall müssen Sie folgenden SQL-Befehl in der LiveConfig-Datenbank ausführen:
UPDATE LIVECONFIG SET LC_VALUE='0005102' WHERE LC_KEY='dbschema' AND LC_VALUE = '0005103';Installieren Sie anschließend die aktuelle Version (2.7.4-r5214).
Viele Grüße
-Klaus Keppler
[UPDATE 20.08.2019]
Mit LiveConfig v2.8.0 haben wir eine andere Lösung zur Vermeidung der zugrundeliegenden Sicherheitsprobleme implementiert.
SetHandler und "AllowOverride FileInfo" sind mit LiveConfig v2.8 also wieder problemlos (und risikolos) möglich.
[ENDE]
Hallo,
kürzlich hat uns ein Kunde auf ein mögliches Sicherheitsrisiko in der Apache-Konfiguration aufmerksam gemacht. Nach kurzer Prüfung konnten wir das Problem bestätigen und haben seitdem einen entsprechenden Patch erarbeitet.
Das Problem ist, dass es sich hier um keinen klassischen "Bug" handelt, sondern Apache in einem bestimmten Zusammenhang schlicht keine Sicherheitsprüfung vornimmt. Bevor wir die Details näher beschreiben möchten wir aber allen Kunden noch genügend Zeit geben, um das Update zu installieren.
Besonders auf Servern, auf denen PHP-FPM läuft, sollte dieses Update möglichst zeitnah eingespielt werden.
Es besteht kein Risiko "von außen". Ein möglicher Angriff müsste lokal erfolgen und setzt einige Kenntnisse über die jeweilige Serverkonfiguration voraus - wir schätzen die Sache also nicht als hochkritisch, aber dennoch ernst ein.
Weniger kritisch ist das Thema bei Servern, bei denen PHP-FPM nicht aktiviert ist oder nicht genutzt wird - aber auch hier empfehlen wir das Update bei Gelegenheit durchzuführen. Reine NGINX-Webserver sind nicht betroffen.
Das Update (v2.7.4) aktualisiert automatisch alle Apache-vHost-Konfigurationen wie folgt:
Die Anweisung "SetHandler" ist damit ab sofort nicht mehr in .htaccess-Dateien erlaubt!
Jede "normale" Web-Anwendung benötigt keine SetHandler-Anweisung in .htaccess. Traurige Ausnahme ist Drupal: dort enthält u.a. /sites/default/.htaccess entsprechende SetHandler-Anweisungen, um die Ausführung von hochgeladenen Dateien zu verhindern (was ohnehin ein merkwürdiges Sicherheitskonzept ist, aber da hat Drupal noch ganz andere Probleme...).
Informationen zur .htaccess-Thematik bei Drupal haben wir (white-labeled) vorab hier bereitgestellt: https://hostinghandbuch.de/apps.drupal.htaccess
Am Ende dieser Seite ist auch ein Aufruf aus find und sed angegeben, mit dem man alle Drupal-.htaccess-Dateien auf einem Server rekursiv patchen kann (Ausführung auf eigene Gefahr!).
Bei Multi-Server-Umgebungen ist es egal, ob das Update zuerst auf dem Server oder auf den Clients installiert wird.
Wir empfehlen Ihnen folgendes Vorgehen:
find /var/www -type f -name .htaccess -exec grep -Hi "^\s*sethandler" {} \;find /var/www -type f -name .htaccess -exec \
sed -e 's/^\(\s*Options\s\+\)+FollowSymLinks/\1+SymLinksIfOwnerMatch/i' \
-e 's/^\(\s*\)\(SetHandler Drupal_Security_Do_Not_Remove.*\)/\1# \!\!\! SetHandler disabled - see https:\/\/hostinghandbuch.de\/apps.drupal.htaccess\n\1#\2\n\1RewriteEngine On\n\1RewriteRule .+\\.(php[3457]?|pht|phtml|phps|pl|py|pyc|pyo|sh)$ - [F,L]/i' \
-i {} \;
[LIST=|INDENT=2]
[*]dann für alle restlichen .htaccess-Dateien:
find /var/www -type f -name .htaccess -exec \
sed -e 's/^\(\s*SetHandler\)/# \!\!\! SetHandler disabled - see https:\/\/hostinghandbuch.de\/apps.drupal.htaccess\n#\1/i' -i {} \;
[/LIST]
Bei Fragen stehen wir gerne zur Verfügung.
Viele Grüße
-Klaus Keppler
Hello,
our PHP packages for Debian/Ubuntu have been updated to version 7.2.15 and 7.3.2.
As FPM and OpCache have had (or still have?) some issues with PHP 7.3, we recommend to upgrade as soon as possible.
Best regards
-Klaus Keppler
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.15 bzw. 7.3.2 aktualisiert.
Da insbesondere FPM und OpCache bei PHP 7.3 noch einige Stabilitätsprobleme hatten (haben?), empfehlen wir, das Update zeitnah durchzuführen.
Viele Grüße
-Klaus Keppler
Starten Sie bitte mal LiveConfig (bzw. falls Multi-Server: nur den lcclient) auf dem betroffenen Server neu, und prüfen dann nach ca. 15-20 Minuten, ob dann Daten erscheinen.
Machen Sie zudem eine Kopie von /var/lib/liveconfig/smtp.stats und prüfen ebenfalls nach ca. 15 Minuten mal per "diff", ob sich in der Datei etwas geändert hat.
(diese beiden Ansätze helfen dabei, die mögliche Ursache weiter einzugrenzen)
Prüfen Sie sicherheitshalber per "ps aux | grep lclogparse" ob der Prozess auch wirklich läuft (systemd alleine ist nicht vertrauenswürdig 
Wenn ja, prüfen Sie ob /var/lib/liveconfig/smtp.stats aktuell ist (sollte max. alle 5 Minuten aktualisiert werden). Da sollten dann auch die aktuellen Statistikdaten (roh) drin stehen.
Zuletzt ggf. noch die lclogparse-Konfiguration prüfen: /etc/liveconfig/lclogparse.conf (am besten mal per "diff" mit einer Datei von den anderen Servern vergleichen, wo's funktioniert).
Bitte prüfen Sie, ob auf den betroffenen Servern der Prozess "lclogparse" läuft (der kümmert sich darum, aus den Mail-Logs die Statistiken zu erzeugen).
Kommt mit der nächsten Version (2.8).
(um genau zu sein: wurde in r5157 implementiert, es gibt dann einen LCDefault-Schlüssel "mail.forwards.blacklist", mit dem man bestimmte Domains als Weiterleitungsziel verbieten kann)
Nachtrag: ein Dropdown zur Auswahl lokaler Domains als Ziel haben wir als Feature Request mit aufgenommen. Da kam noch die Idee hinzu, dass Admins zusätzliche Weiterleitungen frei anlegen können (damit man z.B. "hostmaster@example.org" auf eine zentrale Adresse beim Webhoster umleiten kann).
Nicht nur das. NGINX kann (wenn er nicht als "www-data" läuft) überhaupt nicht auf die Webspace-Verzeichnisse zugreifen und somit keinen Content ausliefern.
Nginx läuft unter folgenden Rechten:nginx/nginx
Das wird vermutlich genau das Problem sein.
/var/www/<Vertrag>/htdocs/ gehört <Vertrag>:www-data (mode=0750), der User "nginx" kommt da also nicht rein.
Unter Debian ist es üblich, dass NGINX auch als www-data:www-data läuft. Das müsste also angepasst werden, dann sollte alles funktionieren.
PHP 7 unter Ubuntu 14 wird dann ohnehin eine Herausforderung, weil die meisten von PHP7 benötigten Bibliotheken gar nicht unter Ubuntu 14 verfügbar sind (einfachstes Beispiel: OpenSSL 1.1).
Ich empfehle dringend ein Dist-Upgrade auf Ubunru 16, damit hält man sich viele Probleme vom Hals. Und es tut auch gar nicht weh.
Naja, im einfachsten Fall nur "./configure" ausführen. Alles weitere kommt eben darauf an, was man braucht und wo PHP installiert werden soll.
Es würde daher auch nichts nutzen, wenn ich die configure-Aufrufe für die von uns bereitgestellten Pakete heraussuche - die Parameter variieren zwischen allen Distributionen und den zu bauenden Extensions.
Vom Bau eigener PHP-Pakete rate ich daher dringend ab, so lange man nicht genau weiß was man tut.
Lieber unsere Pakete oder die von deb.sury.org verwenden.
Immer wenn ein "500 Internal Server Error" generiert wird, erzeugt Apache auch einen Eintrag in der /var/log/apache2/error.log (bzw. wenn im LiveConfig unter "Webspace" der Punkt "Fehlerprotokoll aktivieren" eingeschaltet ist, im dortigen error.log).
Diese Fehlermeldung hilft sicher weiter.
