Christian Boltz [06.11.2014 20:54]:
Hallo Werner, hallo Leute,
Am Donnerstag, 6. November 2014 schrieb Werner Flamme:
Werner Flamme [06.11.2014 11:43]:
beim Starten von dovecot erhalte ich:
auth: Error: open(/var/run/dovecot/auth-token-secret.dat.tmp) failed: Permission denied
Der übliche Mist mit dem AppArmor-Kram. Anscheinend hat das Update bei Tumbleweed von 13.1 auf 13.2 den ganzen Schrott wieder mitinstalliert.
Abhilfe: die AppArmor-Policy auf "Meckern" gestellt, "rcapparmor restart", "rcdovecot restart" und gut ist.
Und die Zeile /{var/,}run/dovecot/auth-token-secret.dat{,.tmp} crw,
in /etc/apparmor.d/local/usr.lib.dovecot.dovecot-auth ...
Diese Zeile ist definitiv falsch - "crw" ist eine ungültige Syntax. (Ich vermute mal, dass Du im Log denied_mask='c' gefunden hast - das steht für "create".
So ist es :)
Im Profil gibt es dafür wahlweise a (append - Datei erstellen und Daten _anhängen_, typisch für Logfiles) oder w (write - Datei erstellen, beliebig schreiben und löschen)
Nimm "rw" statt "crw". Anschließend rcapparmor reload [1] und auch Dovecot neu starten.
Nun, "rw" steht schon im ausgelieferten Profil, damit traten die Probleme auf. Ich würde dann "ra" nehmen, weil die Datei unter /var/run beim Systemstart/AA-Dämonenstart noch nicht existiert.
Nebenbei: aa-logprof macht Profil-Änderungen leichter und produziert automatisch gültige Zeilen ;-)
Mal sehen, wie das anzuwenden ist. Ahja: Reading log entries from /var/log/messages. Updating AppArmor profiles in /etc/apparmor.d. Laut timestamp wurde nichts geändert, aber die Fehlermeldungen, die bei "dovecot status" angezeigt wurden, sind weg. Und: mein Thunderbird kann sich jetzt verbinden. doveconf: Fatal: execv(/usr/lib/dovecot/managesieve) failed: No such file or directory doveconf: Error: managesieve-login: dump-capability process returned 84 Lag das jetzt an AA?
Wärst Du so nett, mir die relevanten Logzeilen zu schicken? Ich kümmere mich dann gern darum, dass das Profil künftig "out of the box" funktioniert.
Wenn ich welche finde, gern. Logzeilen wie apparmor="ALLOWED" operation="file_perm" profile="/usr/lib/dovecot/log" name="/var/log/dovecot.log" pid=10589 comm="log" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 müssen doch nicht sein :) Bis jetzt beschränken sich meine Eingriffe darauf, die Zeile /{var/,}run/dovecot/auth-token-secret.dat{,.tmp} ra, in die *-login-Dateien unter /etc/apparmor.d/local/ aufzunehmen. Oh, ich sehe gerade in /etc/apparmor.d/local/usr.lib.dovecot.log: /var/log/dovecot.log ra, Das braucht man nur, wenn man dovecot direkt loggen lässt, statt die Daten an den Syslog zu geben und den dorthin loggen zu lassen. Mal sehen, ob ich es schaffe, rsyslog-Regeln zu definieren, die mit Facility MAIL nach mail_in und mail_out trennen, dann kann ich 2 sauber getrennte Logfiles anlegen. Vielleicht noch mail_other für den ClamAV und SpamAssassin...
BTW: Den Ablageort Deiner Mails kannst/solltest Du in /etc/apparmor.d/tunables/dovecot eintragen, wenn Du nicht eins der üblichen Verzeichnisse verwendest, die dort schon stehen. Ich hätte das gern automatisiert (wie beim Samba-Profil), aber die Dovecot- Konfiguration ist leider deutlich komplexer :-/
Ich nehme das dovecot-Paket aus obs:server_mail, und die Konfiguration aus Peer Heinleins Dovecot-Buch, soweit ich Änderungen brauche. Das Maildir ist in der tunables-Liste schon enthalten.
Gruß
Der Schrottlieferant ;-)
[1] bitte nicht "restart", weil das den AppArmor-Schutz von derzeit laufenden Prozessen entfernt. Mit "reload" musst Du hinterher die laufenden Prozesse nicht neu starten. (In Deinem Fall bitte nach Beheben des Syntaxfehlers dovecot neu starten!)
Das restart war Absicht, Herr Schrottlieferant :P Die Risiken sind mir bekannt, aber ich halte mein System für nicht gefährdet, hier in der Firma tauchen nur Windows-Viren auf :). Heute nehme ich meist reload... aber es muss ja erstmal richtig laufen. Übrigens lieferst Du vielleicht den Schrott, aber Du hast ihn nicht angerichtet. Du badest das nur aus :) Gruß Werner --