Beiträge von antondollmaier

  • Php-fpm

    Zitat von kk

    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?

  • Preview: LiveConfig 2.7.0

    Zitat von RB-Media-Group

    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).

  • Roundcube und Liveconfig

    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.

  • Roundcube und Liveconfig

    Zitat

    Im smtp debug log steht:


    Postfix erfordert TLS/STARTTLS, andernfalls ist kein Versand möglich.



    Also den SMTP-Server umstellen auf:


    Code
    $config['smtp_server'] = 'tls://%h';


    (oder auf was auch immer euer SSL-Zertifikat ausgestellt wurde)

  • Migration LiveConfig -> Liveconfig

    Zitat von weltmeister

    Die Ausgabe sagt folgendes


    Ist das ein Debian Stretch? Oder noch Jessie? Bei Stretch sollte das so aussehen:


    Code
    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?

  • Php-fpm

    Zitat von kk

    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!

  • Komplett neue PHP-Pakete (5.6.37, 7.0.31, 7.1.20, 7.2.8)

    So - habe einen Fehler gefunden, der leider größere Auswirkungen hatte.


    Mit 5.6.37 (den neuen Paketen) ist per Default suhosin aktiv, das zuvor deaktiviert war:


    Code
    ./php-5.6-opt_5.6.35-1+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini.disabled
./php-5.6-opt_5.6.36-1+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini.disabled
./php-5.6-opt_5.6.37-3+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini
./php-5.6-opt_5.6.37-5+stretch1_amd64/opt/php-5.6/etc/conf.d/suhosin.ini


    Das hätte definitiv als "breaking change" ins Changelog müssen.


    Wir haben die "max_input_vars" erhöht - durch das aktive Suhosin wurde der Wert zwar übernommen, Suhosin hat über "suhosin.post.max_vars" bzw "suhosin.request.max_vars" die Änderung effektiv blockiert.


    Da auch keinerlei Logging aktiv ist, gab es keinerlei Hinweise auf die Änderung.

  • LiveConfig v2.6.0

    Zitat von taenzerme

    Wenn's so einfach und wirtschaftlich wäre etwas wie LiveConfig selber zu entwickeln (Know-How wäre hier vorhanden) hätten wir's auch selber gemacht. Ist es aber eben nicht. Bin daher dankbar für den Ist-Zustand und gebe einfach die Hoffnung nicht auf, dass der "Rest" auch noch kommt.


    Genau das unterschreibe ich hier mal genau so wie geschrieben.

  • WICHTIG: Debian 9 (Stretch) + Xen

    XEN ... migriert doch einfach auf KVM? :)


    Wenn wir aber schon das Thema haben: das Update auf Stretch 9.5 sollte man vermeiden, oder den Apache vorher von mpm_prefork auf worker/event umstellen. Andernfalls ist HTTP/2 nämlich auch weg: