ispconfig_update.sh sollte dovecot.conf bei migrierten Installationen nicht verändern

#1
Hallo,
das Update Script ispconfig_update.sh beachtet leider bei migrierten Installationen von Courier zu Dovecot die geänderten Namespace Einstellungen der dovecot.conf beachten.

Bei einer migrierten oder umgestellten Installation von Courier auf Dovecot muss für den Namespace folgender Eintrag in der dovecot.conf eingefügt werden:

namespace {
inbox = yes
location =
prefix = INBOX.
separator = .
type = private
}

Andernfalls sind bestehende Abos von Emailclients nicht mehr gültig und müssen neu erstellt werden.
Wenn diese Änderung nun an der dovecot.conf durchgeführt wurde macht das Updatescript ispconfig_update.sh diese Änderung rückgängig wenn die Service neu konfiguriert werden müssen, welches als Standard mit "Yes" belegt ist.

Gruß

Rafael
 
#2
Der Updater kann nur schwer auf jeden Einzellfall reagieren. Du kannst doch einfach das Backup /etc/dovecot/dovecot.conf~ nehmen.

Man könnte grds. auch darüber nachdenken, bei jedem Services abzufragen, ob configure laufen soll oder nicht. Aber ob das nun wirklich sinnvoll ist...
 

Till

Administrator
#3
Das Updatescript kann bereits geänderte configs berücksichtigen, er hat nur vergessen die geänderte config für den Installer korrekt zu hinterlegen. man muss das config Datei template aus install/tpl/ des ispconfig tar.gz nach /usr/local/ispconfig/server/conf-custom/install/ kopieren und in dieser Datei dann die gewünschten Änderungen durchführen.
 
#4
Jein. Dann wird immer conf-custom genommen und zusätzliche / neue Parameter werden nicht in die Config geschrieben. Ich persönlich bevorzuge eine reconfigure und nehme dann diff.
 

Till

Administrator
#5
Ja, das ist richtig dass man sich dann selbst um ggf. anfallende Änderungen kümmern muss, das zu automatisieren wird aber kaum möglich sein, wie Du bereits beschrieben hast. Die Frage im Titel ist ja "ispconfig_update.sh sollte dovecot.conf bei migrierten Installationen nicht verändern" und dass macht die aktuelle Funktion mit dem hinterlegen der custom config ja.
 
#6
Man kann auch !include conf.d/*.conf in die dovecot.conf schreiben. Die eigene Änderungen liegen dann eben in etc/dovecot/conf.d/10-irgendwas.conf. Zumindest ein kleiner Test hat eben ergeben, dass die Werte aus conf.d/* übernommen werden und die aus der main-config überschreiben (zumindest das Logging - andere Werte kann ich produktiv gerade nciht testen)
 

Till

Administrator
#7
Das könnte man auch machen, aber wenn jemand splitted config bei der dovecot installation hatte, denn stehen da doch bereits jede Menge Dateien drin, die müsste man dann möglicherweise erstmal alle löschen. oder man macht ein eigenes include Verzeichnis.
 
#8
Ja, im Include-Dir dürfen keine weiteren Files liegen. Ich finde eine split-config in den meisten Fällen aber nicht sonderlich hilfreich. Deswegen lieber diff nach dem Update.
 
#9
In meinem Fall kam es zu dieser Situation nach einer Migration von Courier zu Dovecot. Die custom-install Lösung kannte ich noch nicht und würde in meinem Fall auch genügen obwohl natürlich Neuerungen aus dem Update dann nicht aktiviert werden.
Gleiches Problem tritt ja auch bei Postfix und der main.cf auf, hier könnte ein custom-install mögliche Sicherheitsprobleme die mit einem Update korrigiert werden nicht bereinigen.
Vielleicht würde ein Abschnitte ispconfig relevante Bereiche hier hilfreich sein.

Als Beispiel:

###ispconfig - do not change anything here ###
config..
config..

Eigene Änderungen werden oberhalb dieses Abschnitts vorgenommen. Das Updatescript manipuliert nur den Teil ab dem Abschnittmarker.
 
#10
Die Änderungen an der main.cf schreibt man für gewöhnlich mit postconf. So machen das auch install.php und update.php. Ich wüsste im Moment auch nicht, was es so extrm relevantes gibts, dass in der main.cf hinzugefügt / geändert werden muss. Entweder custom-conf oder diff neu gegen alt.
 
#11
Bei mir z.B. zusätzliche check_policies wie check_policy_service unix/ private/policy-spf, check_policy_service inet:127.0.0.1:10023
Ich führe noch SPF checks und ein mildes Greylisting durch. Diese Änderungen muss ich nach jedem Update zurückschreiben.
 
#12
Hi, da klinke ich mich mal ein, bei uns sind auch einige Besonderheiten in der main.cf
z.B
smtpd_milters = inet:127.0.0.1:12345, inet:localhost:8893
non_smtpd_milters = inet:127.0.0.1:12345, inet:localhost:8893
ein nicht überschreibbarer Bereich wäre schon schön ;)

greetz
 

Werbung