FcgidWrapper /var/www/web207/conf/php7/php-fcgi-starter .php
FcgidWrapper /var/www/web207/conf/php7/php-fcgi-starter .php5
Ja, das ist korrekt. Es wird da der "richtige" PHP-Interpreter ausgeführt; das mit dem ".php5" bedeutet nur, dass auch Dateien mit der Endung ".php5" von diesem PHP-Interpreter verarbeitet werden sollen.
So lange PHP in dem Webspace nicht als FPM konfiguriert ist, wird auch kein FPM benötigt - definitiv.
Im Zweifelsfall prüfen Sie bitte mal die vHost-Konfiguration in /etc/apache2/sites-enabled/<Vertrag>.conf und suchen dort nach der Zeile "# PHP configuration for this subscription:".
Wenn es beim Aufruf von ownCloud nur eine weiße Seite gibt, tritt wahrscheinlich ein Fehler während der PHP-Ausführung auf. Mit dem Apache-Errorlog und dem PHP-Errorlog lässt sich der auslesen.
(entweder in /var/log/apache2/error.log schauen, oder unter "Hosting" -> "Webspace" das Fehlerprotokoll für 24Std aktivieren; zudem in den php.ini-Einstellungen des Vertrags die php.ini-Option "log_errors" auf "on" setzen).
Im Zweifelsfall schicken Sie uns bitte mal die vHost-Konfiguration (/etc/apache2/sites-enabled/<Vertrag>.conf) und die Ausgabe von "liveconfig --diag" an support@liveconfig.com
Viele Grüße
-Klaus Keppler
FPM (bzw. php7.0-fpm) muss definitiv nicht installiert sein, um PHP via FastCGI (mod_fcgid) nutzen zu können. Es gab da sicher irgendeinen anderen Grund.
Sie können das Paket "php7.0-fpm" getrost deinstallieren. Starten Sie LiveConfig anschließend neu (um die Modul-Liste zu aktualisieren).
Viele Grüße
-Klaus Keppler
Welche Apache-MPM verwenden Sie? http/2 funktioniert nicht mit dem Prefork-MPM; empfohlen wird das Event-MPM.
Aber: wir haben inzwischen schon mehrfach die Rückmeldung erhalten, dass mod_http2 zumindest bei Apache unter Debian 9 und Event-MPM beim Download von großen Dateien (>300MB) Probleme macht (einige Hoster haben das derzeit bewusst deaktiviert).
Habe jetzt mal noch zusätzlich php7.0-fpm installiert, danach scheint es zu laufen, normal das man das zusätzlich noch braucht? Nur libapache2-mod-fcgid ging nicht^^
Ich kann mir eher vorstellen, dass php7.0-cgi gefehlt hatte und über Abhängigkeiten via php7.0-fpm mit installiert wurde.
ZitatInteressant im Admin Bereich ist, dass fcgid nen grünen Haken hat aber proxy_fcgi (PHP-FPM) nicht, obwohl ich php7.0-fpm installiert habe und es danach nun läuft?!
mod_proxy_fcgi ist ein separates Apache-Modul, das bei Debian standardmäßig nicht aktiviert ist. Man benötigt das, wenn man PHP-FPM nutzen möchte.
Noch etwas: unter "Hosting" -> "Webspace" können Sie die php.ini-Einstellungen bearbeiten. Aktivieren Sie dort die Option "log_errors" (also auf "On" stellen). Damit sollte in /var/www/<Vertrag>/logs/priv/ auch ein php_errors.log o.ä. geschrieben werden. Sofern beim Aufruf von ownCloud dann ein Fehler auftritt, sollte man dort weitere Infos finden.
Nein, owncloud braucht definitiv kein mod_php (davon ist allgemein dringend abzuraten).
Wenn Sie von mod_php auf FastCGI umgestellt haben, dann vermute ich, dass die ganzen Dateiberechtigungen nicht (mehr) stimmen.
Alle Dateien in /var/www/<Vertrag>/htdocs/ müssen dem Vertragsnamen/-Gruppe gehören, also bei "web1" z.B. dem Benutzer "web1" und der Gruppe "web1".
(mit mod_php sah das anders aus, da mussten die Dateien alle dem Webserver-User, also "www-data" gehören).
Um die Rechte anzupassen, führen Sie also z.B. so was aus:
chown -R webX:webX /var/www/webX/htdocs/*
(bzw. falls Sie ownCloud über den AppInstaller instaliert haben: chown -R webX:webX /var/www/webX/apps/*)
("webX" durch den jeweiligen Vertragsnamen ersetzen)
Viele Grüße
-Klaus Keppler
Hallo!
Vielen Dank für das große Interesse. Wir sind erst seit heute wieder "normal" im Büro, und haben leider noch einen Berg Arbeit zu erledigen. Wir sind nun dabei einen Demo-Server mit der v2.8 vorzubereiten und die ganzen Änderungen/Neuerungen zusammenzufassen; bis Ende der Woche sollte das dann online gehen.
Wir arbeiten mit Hochdruck an der Freigabe!
Viele Grüße
-Klaus Keppler
Exakt.
Soweit ich weiß wird in Postfix derzeit an SNI (Server Name Indikation) gearbeitet - damit könnte man dann für jede gewünschte MX-Domain ein eigenes Zertifikat anlegen. Da es ja aber für jede IP auch nur einen Reverse-DNS-Namen geben kann, macht das in der Praxis wenig Sinn.
Evtl. wäre es eine Option, AutoConfigure/AutoDeploy einzurichten (was nicht ganz trivial ist); dann "sehen" die Kunden den Mailservernamen häufig gar nicht mehr.
Ich finde hier kein Support-Ticket zu dem beschriebenen Problem.
Was taucht denn genau alles in /var/log/mail.log auf, wenn eine E-Mail eintrifft?
(vor dem Eintrag von lcsam sollten jeweils die Meldungen von SpamAssasin (spamd) stehen).
Einizige Möglichkeit aktuell: die Änderungen in der FPM-Konfigurationsdatei (in diesem Fall also /etc/php-fpm/php72-fpm.d/test.conf) vornehmen, und die Datei anschließend mit "chattr +i" schreibschützen.
Wir planen aber bereits eine Möglichkeit, die FPM-Einstellungen individuell konfigurierbar zu machen (z.B. auch wenn man einen anderen Prozessmanager verwenden möchte).
Hallo Herr Keppler,
wann wird die Funktion bereitgestellt?
Wie in Beitrag #16 geschrieben, ist das Feature in v2.8 enthalten. Wir nähern uns der Freigabe mit großen Schritten.
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.1.27, 7.2.16 und 7.3.3 aktualisiert.
Viele Grüße
-Klaus Keppler
Hallo liebe LiveConfig-Anwenderinnen und -Anwender!
Am Mittwoch, dem 27. März werden wir im Rahmen des CloudFests die Version 2.8 von LiveConfig offiziell präsentieren.
Wie bereits angekündigt hat sich u.a. im Bereich der SSL-Verwaltung viel getan. So haben wir mit einem der größten Anbieter von SSL-Zertifikaten in Deutschland, der CertCenter AG, eine komplett automatisierte Bestellabwicklung von OV/EV-Zertifikaten integriert - inklusive SSL-Upselling und dem kostenlosen "AlwaysOnSSL".
Zusammen mit der CertCenter AG laden wir daher zu einem speziellen Launch-Event ein, an dem wir die neue SSL-Verwaltung vorstellen werden.
Im Anschluss an eine kurze Präsentation werden wir gemeinsam das wunderschöne Straßburg per Schiff erkunden. Sie haben dabei die Möglichkeit, sich mit dem LiveConfig-Team, den Spezialisten von CertCenter und den anderen Teilnehmern in entspannter Atmosphäre auszutauschen und Straßburg bei Nacht zu erleben. Auch Vertreter von CAs stehen Ihnen an dem Abend für alle Fragen rund um SSL-Produkte zur Verfügung.
Kulinarische Spezialitäten aus dem Elsass sorgen für das leibliche Wohl - auch mal außerhalb des Europaparks.
Es sind noch Restplätze für diese Veranstaltung verfügbar, die nach "first come, first serve" vergeben werden. Zur Anmeldung registrieren Sie sich bitte unter https://launch.liveconfig.com
Zeitplan:
Bei Fragen stehen wir Ihnen unter launch@liveconfig.com zur Verfügung.
Viele Grüße
-Klaus Keppler
Datenschutzhinweis: die bei der Anmeldung bzw. Kontaktaufnahme erfassten Daten werden von der Keppler IT GmbH und der CertCenter AG zum alleinigen Zweck dieser Veranstaltung gespeichert und anschließend gelöscht. Es erfolgt keine Weitergabe an Dritte.
Hallo Herr Keppler,
seit zwei bis drei Wochen gibt es eine #5244 als Preview, aber keine Ankündigung dazu.
Was verbirgt sich denn hinter der Version?
Die SOAP-Funktionen HostingSubscriptionEdit und HostingSubscriptionGet akzeptieren bzw. liefern mit diesem Update noch einen Parameter "phpini", um somit php.ini-Einstellungen via API bearbeiten zu können. Das Ganze ist noch nicht ausführlich getestet, wurde aber für einen Sonderfall in einem größeren Rollout kurzfristig benötigt. Die Änderungen werden in den nächsten Tagen noch dokumentiert und getestet, dann wird das in v2.8 "offiziell" enthalten sein. Weitere Änderungen enthält diese Version nicht.
<FilesMatch ".+\.(php[3457]?|pht|phtml|phps|pl|py|pyc|pyo|sh)$">
RewriteEngine On
RewriteRule .+\.(php[3457]?|pht|phtml|phps|pl|py|pyc|pyo|sh)$ - [F,L]
</FilesMatch>
Schaut plausibel aus. Zumal wenn Ihre Tests positiv verlaufen sind, wüsste ich nicht was dagegen sprechen sollte.
Code<info@xxxxx.de>: Recipient address rejected: Domain disabled (in reply to RCPT TO command)
Wie die Meldung schon sagt: die Domain ist deaktiviert. Soweit ich weiß müsste diese Meldung nur dann erscheinen, wenn im LiveConfig beim betroffenen Vertrag E-Mail deaktiviert wurde.
(also mal auf "Vertrag bearbeiten" klicken und schauen, was bei "Status" eingestellt ist (aktiv/gesperrt/deaktiviert).
Viele Grüße
-Klaus Keppler
Also, Drupal trickst da ganz schön mittels .htaccess herum.
Vereinfacht gesagt: in der .htaccess-Datei im Hauptverzeichnis wird eine RewriteRule gesetzt, welche Zugriffe auf nicht vorhandene Dateien pauschal durch index.php routet. Die Rewrite-Anweisungen in sites/default/files/.htaccess setzen alle anderen RewriteRules zurück - daher kommt es zu einem "403".
Die Lösung ist also, das Routing nicht vorhandener Dateien auf die /index.php auch in die untergeordnete .htaccess aufzunehmen:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ /index.php [L]Damit werden die Thumbnails wieder korrekt beim ersten Aufruf erzeugt. Wir werden das in unsere Doku mit aufnehmen.
Bei CloudFest werden wir uns zudem mal direkt mit den Drupal-Leuten über die Problematik unterhalten. 
Hallo,
anhand einer NGINX-Konfiguration für Drupal vermute ich, dass das am URL-Rewriting liegt: gedacht ist das so, dass wenn ein Zugriff auf den Image-Cache erfolgt und die Zieldatei aber (noch) nicht existiert, dass der Aufruf dann über die index.php geroutet werden soll (damit Drupal das gewünschte Bild dynamisch erzeugt).
Die aktuelle RewriteRule sollte das aber eigentlich auch gar nicht verbieten...
Wir werden mal versuchen, das mit einer Drupal-Testinstallation zu reproduzieren. Details folgen dann in Kürze...
Viele Grüße
-Klaus Keppler
Leider hat der eine sehr negative Auswirkung:
Durch den Flag [F] werden alle Scripten abgebrochen, die auf den Files-Folder zugreifen. Viele Bild-Uploads, die in Drupal durchgeführt werden, legen automatisch von den hochgeladenen Bildern Styles an:
So werden z.B. automatisch Bilder als Thumbnails in 150 x 150 Pixel erstellt [...]
Die o.g. RewriteRule sollte nur dann Zugriffe verbieten, wenn die abzurufende Datei direkt eine der aufgeführten Endungen (.php/.pl/.sh/usw) hat.
Eine .jpg-Datei, die sich in dem Verzeichnis befindet, müsste problemlos abrufbar sein.
Legen Sie testweise mal in sites/default/files/ eine Datei namens "test.txt" mit irgendeinem Inhalt an, und versuchen Sie anschließend, diese über den Browser aufzurufen.
Welche Fehlermeldung exakt bekommen Sie? (403 forbidden oder 500 internal server error?)
ZitatHabt Ihr andere Vorschläge, wie man die Sicherheitslücke stopfen kann?
Danke und Viele Grüße
Wolfgang
Das Hauptproblem ist Drupal selbst, da es aktiv in die Serverkonfiguration eingreifen möchte. Dieser Ansatz ist gut gemeint, aber leider nicht zu Ende gedacht (z.B. sind NGINX .htaccess-Dateien völlig schnuppe).
Wenn Sie einen komplett eigenen Server betreiben (also quasi nur einen einzigen Webspace-Vertrag auf dem Server angelegt haben), dann könnte man SetHandler dort erlauben (die Lücke wäre dann quasi wieder offen, könnte aber nicht aktiv durch "fremde" Kunden ausgenutzt werden).
Ich vermute auf den ersten Blick, das irgendwas mit der RewriteRule oder der restlichen .htaccess-Datei nicht stimmt und deshalb der Zugriff auf die temporären Dateien nicht funktioniert - da gibt es also wahrscheinlich eine recht einfache Lösung.
Viele Grüße
-Klaus Keppler
