Beiträge von antondollmaier

    The default SSL-Certificate:


    - has a CommonName which will never match any domain name
    - is the fallback, if a domain is accessed over HTTPS and the user hasn't activated his own certificate


    The validity of this default SSL certificate shouldn't matter - at all and as stated above.

    In einem Wartungszeitraum verschiebt man kurzzeitig die Nutzdaten, so dass alle E-Mail und Webverzeichnisse leer sind. Damit erstellt man das Backup und anschließend verschiebt man die Daten wieder zurück.


    In der Zeit sind damit für alle IMAP-Nutzer die Postfächer leer, was deren lokalen Cache komplett durcheinander bringt. Halte ich nicht unbedingt für die beste Idee.

    Zitat


    [*]IP-Adresse des Mailsystems auf das neue System umziehen


    Kunden verwenden niemals nicht eine einzelne IP-Adresse, da Server ja typischerweise über IPv4 und IPv6 erreichbar sind.


    Sie verwenden zwischenzeitlich auch nicht mehr "mail.example.com" oder "imap.example.com", da das Probleme mit dem SSL-Zertifikat gibt.


    Somit verwenden Kunden nur noch "server1.example.com" als Servername, da darauf auch das SSL-Zertifikat ausgestellt ist.


    Und diesen Namen kann man bequem auf eine neue IP-Gruppe zeigen lassen, wenn die TTL niedrig genug gesetzt ist und das SSL-Zertifikat übernommen wird.


    Zitat

    [*]Nutzdaten im Hintergrund migrieren(per rsync(unterschiedliche UIDs!)[/LIST]
    E-Mails liegen bei LiveConfig in /var/mail und gehören allesamt derselben UID des Benutzers "mail".




    [quote]Auf die Art und Weise könnte man den E-Maildienst relativ unterbrechungsfrei migrieren. Die Nutzer hätten nur vorübergehend keinen Zugriff auf die vorhandenen E-Mails Ihrer Postfächer, bis der Hintergrund-sync abgeschlossen ist.


    Was ebenfalls verkürzt werden kann:


    - initialer RSync im laufenden Betrieb
    - Dienste abschalten, ab jetzt Ausfall
    - neuer Rsync, der nur die Änderungen überträgt
    - Dienste wieder einschalten


    Somit wird die Downtime minimiert.

    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.

    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)

    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?