Beiträge von antondollmaier
-
-
Das ist Wichtig, da den Haken viele Kunden einfach übersehen und im Nachhinein meckern, weil viel Spam kommt.
Da sind jetzt mehrere Sachen vermischt worden.- die LCDEFAULTS greifen nur, wenn ein neues Postfach angelegt wird. Egal, wann - solange dies nach der Änderung passiert. Durch die Änderung der Defaults werden keine bestehenden Postfächer angefasst.
- eine Aktivierung von SA-Einstellungen für alle Kunden, zwangsweise über die gesamte Datenbank hinweg und das auch noch über die Web-UI des Admins, halte ich für falsch. Immerhin gibt es genügend Kunden, die explizit den Spam-/Viren-Filter deaktiviert haben wollen.=>
- direkt beim Server-Setup die LCDEFAULTS passend setzen. Dafür gibt es inzwischen ja sogar schon das AutoDeploy.
- nachträgliche Änderungen halte ich für nicht realisierbar. Da muss der Kunde schon selbst Antispam aktivieren, wenn ihm zu viel Spam kommt. -
Der Ordnername "Junk" wird vom Server vorgegeben und kann daher nicht auf "Spam" geändert werden.
-
- was steht im Log zu Bind und LiveConfig?
- Zonen-Dateien werden nur mit "freeze" geschrieben, ansonsten gibt es das Journal. Anschließend den "thaw" nicht vergessen. -
Die Limits lassen sich doch auch bei Dovecot über die GUI unter dem Punkt "Verbindungen" festlegen.
Dort lassen sich nur die Anzahl der gleichzeitigen Verbindungen festlegen - nicht aber die Prozess-Limits.ZitatDiese Datei existiert derzeit nicht. Erstelle ich diese mit dem gen. Inhalt kommt es zu dem Fehler. (Es existiert nur die dovecot.conf-Datei)
das process_limit gehört offenbar nicht in die protocol{}-Sektion.Anlegen mit:
Codedefault_process_limit = 1024 default_client_limit = 2500 -
Ganz langsam:
- dovecot.local.conf wird weder von Dovecot noch von LiveConfig erzeugt
- offensichtlich hat LiveConfig die dovecot.conf umgeschrieben, so dass dort nun die dovecot.local.conf eingebunden wird
- in der dovecot.local.conf, die eben NICHT von LiveConfig kommt, ist laut Dovecot ein Fehler in Zeile 2.Ich frage daher erneut: was steht in der dovecot.local.conf?
Codecat /etc/dovecot/dovecot.local.conf -
und wie sieht diese Datei _vollständig_ aus?
-
-
lade diese auf den Server und speichere im LiveConfig die Konfiguration neu ab. Leider wird die Sache in der dovecot.conf nicht mit aufgenommen und im LiveConfig erscheint eine Fehlermeldung.
Welche Fehlermeldung denn?Die Datei wird aufgenommen, wenn die dovecot.conf neu erzeugt wird und währenddessen die dovecot.local.conf bereits existiert.
Klappt hier auf allen Servern fehlerfrei.
-
Danke gemeint ist sicher dovecot.conf?
nein.Codeprotocol imap { process_limit = 200 }
Einfach genau so in die dovecot.local.conf eintragen. -
die conf.d/10-master.conf ist irrelevant, da nicht verwendet.
Bitte in /etc/dovecot/dovecot.local.conf verwenden.
Quelle: https://www.liveconfig.com/de/…tml#advanced.mail.dovecot
-
Sprechen wir nur von IPv4 oder klappt es bei euch auch mit Ergänzung um IPv6?
Funktioniert beides. -
Wie hast du das geschafft? kk hat den Bug, afair wie du ihn beschrieben hast, bestätigt. Behebung würde noch etwas Zeit in Anspruch nehmen.
Eventuell sind hier zwei verschiedene Bugs/Probleme gemeint.
Wenn wir hier eine IP zur IP-Gruppe hinzufügen oder löschen, wird sehr wohl die Zone entsprechend angepasst. Funktioniert seit sehr langer Zeit, mit 2.7 jedoch auch (letzte Woche erst genutzt).
ZitatKann es sein dass du die Domain deren Zone du geprüft hast via GUI bearbeitet hast?
Auch bei zusätzlich gesetzten DNS-Einträgen gab es keine Fehler. -
Somit müsste ich - wenn ich den A-Recort von domain.de ändern will, "web" deaktivieren, dann sollte lc ja vermutlich den entsprechenden eintrag aus dem zonefile löschen sodass ich händisch einen hinzufügen kann???
Oder einfach "eigene DNS-Einträge" für den Vertrag erlauben und den A-Record direkt in der GUI setzen. -
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 certificateThe 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 einschaltenSomit wird die Downtime minimiert.
-
Viele Massenhoster scheren sich nicht um dieses Situation. Da werden alte Versionen entzogen und neuere Standard-Versionen aktiviert.
:+1:
(*10z*)
-
Bei PHP 5.6 bzw. PHP7 auch noch?
Was sagen die LiveCOnfig-Logs nach einer Änderung der PHP-Version?
-
Ist proxy_fcgi aktiviert?
