Bei PHP 5.6 bzw. PHP7 auch noch?
Was sagen die LiveCOnfig-Logs nach einer Änderung der PHP-Version?
Bei PHP 5.6 bzw. PHP7 auch noch?
Was sagen die LiveCOnfig-Logs nach einer Änderung der PHP-Version?
Ist proxy_fcgi aktiviert?
Alles anzeigen
suphp-common:
Installiert: 0.7.2-0ubuntu1
Installationskandidat: 0.7.2-0ubuntu1
Versionstabelle:
*** 0.7.2-0ubuntu1 100
100 /var/lib/dpkg/status
kommt also aus dem lokalen Storage und wurde nicht über die Stretch-Repositories installiert.
Ich würde kein suPHP mehr nutzen.
libapache2-mod-suphp 0.7.2-0ubuntu1 amd64 Apache2 module to run PHP scripts with the owner permissions
suphp-common 0.7.2-0ubuntu1 amd64 Common files for mod suphp
Und das sind wirklich die Debian-Pakete?
es gibt aber auch noch andere schöne Töchter, wie z.B. Ubuntu :-p
Wheezy und Trusty sind in etwa gleich alt. Danach gibt es auch dort kein suPHP mehr.
suPHP war eigentlich nur ein Behelf. Es gibt kein einziges Argument für suPHP und gegen FastCGI.
Nochmal die Frage: warum überhaupt suPHP?
Bei FastCGI gibt es zwangsweise mindestens eine laufende PHP-Instanz pro Vertrag und pro PHP-Version. FPM ist hier flexibler und ermöglicht es, auch den "ersten" benötigten PHP-Interpreter nur bei Bedarf zu starten. Bei Shared-Hosting ermöglicht das somit (theoretisch) eine höhere Kundendichte pro Server, insbesondere wenn der Trend zu vielen verschiedenen PHP-Versionen gleichzeitig geht.
Ich glaube, das sollte genau andersrum sein.
Bei Fcgid läuft normal kein einziger PHP-Prozess - solange, bis die erste Anfrage für den VirtualHost kommt.
Der FPM-Pool hat selbst im "onDemand"-Modus noch einen Haupt-Prozess aktiv, der immer läuft.
Oder bin ich komplett auf dem falschen Dampfer?
SuPHP lief bis zum Update ohne Probleme, mit FastCGI geht nun die Versionsauswahl wieder.
Wurde in der Richtung was verändert?
Nachdem suPHP gar nicht mehr verfügbar sein sollte, eben weil es "suphp-common" seit Jessie gar nicht mehr gibt, ist das doppelt interessant.
Einfach überall von suPHP auf FastCGI umstellen. Erspart einige Probleme, die suPHP hat(te).
Solange das Zertifikat nicht auf "localhost" ausegstellt ist (was ich vermute), wird das nicht funktionieren.
Daher sagte ich ja, dass RoundCube als SMTP-Server eben nicht "localhost" nehmen soll, sondern den Servernamen, auf den das SMTP-Zertifikat ausgestellt ist.
ZitatIm smtp debug log steht:
CodeAlles anzeigen[17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 220 server1.xxx ESMTP [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Send: EHLO webmail.xxx [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250-server1.xxx [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250-PIPELINING [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250-SIZE 104857600 [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250-ETRN [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250-STARTTLS [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250-ENHANCEDSTATUSCODES [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250 8BITMIME [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Send: RSET [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 250 2.0.0 Ok [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Send: QUIT [17-Oct-2018 12:11:48 +0200]: <c9f83eph> Recv: 221 2.0.0 Bye
Postfix erfordert TLS/STARTTLS, andernfalls ist kein Versand möglich.
Also den SMTP-Server umstellen auf:
(oder auf was auch immer euer SSL-Zertifikat ausgestellt wurde)
Was passiert, wenn via "telnet -6 localhost 25" getestet wird?
Wird als Host in RoundCube wirklich "ssl://" oder "tls://" verwendet?
Die erste, und mir liebste, wäre es überhaupt keine Großbuchstaben in den Hostingverträgen mehr zu erlauben.
Nachdem das tendentiell auch bei MySQL-Datenbanken/Benutzern zu Problemen führt: *signed*
Die Ausgabe sagt folgendes
Ist das ein Debian Stretch? Oder noch Jessie? Bei Stretch sollte das so aussehen:
root@v5659:~# systemctl status proftpd
● proftpd.service - LSB: Starts ProFTPD daemon
Loaded: loaded (/etc/init.d/proftpd; generated; vendor preset: enabled)
Active: active (running) since Thu 2018-10-04 15:32:13 UTC; 2h 39min ago
Docs: man:systemd-sysv-generator(8)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/proftpd.service
└─780 proftpd: (accepting connections)
Und da läuft der FTPd auch.
Aber gut:
- läuft der Dienst überhaupt auf Port 21 (lsof -i :21)?
- läuft proFTPd überhaupt (ps aux| grep -i ftp)
- was steht in der /var/log/proftpd/proftpd.log?
Wahrscheinlich läuft der FTP-Daemon nicht.
Hat jemand einen Tipp?
Firewall, Prozess-Status, ...
Was steht denn in den Logs dazu?
Die Idee behalten wir mal im Hinterkopf, bei "normalem" Mass-Shared-Hosting schießt das eher über's Ziel hinaus.
Dort ergibt PHP-FPM aber IMHO - selbst mit "ondemand" - wenig Sinn.
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.
Die Alternative dazu ist, für jeden Benutzer einen komplett eigenen PHP-FPM-Prozess (und nicht nur einen eigenen Pool) zu erstellen.
Ob das den Aufwand Wert ist, sei dahingestellt.
Ansonsten - mal wieder - vielen Dank für die detailreichen Ausführungen!
Gilt dann halt nur für neu angelegte Accounts.
Oder über apache.configureVHost() und LC.fs.is_dir().