Beiträge von lebenszeit

    Die FTP-Zugänge sind bei "Webspace" gut aufgehoben. Ich schätze das schlanke Menü und dass nicht jede Funktion eine eigene Seite hat.


    Eventuell könnte der (default-)FTP-Zugang stärker visualisiert werden wenn er kein Kennwort hat. So wäre schneller ersichtlich, dass ein Kennwort hierfür gesetzt werden kann.


    Der Erweiterung um Kennzeichnung für SSH stimme ich zu.

    Die Variablen sind veraltet:

    Zitat von https://wiki2.dovecot.org/Pigeonhole/ManageSieve/Configuration?highlight=(sieve_storage|sieve_dir)

    For Dovecot v1.0 and v1.1, the sieve_dir setting used by ManageSieve was called sieve_storage
    ...
    For Pigeonhole versions before v0.3.1, this setting can only be a filesystem path pointing to a script file, or - when ManageSieve is used - it is the location of the symbolic link pointing to the active script in the storage directory. That storage directory is then configured using the deprecated sieve_dir setting.


    Es ist nun alles über sieve bzw. userdb_sieve zu regeln:
    Mit
    userdb_sieve=file:~/sieve/%u;active=/var/mail/vertrag/3/dovecot.sieve in /etc/dovecot/passwd
    klappt es.

    Danke.


    Zunächst: Ich vermute den Fehler außerhalb von LC.
    Autoresponder in LC ist deaktiviert damit der Symlink auf die aktive, individuelle Sieve-Dateien erhalten bleibt. So kann mittels managesieve deutlich mehr konfiugiert werden.
    Um globale Filtersätze zu vermeiden werden mittels
    sieve_storage = ~/sieve/%u
    die Daten in
    /var/mail/sieve/info@example.com/names_des_filtersatzes.sieve
    geschrieben. Das funktioniert. Nur wird es bei Maileingang nun mit o.g. Fehler quittiert.

    Das hat lange Zeit wunderbar funktioniert. Neuerdings sowohl auf einem schon länger bestehenden als auch auf einem einem neu installierten Debian 9 führt es zu
    dovecot: lda(info@example.com): Warning: sieve: file storage: Active sieve script symlink /var/mail/vertragsname/3/dovecot.sieve is broken: Invalid/unknown path to storage (points to /var/mail/sieve/info@example.com).


    Die Zeile
    sieve = ~/.dovecot.sieve
    wird durch
    userdb_sieve=/var/mail/vertragsname/3/dovecot.sieve aus /etc/dovecot/passwd überschrieben und ist nach meinem Verständnis optional.


    Wird
    sieve_storage = ~/sieve/%u
    weggelassen entfällt die Fehlermeldung und Sieve funktioniert - dann gibt es aber kein eigenes Verzeichnis je User mehr => ungeeignet.



    Wer kann das reproduzieren?

    Bevor ein Vertrag angelegt ist kann ihm keine IP-Gruppe zugewiesen werden.
    Wird der Vertrag via API samt Domains angelegt und gleich die richtige, exklusiv gewünschte IP-Gruppe zugewiesen so kann diese in der Webserververwaltung nicht mehr von "gemeinsam" auf "exklusiv" umgestellt werden.


    Den Import an dieser Stelle zu splitten kann keine Lösung sein.

    Mit aktuellem Stable weiterhin


    * Connection state changed (MAX_CONCURRENT_STREAMS updated)!
    * http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [upgrade], value: [h2]
    * HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
    * Curl_http_done: called premature == 1
    * Closing connection 0
    * TLSv1.2 (OUT), TLS alert, Client hello (1):
    curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)


    und Schleifen von AppleWebKit.


    "more" erscheint in /usr/lib/liveconfig/lua/nginx.lua nicht. Ist Ihr letzter Absatz ein Ausblick, eine Empfehlung, nur eine technische Information?

    Zur DB: Aus dem Bauch heraus zum prüfen - vorab mit einem Test-Vertrag!
    DB sichern (zB MySQL-Dump), Integrität sicherstellen. Alle DB des Kunden in LC löschen, dann prüfen, ob der DB-Server geändert werden kann. Wenn geändert (vmtl. geht das sonst auch über die DB) neu Anlegen und Dumps importieren.


    Workaround: Dem Kunden einen zweiten Vertrag geben für die DB. Dann kann komfortabler mittels Rsync gearbeitet werden.

    Debian 9:


    Nach Aktivierung von http/2 in Nginx explodiert die Last auf dem Server. Requests werden gefühlt endlos erneut abgesetzt:



    Nach Deaktivierung von http/2 normalisiert sich das wieder.
    Gibt es dazu Ideen?

    Das ist eine sehr seltene und nur für Profis interesannte Option. Es würde viele verwirren aber wenigen nützen. Soweit ich weiß ist es aus diesem Grund nicht möglich. NS-Records optional je Kunde freischalten zu können habe ich bereits angeregt.


    Warum nicht gleich die Ziel-Nameserver für die gesamte Domain verwenden?