Dovecot-Problem mit Rechten bei VirtualUser-Konfiguration
![](https://seccdn.libravatar.org/avatar/3ce160b3500131402c3a29bfb24732cc.jpg?s=120&d=mm&r=g)
Hallo zusammen, ich möchte einen Dovecot-IMAP-Server nur mit sog. Virtuellen Benutzern (solche, die nicht gleichzeitig Systembenutzer sind, also kein Konto am System haben). Ich habe dazu folgende Anleitungen zu Rate gezogen: http://wiki2.dovecot.org/QuickConfiguration http://wiki2.dovecot.org/MailLocation http://wiki2.dovecot.org/VirtualUsers http://wiki2.dovecot.org/VirtualUsers/Home http://wiki.dovecot.org/HowTo/SimpleVirtualInstall https://www.digitalocean.com/community/tutorials/how-to-configure-a-mail-ser... (hier Step 4: Configure Dovecot) Zum testen hat die Datei /etc/dovecot/users nur die eine Zeile <user>@<domain>.<tld>:{PLAIN}test:10000:10000::/srv/mail/vhosts/<domain>.<tld>/<user>/Mail Die Verzeichnisse haben folgende Rechte: drwxr-xr-x 14 root root 4096 Oct 18 11:59 /srv drwxrwxrwt 4 root root 4096 Oct 18 18:27 /srv/mail/ drwxrwsrwt 2 vmail vmail 4096 Oct 19 19:37 /srv/mail/vhosts/ Eigentlich braucht es für das Verz. vhosts/ nicht die Rechte für die anderen o=rwxt, aber das war bei meinen Versuchen noch übriggeblieben. Dovecot meldet bei der User-Anmeldung Permissions-Fehler (habe Datum, Zeit Hostname und Prozessname [PID] weggelassen und für bessere Lesbarkeit etwas manuell formatiert und Leerzeilen zw. d. einzelnen Logs eingefügt): imap(<user>@<domain>.<tld>): Error: open(/var/run/dovecot/mounts) failed: Permission denied imap(<user>@<domain>.<tld>): Error: user <user>@<domain>.<tld>: Initialization failed: Namespace '': mkdir(/srv/mail/vhosts/<domain>.<tld>/<user>/Mail) failed: Permission denied (euid=10000(vmail) egid=10000(vmail) UNIX perms appear ok (ACL/MAC wrong?)) imap(<user>@<domain>.<tld>): Error: Invalid user settings. Refer to server log for more information. Hier schon die Frage: welchen Server Log soll ich mir ansehen? Wie man oben sieht, gibt es einen System-User vmail und eine gleichnamige Gruppe, unter der die Zugriffe auf die Mailboxen der Mail-Benutzer erfolgen sollen. Die Benutzer dovecot und dovenull sind Mitglieder der Gruppe vmail. Dovecot sollte die fehlenden Verzeichnisse für den Benutzer beim ersten Anmelden anlegen: <domain>.<tld>/<user>/Mail (siehe hierzu das Howto "SimpleVirtualInstall" mit folg. Aussage: "Users can be added by editing this file [gemeint ist das, welches bei mir /etc/dovecot/users heißt]. Dovecot automatically notices the new users immediately after they're added. It also creates their home directories when the user logs in.") Die große Frage für mich ist nun: was kann an den Permissions falsch sein, wenn sogar "alle" in /srv/mail/vhosts/ Schreibrechte haben? Wenn ich die Verzeichnisse <domain>.<tld>/<user>/Mail in vhosts/ selber anlege (mit den selben Rechten und Owner:Group = vmail:vmail), dann funktioniert die Anmeldung (keine Fehlermeldung vom MUA), aber dennoch gibt es wieder rechtebedingte Fehler; das Verzeichnis cur/ in .../Mail/ kann nicht angelegt werden: imap(<user>@<domain>.<tld>): Error: mkdir(/srv/mail/vhosts/<domain>.<tld>/<user>/Mail/cur) failed: Permission denied (euid=10000(vmail) egid=10000(vmail), access(/srv/mail/vhosts/<domain>.<tld>/<user>/Mail/cur, 4) failed: No such file or directory) Die fehlerhafte Initialisierung der ganz oben stehenden Fehelrmeldungen steht hier natürlich nicht mehr, weil die Verzeichnisse für den Benutzer voher schon von mir angelegt wurden. Hier noch die von den Defaults abweichenden Configs (doveconf -n): auth_debug = yes auth_verbose = yes mail_access_groups = vmail mail_debug = yes mail_home = /srv/mail/vhosts/%d/%n mail_location = maildir:~/Mail mail_privileged_group = vmail # Folgende Configs waren von der Distri so vorgegeben ########################################################### managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } ########################################################### passdb { args = scheme=CRYPT username_format=%u /etc/dovecot/users driver = passwd-file } # Folgende Configs waren von der Distri so vorgegeben ########################################################### plugin { sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } protocols = imap lmtp ssl = no userdb { driver = passwd } userdb { args = username_format=%u /etc/dovecot/users driver = passwd-file } verbose_proctitle = yes ########################################################## Hat jemand eine Idee, was bei den Permissions noch falsch sein könnte? Danke im Voraus für jeden Anstoß! Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b58101fb24c64d0ff1d0f918e61cedd2.jpg?s=120&d=mm&r=g)
Hallo Thomas, hallo zusammen, Am Donnerstag, 20. Oktober 2016, 18:52:01 CEST schrieb Thomas Michalka:
imap(<user>@<domain>.<tld>): Error: open(/var/run/dovecot/mounts) failed: Permission denied
imap(<user>@<domain>.<tld>): Error: user <user>@<domain>.<tld>: Initialization failed: Namespace '': mkdir(/srv/mail/vhosts/<domain>.<tld>/<user>/Mail) failed: Permission denied (euid=10000(vmail) egid=10000(vmail) UNIX perms appear ok (ACL/MAC wrong?))
imap(<user>@<domain>.<tld>): Error: Invalid user settings. Refer to server log for more information.
Hier schon die Frage: welchen Server Log soll ich mir ansehen?
"Permission denied" klingt nach AppArmor ;-) Du musst in /etc/apparmor.d/tunables/dovecot/ noch /srv/mail/vhosts/ eintragen (wenn Du schon dabei bist, kannst Du auch die nicht benötigten Verzeichnisse löschen) und anschließend mit "rcapparmor reload" die AppArmor-Profile neu laden. Guck auch mal in /var/log/audit/audit.log nach Zeilen mit DENIED (insbesondere Einträge zu /var/run/dovecot/mounts würden mich interessieren) Noch eine Frage - welche openSUSE-Version? Gruß Christian Boltz -- who needs facts if polemics are that much easier to get into. [Sven Burmeister in opensuse-factory] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/3ce160b3500131402c3a29bfb24732cc.jpg?s=120&d=mm&r=g)
Servus Christian und allen interessierten Mitlesern, herzlichen Dank für Deinen _sehr richtigen_ Hinweis :-D Ich könnt' mich bloß in den A...sten beißen, weil ich mich dadurch wieder erinnere, dass ich deswegen schon mal den AppArmor kurzerhand zum Teufel geschickt habe (ich mag solche Nebenberechtigungs- oder besser Nebenbeschränkungssysteme nicht). Hätte ich bloß in meinem Admin-Diary gesucht -- knirsch :-| Ist nämlich schon recht lange her; das war bei einer oS 12.3 oder 13.1, glaube ich. Heute habe ich oS 13.2. Nebenfrage: Gibt's eigentlich eine zentrale Datei, wo eingetragen ist, was auf einem System per Distri-Default läuft bzw. aktiviert ist, und wo am besten auch automatisch eingetragen wird, wann man selber einen Dienst oder was auch immer aktiviert, neu konfiguriert u.s.w.. Wäre schon interessant, wenn man das von Distri-Version zu -Version vergleichen könnte, und freilich auch, um zu sehen, was man über die Jahre selber so 'verbrochen' hat. Das wäre sozusagen ein sehr, sehr langsamer Log, weil nur Admin-Aktionen aufgezeichnet würden. So könnte man auch gut nachvollziehen, wenn man etwas verbockt hat, besonders, wo Fehler erst viel später auftauchen. Trotzdem gibt's so immer wieder was zu lernen, was das Gute daran ist, denn ich habe noch den Fehler mit /var/run/dovecot/mounts. Doch hier zunächst mal ein paar Zeilen aus /var/log/audit/audit.log: type=USER_AUTH msg=audit(1476894139.992:14384): pid=14663 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="?" exe="/usr/lib/dovecot/auth" hostname=192.168.0.3 addr=192.168.0.3 terminal=dovecot res=failed' type=AVC msg=audit(1476894139.994:14385): apparmor="DENIED" operation="open" profile="/usr/lib/dovecot/imap" name="/var/run/dovecot/mounts" pid=14664 comm="imap" requested_mask="r" denied_mask="r" fsuid=10000 ouid=0 type=SYSCALL msg=audit(1476894139.994:14385): arch=c000003e syscall=2 success=no exit=-13 a0=7fb2413f0a40 a1=0 a2=7fb2413f0940 a3=7fff63a3aba0 items=0 ppid=21672 pid=14664 auid=4294967295 uid=10000 gid=10000 euid=10000 suid=10000 fsuid=10000 egid=10000 sgid=10000 fsgid=10000 tty=(none) ses=4294967295 comm="imap" exe="/usr/lib/dovecot/imap" key=(null) type=PROCTITLE msg=audit(1476894139.994:14385): proctitle="dovecot/imap" type=AVC msg=audit(1476894139.994:14386): apparmor="DENIED" operation="mkdir" profile="/usr/lib/dovecot/imap" name="/srv/mail/vhosts/<domain>.<tld>/<user>/Mail/" pid=14664 comm="imap" requested_mask="c" denied_mask="c" fsuid=10000 ouid=10000 Hoffe, das genügt Dir. Wenn Dich noch anderes interessiert, immer gerne! Nochmal speziell zur Datei "/etc/apparmor.d/tunables/dovecot". Hier stand bei mir nur die eine Zeile für bzw. gegen Dovecot drin: @{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/ /var/vmail/ /var/mail/ /var/spool/mail/ Ans Ende habe ich "/srv/mail/vhosts" eingetragen, was gewirkt hat. Im Kommentar darüber steht: # @{DOVECOT_MAILSTORE} is a space-separated list of all directories # where dovecot is allowed to store and read mails Muss ich das wörtlich nehmen, d.h. dass nur die Mailverzeichnisse dort eingetragen werden dürfen? Wenn ja, wie müsste dann ein Eintrag aussehen, damit das lesen von "/var/run/dovecot/mounts" möglich wird? Oder kann/sollte man diesen Fehler getrost ignorieren? Noch eines: als ich noch Systembenutzer als Mail-User zugelassen habe, war es AppArmor anscheinend egal, dass dovecot im Home-Verzeichnis des Benutzers die MailDir-Verzeichnisstruktur angelegt hat. Wacht AppArmor nicht über Benutzerverzeichnisse? Wo ist festgelegt, worüber grundsätzlich gewacht wird? Am 20.10.2016 um 22:42 schrieb Christian Boltz:
Hallo Thomas, hallo zusammen, [...]
Guck auch mal in /var/log/audit/audit.log nach Zeilen mit DENIED (insbesondere Einträge zu /var/run/dovecot/mounts würden mich interessieren)
Gibt's irgendwo eine Stelle, wo man alle Neuerungen von Distri-Version zu Distri-Version gesammelt und möglichst schön gegliedert und in einer gewissen Tiefe (oder gerne mit Links auf entsprechende Doku) nachlesen kann, damit man besser auf dem Laufenden bleibt? Vor langer, langer Zeit (noch SuSE) gab's mal einen Documentation Server im System, wo man im Browser auch Man Pages, die On-the-Fly nach HTML umgewandelt wurden, und viele andere Doku lesen konnte. Gibt's heute etwas entsprechendes?
Noch eine Frage - welche openSUSE-Version?
oS 13.2 Also nochmals vielen Dank! Wäre schön, wenn wir auch noch klären könnte, wie man den Fehler mit "/var/run/dovecot/mounts" beseitigen kann. Viele Grüße, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b58101fb24c64d0ff1d0f918e61cedd2.jpg?s=120&d=mm&r=g)
Hallo Thomas, hallo zusammen, Am Freitag, 21. Oktober 2016, 16:23:53 CEST schrieb Thomas Michalka:
herzlichen Dank für Deinen _sehr richtigen_ Hinweis :-D Ich könnt' mich bloß in den A...sten beißen, weil ich mich dadurch wieder erinnere, dass ich deswegen schon mal den AppArmor kurzerhand zum Teufel geschickt habe (ich mag solche Nebenberechtigungs- oder besser Nebenbeschränkungssysteme nicht). Hätte ich bloß in meinem
Im Zweifelsfall verhindert AppArmor das Ausnutzen einer Sicherheitslücke (nicht nur theoretisch - es hat mich schon mehr als einmal vor Problemen bewahrt), daher lasse ich das sehr gern aktiv und habe auch ein paar zusätzliche (leider nicht massentaugliche) Profile im Einsatz. Als AppArmor-Maintainer und einer der Entwickler bin ich in dieser Frage natürlich etwas befangen ;-)
Admin-Diary gesucht -- knirsch :-| Ist nämlich schon recht lange her; das war bei einer oS 12.3 oder 13.1, glaube ich. Heute habe ich oS 13.2.
;-)
Nebenfrage: Gibt's eigentlich eine zentrale Datei, wo eingetragen ist, was auf einem System per Distri-Default läuft bzw. aktiviert ist, und wo am besten auch automatisch eingetragen wird, wann man selber einen Dienst oder was auch immer aktiviert, neu konfiguriert u.s.w.. Wäre schon interessant, wenn man das von Distri-Version zu -Version vergleichen könnte, und freilich auch, um zu sehen, was man über die Jahre selber so 'verbrochen' hat. Das wäre sozusagen ein sehr, sehr langsamer Log, weil nur Admin-Aktionen aufgezeichnet würden. So könnte man auch gut nachvollziehen, wenn man etwas verbockt hat, besonders, wo Fehler erst viel später auftauchen.
Nicht direkt, aber es gibt ein paar Möglichkeiten: - rpm -Va listet alle veränderten Dateien (ggf. | grep /etc verwenden) - rpm -qf /eine/datei zeigt, zu welchem Paket eine Datei gehört bzw. dass sie nicht zu einem Paket gehört - etckeeper verwaltet /etc/ in git (habe ich nie getestet, wäre aber für einen kurzen Bericht dankbar, falls es jemand einsetzt) - verwende ein Konfigurationsmanagement-Tool wie Saltstack, Puppet o. ä. und benutze nie "su" oder "sudo". Bei einem einzelnen Rechner ist das natürlich ein gewisser Overhead, dafür bekommst Du aber eine saubere Doku Deiner Config und kannst bei Bedarf einen neuen Rechner automatisch genau so konfigurieren. Bei mehreren (großteils) identisch konfigurierten Rechnern sollte es sogar Zeit sparen, weil Du alles nur 1x und nicht auf jedem Rechner machen musst
Trotzdem gibt's so immer wieder was zu lernen, was das Gute daran ist, denn ich habe noch den Fehler mit /var/run/dovecot/mounts. Doch hier zunächst mal ein paar Zeilen aus /var/log/audit/audit.log:
type=AVC msg=audit(1476894139.994:14385): apparmor="DENIED" operation="open" profile="/usr/lib/dovecot/imap" name="/var/run/dovecot/mounts" pid=14664 comm="imap" requested_mask="r" denied_mask="r" fsuid=10000 ouid=0
Du kannst mit aa-logprof die AppArmor-Profile interaktiv updaten. Du kannst aber auch folgende Zeile in /etc/apparmor.d/ usr.lib.dovecot.imap eintragen: /{,var/}run/dovecot/mounts r, Genau passend zum Logeintrag wäre /var/run/dovecot/mounts r, aber obige Variante ist zukunfssicher und funktioniert für /var/run/... und /run/... In der aktuellen Upstream-Version der Dovecot-Profile ist diese Zeile übrigens schon enthalten - aber nur wegen dieser einen Zeile lohnt es sich nicht wirklich, ein Update anzustoßen. Außerdem braucht Dovecot diese Zeile nur in manchen Situationen - IIRC nur dann, wenn das Mailverzeichnis nicht existiert oder Zugriffsrechte fehlen.
Nochmal speziell zur Datei "/etc/apparmor.d/tunables/dovecot". Hier stand bei mir nur die eine Zeile für bzw. gegen Dovecot drin:
@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/ /var/vmail/ /var/mail/ /var/spool/mail/
Ans Ende habe ich "/srv/mail/vhosts" eingetragen, was gewirkt hat. Im
Genau, passt. Die für Dich "unnötigen" Verzeichnisse darfst Du übrigens gern rauslöschen.
Kommentar darüber steht:
# @{DOVECOT_MAILSTORE} is a space-separated list of all directories # where dovecot is allowed to store and read mails
Muss ich das wörtlich nehmen, d.h. dass nur die Mailverzeichnisse dort eingetragen werden dürfen?
Du musst nicht, aber Du solltest ;-) Jedenfalls werden für alle angegebenen Verzeichnisse Schreib- und Leserechte für Dovecot vergeben. Dateien eintragen ist übrigens komplett sinnlos, weil im Profil @{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwkl, steht. Die erste Zeile erlaubt Schreiben und Lesen des Verzeichnisses (quasi mkdir und ls), und durch den angehängten / wird die Regel ausdrücklich auf "Verzeichnis" festgelegt. Die zweite Zeile gibt vollen Zugriff auf alle Dateien und Unterverzeichnisse innerhalb des Verzeichnisses.
Wenn ja, wie müsste dann ein Eintrag aussehen, damit das lesen von "/var/run/dovecot/mounts" möglich wird? Oder kann/sollte man diesen Fehler getrost ignorieren?
Siehe oben - das gehört ins dovecot/imap-Profil.
Noch eines: als ich noch Systembenutzer als Mail-User zugelassen habe, war es AppArmor anscheinend egal, dass dovecot im Home-Verzeichnis des Benutzers die MailDir-Verzeichnisstruktur angelegt hat. Wacht AppArmor nicht über Benutzerverzeichnisse? Wo ist festgelegt, worüber grundsätzlich gewacht wird?
Doch, AppArmor wacht über alles. Genaugenommen erlaubt es nur das, was ausdrücklich erlaubt ist, und verbietet alles andere. Guck nochmal in die tunables/dovecot - dort steht u. a. @{HOME}/Maildir drin. @{HOME} ist in tunables/home definiert und enthält /home/*/ und /root/ Sprich: @{HOME}/Maildir wird zu /home/*/Maildir und /root/Maildir expandiert und der Zugriff auf /home/*/Maildir somit ganz offiziell erlaubt.
Gibt's irgendwo eine Stelle, wo man alle Neuerungen von Distri-Version zu Distri-Version gesammelt und möglichst schön gegliedert und in einer gewissen Tiefe (oder gerne mit Links auf entsprechende Doku) nachlesen kann, damit man besser auf dem Laufenden bleibt?
Die Release Notes und das Release-Announcement sind ein guter Überblick über die wichtigsten Änderungen. _Alle_ Neuerungen seit der letzten Version ergeben eine *sehr* lange Datei, die vermutlich eh niemand lesen würde. Zum Vergleich: Tumbleweed hat im Schnitt 4 Releases pro Woche, und die Changelog-Mail (für jedes dieser Releases, also für 2 Tage) ist meistens mehrere hundert Zeilen lang. Jetzt rechne Dir das auf ein jährliches Release hoch ;-)
Vor langer, langer Zeit (noch SuSE) gab's mal einen Documentation Server im System, wo man im Browser auch Man Pages, die On-the-Fly nach HTML umgewandelt wurden, und viele andere Doku lesen konnte. Gibt's heute etwas entsprechendes?
http://doc.opensuse.org (zwar keine Manpages, aber eine ganze Menge Handbücher) Die Manpages findest Du auch irgendwo online, oder Du verwendest z. B. "man:apparmor.d" in Konqueror. Für den Einstieg in AppArmor empfehle ich gern meinen "AppArmor Crash Course". Die Slides gibt es auf blog.cboltz.de, ein Vortragsvideo von der letzten openSUSE Conference irgendwo ;-) auf conference.opensuse.org und bei YouTube. Gruß Christian Boltz -- A lot of us don't speak chinese - should we switch to this language to enable 1 billion people to read this list too? :) [Wolfgang Post in suse-laptop] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/3ce160b3500131402c3a29bfb24732cc.jpg?s=120&d=mm&r=g)
Hallo Christian, Am 21.10.2016 um 21:03 schrieb Christian Boltz:
Hallo Thomas, hallo zusammen,
Am Freitag, 21. Oktober 2016, 16:23:53 CEST schrieb Thomas Michalka:
[...]
Im Zweifelsfall verhindert AppArmor das Ausnutzen einer Sicherheitslücke (nicht nur theoretisch - es hat mich schon mehr als einmal vor Problemen bewahrt), daher lasse ich das sehr gern aktiv und habe auch ein paar zusätzliche (leider nicht massentaugliche) Profile im Einsatz.
Klar, wer um die Wirkung weiß, steht nicht wie der Ochs vorm Berg, wenn von dovecot/imap fehlende, aber nicht näher definierte Permissions benannt werden. Wäre vielleicht 'nen Hinweis an die Dovecot-Entwickler wert. Es heißt ja auch "Unix perms seem to be ok (ACL/MAC wrong?)". Sonst hätte ich mich gar nicht an die Liste gewandt, wenn ich an den Unix Permissions noch hätte drehen können. Oder AppArmor könnte sich gegenüber Dovecot offenbaren.
Als AppArmor-Maintainer und einer der Entwickler bin ich in dieser Frage natürlich etwas befangen ;-)
Ich kann darüber nicht klagen :-) "Tue Gutes und rede darüber" sollte man hin und wieder beherzigen.
Nebenfrage: Gibt's eigentlich eine zentrale Datei, wo eingetragen ist, was auf einem System per Distri-Default läuft bzw. aktiviert ist, und wo am besten auch automatisch eingetragen wird, wann man selber einen Dienst oder was auch immer aktiviert, neu konfiguriert u.s.w.. Wäre schon interessant, wenn man das von Distri-Version zu -Version vergleichen könnte, und freilich auch, um zu sehen, was man über die Jahre selber so 'verbrochen' hat. Das wäre sozusagen ein sehr, sehr langsamer Log, weil nur Admin-Aktionen aufgezeichnet würden. So könnte man auch gut nachvollziehen, wenn man etwas verbockt hat, besonders, wo Fehler erst viel später auftauchen.
Nicht direkt, aber es gibt ein paar Möglichkeiten: - rpm -Va listet alle veränderten Dateien (ggf. | grep /etc verwenden) - rpm -qf /eine/datei zeigt, zu welchem Paket eine Datei gehört bzw. dass sie nicht zu einem Paket gehört - etckeeper verwaltet /etc/ in git (habe ich nie getestet, wäre aber für einen kurzen Bericht dankbar, falls es jemand einsetzt) - verwende ein Konfigurationsmanagement-Tool wie Saltstack, Puppet o. ä. und benutze nie "su" oder "sudo". Bei einem einzelnen Rechner ist das natürlich ein gewisser Overhead, dafür bekommst Du aber eine saubere Doku Deiner Config und kannst bei Bedarf einen neuen Rechner automatisch genau so konfigurieren. Bei mehreren (großteils) identisch konfigurierten Rechnern sollte es sogar Zeit sparen, weil Du alles nur 1x und nicht auf jedem Rechner machen musst
Die ersten zwei kenne ich natürlich und Versionsverwaltung mit CVS und Subversion sind mir geläufig und habe ich auch mal eine Zeit lang für Configs gemacht. Dann macht mir mein Admin-Diary aber doch weniger Aufwand. Aber beide haben den Nachteil, dass man sie pflegen und darin nachsehen muss ;-) Die Versionsverwaltung ist mir für die wenigen Änderungen in Jahren einfach zu hoch. Meine Systeme verändern sich nur langsam/selten und wenn, dann in Schüben. Das schreibe ich dann lieber manuell auf. Ich muss auch gar nicht genau wissen, was ich in Configs und in welchen Schritten verändert habe (kann ich mit diffs zw. der Originalversion und dem aktuellen File rausbekommen), sondern ich hätte nur gerne einen Automatismus, der mir aufzeichnet, wann ich welche Dateien verändert und Dienste neu gestartet habe bzw. Configs neu eingelesen wurden. Könnte man mit einigem Aufwand sicher aus den Logs herausfiltern.
[...] zunächst mal ein paar Zeilen aus /var/log/audit/audit.log:
type=AVC msg=audit(1476894139.994:14385): apparmor="DENIED" operation="open" profile="/usr/lib/dovecot/imap" name="/var/run/dovecot/mounts" pid=14664 comm="imap" requested_mask="r" denied_mask="r" fsuid=10000 ouid=0
Du kannst mit aa-logprof die AppArmor-Profile interaktiv updaten.
Was ist mit "interaktiv" updaten gemeint?
Du kannst aber auch folgende Zeile in /etc/apparmor.d/ usr.lib.dovecot.imap eintragen: /{,var/}run/dovecot/mounts r,
[...]
Nochmal speziell zur Datei "/etc/apparmor.d/tunables/dovecot". Hier stand bei mir nur die eine Zeile für bzw. gegen Dovecot drin:
@{DOVECOT_MAILSTORE}=@{HOME}/Maildir/ @{HOME}/mail/ @{HOME}/Mail/ /var/vmail/ /var/mail/ /var/spool/mail/
Ans Ende habe ich "/srv/mail/vhosts" eingetragen, was gewirkt hat. Im
Genau, passt.
Die für Dich "unnötigen" Verzeichnisse darfst Du übrigens gern rauslöschen.
Ja, steht auch im Kommentar.
[...]
Dateien eintragen ist übrigens komplett sinnlos, weil im Profil @{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwkl, steht.
Die erste Zeile erlaubt Schreiben und Lesen des Verzeichnisses (quasi mkdir und ls), und durch den angehängten / wird die Regel ausdrücklich auf "Verzeichnis" festgelegt.
Die zweite Zeile gibt vollen Zugriff auf alle Dateien und Unterverzeichnisse innerhalb des Verzeichnisses.
"rw" ist klar, aber "kl"?
[...] Wacht AppArmor nicht über Benutzerverzeichnisse? Wo ist festgelegt, worüber grundsätzlich gewacht wird?
Doch, AppArmor wacht über alles. Genaugenommen erlaubt es nur das, was ausdrücklich erlaubt ist, und verbietet alles andere.
Guck nochmal in die tunables/dovecot - dort steht u. a. @{HOME}/Maildir drin. @{HOME} ist in tunables/home definiert und enthält /home/*/ und /root/
Sprich: @{HOME}/Maildir wird zu /home/*/Maildir und /root/Maildir expandiert und der Zugriff auf /home/*/Maildir somit ganz offiziell erlaubt.
Ok, ich dachte zuerst, dass mit @{HOME} das Mailhome, bei mir gemeint sei, denn zufällig entspricht das Home-Verzeichnis der Systembenutzer genau den Mail-Homes für Dovecot. Aber AppArmor juckt der IMAP-Server ja nicht.
Gibt's irgendwo eine Stelle, wo man alle Neuerungen von Distri-Version zu Distri-Version gesammelt und möglichst schön gegliedert und in einer gewissen Tiefe (oder gerne mit Links auf entsprechende Doku) nachlesen kann, damit man besser auf dem Laufenden bleibt?
Die Release Notes und das Release-Announcement sind ein guter Überblick über die wichtigsten Änderungen.
Aber nur von Release zu Release innerhalb der Version, und das ist schon viel Stoff. Würde man alle bis zu einer neuen Version lesen, hätte man die ersten schon wieder vergessen.
_Alle_ Neuerungen seit der letzten Version ergeben eine *sehr* lange Datei, die vermutlich eh niemand lesen würde.
Eben, wenn man sich aber auf die größeren Änderungen beschränken würde, z.B. welche Dienste neu und standardmäßig eingeschaltet sind, dann wäre die Datei viel kürzer.
Zum Vergleich: Tumbleweed hat im Schnitt 4 Releases pro Woche, und die Changelog-Mail (für jedes dieser Releases, also für 2 Tage) ist meistens mehrere hundert Zeilen lang. Jetzt rechne Dir das auf ein jährliches Release hoch ;-)
Ja, klar, deswegen müsste man eher an der Oberfläche bleiben bzw. einen sinnvollen Kompromiss darüber finden, was man bringt und was nicht -- natürlich nur in einer extra Datei mit den großen Änderungen, nicht in den Release Notes, denn Kleinigkeiten können auch wichtig sein.
Vor langer, langer Zeit (noch SuSE) gab's mal einen Documentation Server im System, wo man im Browser auch Man Pages, die On-the-Fly nach HTML umgewandelt wurden, und viele andere Doku lesen konnte. Gibt's heute etwas entsprechendes?
http://doc.opensuse.org (zwar keine Manpages, aber eine ganze Menge Handbücher)
Naja, "einige" würde ich sagen.
Die Manpages findest Du auch irgendwo online, oder Du verwendest z. B. "man:apparmor.d" in Konqueror.
Ich komme schon klar mit man <Befehl> im Terminal, aber ein Doku-Crawler, von dem aus man zentral ein System oder sogar ein ganzes LAN, wenn man Doku-Server hat, nach Doku durchsuchen kann, wäre schon praktisch, auch zum Schmökern, wie in einer Buchhandlung. Da kommt man auf Schätzchen, die man sonst nicht finden würde.
Für den Einstieg in AppArmor empfehle ich gern meinen "AppArmor Crash Course". Die Slides gibt es auf blog.cboltz.de, ein Vortragsvideo von der letzten openSUSE Conference irgendwo ;-) auf conference.opensuse.org und bei YouTube.
Danke, schaue ich mir gerne an. Schöne Grüße Thomas Michalka -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b58101fb24c64d0ff1d0f918e61cedd2.jpg?s=120&d=mm&r=g)
Hallo Thomas, hallo zusammen, Am Samstag, 22. Oktober 2016, 16:05:01 CEST schrieb Thomas Michalka:
Am 21.10.2016 um 21:03 schrieb Christian Boltz:
Hallo Thomas, hallo zusammen,
Am Freitag, 21. Oktober 2016, 16:23:53 CEST schrieb Thomas Michalka:
[...]
Im Zweifelsfall verhindert AppArmor das Ausnutzen einer Sicherheitslücke (nicht nur theoretisch - es hat mich schon mehr als einmal vor Problemen bewahrt), daher lasse ich das sehr gern
Apropos: Ich habe mir gestern Abend mal "Dirty COW" und die öffentlich verfügbaren Proof of Concept-Exploits angesehen. Wie es aussieht [1], kann AppArmor das Ausnutzen dieser Sicherheitslücke verhindern :-) Das Programm muss natürlich ein AppArmor-Profil haben, und das darf keine Zugriffe auf /proc/*/mem erlauben. (Trotzdem ist es eine gute Idee, das Kernel-Update zu installieren ;-)
aktiv und habe auch ein paar zusätzliche (leider nicht massentaugliche) Profile im Einsatz. Klar, wer um die Wirkung weiß, steht nicht wie der Ochs vorm Berg,
;-)
wenn von dovecot/imap fehlende, aber nicht näher definierte Permissions benannt werden. Wäre vielleicht 'nen Hinweis an die Dovecot-Entwickler wert. Es heißt ja auch "Unix perms seem to be ok (ACL/MAC wrong?)". Sonst hätte ich mich gar nicht an die Liste
MAC steht für Mandatory Access Control. AppArmor ist so ein MAC, SELinux ein anderes. Dovecot ist also schon deutlich hilfreicher als die meisten anderen Programme, die einfach nur "Permission denied" melden ;-)
gewandt, wenn ich an den Unix Permissions noch hätte drehen können. Oder AppArmor könnte sich gegenüber Dovecot offenbaren.
_Vermutlich_ wird das etwas schwierig. AppArmor arbeitet ja innerhalb des Kernels, und nach außen wird dann nur ein "Permission denied" (EPERM) rausgegeben, und eben der Eintrag im audit.log. Es gibt kein "Permission denied by AppArmor" als eigenen Fehlerstatus, und das wird sich vermutlich auch nie ändern, weil dann alle existierende Software plötzlich einen neuen Fehlercode kennen und handlen müsste. Merke Dir einfach, dass "Permission denied" auch durch AppArmor verursacht werden kann ;-)
Nebenfrage: Gibt's eigentlich eine zentrale Datei, wo eingetragen ist, was auf einem System per Distri-Default läuft bzw. aktiviert ist, und wo am besten auch automatisch eingetragen wird, wann man selber einen Dienst oder was auch immer aktiviert, neu konfiguriert u.s.w.. Wäre schon interessant, wenn man das von Distri-Version zu -Version vergleichen könnte, und freilich auch, um zu sehen, was man über die Jahre selber so 'verbrochen' hat. Das wäre sozusagen ein sehr, sehr langsamer Log, weil nur Admin-Aktionen aufgezeichnet würden. So könnte man auch gut nachvollziehen, wenn man etwas verbockt hat, besonders, wo Fehler erst viel später auftauchen.
Nicht direkt, aber es gibt ein paar Möglichkeiten: - rpm -Va listet alle veränderten Dateien (ggf. | grep /etc
verwenden)
- rpm -qf /eine/datei zeigt, zu welchem Paket eine Datei gehört bzw.> dass sie nicht zu einem Paket gehört
- etckeeper verwaltet /etc/ in git (habe ich nie getestet, wäre aber> für einen kurzen Bericht dankbar, falls es jemand einsetzt)
- verwende ein Konfigurationsmanagement-Tool wie Saltstack, Puppet o. ä.> und benutze nie "su" oder "sudo". Bei einem einzelnen Rechner ist das natürlich ein gewisser Overhead, dafür bekommst Du aber eine saubere Doku Deiner Config und kannst bei Bedarf einen neuen Rechner automatisch genau so konfigurieren. Bei mehreren (großteils) identisch konfigurierten Rechnern sollte es sogar Zeit sparen, weil Du alles nur 1x und nicht auf jedem Rechner machen musst
Die ersten zwei kenne ich natürlich und Versionsverwaltung mit CVS und Subversion sind mir geläufig und habe ich auch mal eine Zeit lang für Configs gemacht. Dann macht mir mein Admin-Diary aber doch weniger Aufwand. Aber beide haben den Nachteil, dass man sie pflegen und darin nachsehen muss ;-) Die Versionsverwaltung ist mir für die wenigen Änderungen in Jahren einfach zu hoch. Meine Systeme verändern sich nur langsam/selten und wenn, dann in Schüben. Das schreibe ich dann lieber manuell auf.
Laut Beschreibung von etckeeper ist zumindest das "dass man sie pflegen muss" automatisiert.
Ich muss auch gar nicht genau wissen, was ich in Configs und in welchen Schritten verändert habe (kann ich mit diffs zw. der Originalversion und dem aktuellen File rausbekommen), sondern ich hätte nur gerne einen Automatismus, der mir aufzeichnet, wann ich welche Dateien verändert und Dienste neu gestartet habe bzw. Configs neu eingelesen wurden. Könnte man mit einigem Aufwand sicher aus den Logs herausfiltern.
hmm, regelmäßig /root/.bash_history sichern? ;-) Dienste-Neustarts finden sich IIRC auch im audit.log, aber $EDITOR verewigt sich nicht darin.
[...] zunächst mal ein paar Zeilen aus /var/log/audit/audit.log:
type=AVC msg=audit(1476894139.994:14385): apparmor="DENIED" operation="open" profile="/usr/lib/dovecot/imap" name="/var/run/dovecot/mounts" pid=14664 comm="imap" requested_mask="r" denied_mask="r" fsuid=10000 ouid=0
Du kannst mit aa-logprof die AppArmor-Profile interaktiv updaten.
Was ist mit "interaktiv" updaten gemeint?
aa-logprof liest das audit.log, "übersetzt" es in Regeln für ein AppArmor-Profil und fragt für jedes Log-Ereignis nach, ob Du das erlauben willst. Teilweise kannst Du die Regeln auch noch anpassen, z. B. durch Wildcards im Dateinamen.
@{DOVECOT_MAILSTORE}/ rw, @{DOVECOT_MAILSTORE}/** rwkl,
"rw" ist klar, aber "kl"?
loc_k_ und hard_l_ink
Gibt's irgendwo eine Stelle, wo man alle Neuerungen von Distri-Version zu Distri-Version gesammelt und möglichst schön gegliedert und in einer gewissen Tiefe (oder gerne mit Links auf entsprechende Doku) nachlesen kann, damit man besser auf dem Laufenden bleibt?
Die Release Notes und das Release-Announcement sind ein guter Überblick über die wichtigsten Änderungen.
Aber nur von Release zu Release innerhalb der Version, und das ist schon viel Stoff. Würde man alle bis zu einer neuen Version lesen, hätte man die ersten schon wieder vergessen.
_Alle_ Neuerungen seit der letzten Version ergeben eine *sehr* lange Datei, die vermutlich eh niemand lesen würde.
Apropos: http://download.opensuse.org/distribution/leap/42.2/repo/oss/ und dort "ChangeLog". Die 57 MB Text enthalten alle Änderungen sein 1997. Wirklich lesen kann man das nicht, höchstens greppen.
Eben, wenn man sich aber auf die größeren Änderungen beschränken würde, z.B. welche Dienste neu und standardmäßig eingeschaltet sind, dann wäre die Datei viel kürzer.
Neue standardmäßig eingeschaltete Dienste würde ich sogar als wichtig genug für die Release Notes bezeichnen. Die schreiben sich natürlich nicht von selbst ;-) sondern es muss sich zumindest jemand beim Doku- Team melden und ein Stichwort (oder im Idealfall) gleich einen Text) mitliefern.
Zum Vergleich: Tumbleweed hat im Schnitt 4 Releases pro Woche, und die Changelog-Mail (für jedes dieser Releases, also für 2 Tage) ist meistens mehrere hundert Zeilen lang. Jetzt rechne Dir das auf ein jährliches Release hoch ;-)
Ja, klar, deswegen müsste man eher an der Oberfläche bleiben bzw. einen sinnvollen Kompromiss darüber finden, was man bringt und was nicht -- natürlich nur in einer extra Datei mit den großen Änderungen, nicht in den Release Notes, denn Kleinigkeiten können auch wichtig sein.
Damit hast Du schon die wichtigsten Probleme selbst rausgefunden ;-) - welche Meldungen sind zu unwichtig für die Release Notes, aber wichtig genug für die ausführlichere Datei? Und was ist unwichtig genug, um es zu ignorieren? - wer macht sich die Mühe, das rauszufiltern und zusammenzuschreiben? - selbst wenn pro Paket nur zwei Zeilen drinstehen, sind das in der Summe mehrere tausend Zeilen - wer liest das? (Manchmal wäre ich schon froh, wenn jeder wenigstens die Release Notes lesen würde ;-) Es gibt aber vermutlich wichtigere Baustellen (z. B. Aktualisierung der Wiki-Inhalte), bei denen der Nutzen der investierten Zeit größer ist. Trotzdem: Wenn Du sowas machen willst oder jemanden findest, der es machen will, wirst Du keine Gegenwehr sehen ;-) Mein Rat ist: Lies die Release Notes, und bei den für Dich "lebenswichtigen" Paketen zusätzlich rpm -q --changes
Vor langer, langer Zeit (noch SuSE) gab's mal einen Documentation Server im System, wo man im Browser auch Man Pages, die On-the-Fly nach HTML umgewandelt wurden, und viele andere Doku lesen konnte. Gibt's heute etwas entsprechendes?
http://doc.opensuse.org (zwar keine Manpages, aber eine ganze Menge Handbücher)
Naja, "einige" würde ich sagen.
Als SUSE vor langer Zeit noch gedruckte Handbücher lieferte, waren die ganz schön schwer. Seitdem sind noch etliche Dinge dazugekommen (z. B. Virtualisierung) - ich schätze mal, dass doc.opensuse.org ausgedruckt mehr als 1000 A4-Seiten ergäbe ;-)
Die Manpages findest Du auch irgendwo online, oder Du verwendest z. B. "man:apparmor.d" in Konqueror.
Ich komme schon klar mit man <Befehl> im Terminal, aber ein Doku-Crawler, von dem aus man zentral ein System oder sogar ein ganzes LAN, wenn man Doku-Server hat, nach Doku durchsuchen kann, wäre schon praktisch, auch zum Schmökern, wie in einer Buchhandlung. Da kommt man auf Schätzchen, die man sonst nicht finden würde.
Ich würde mal spontan man2html vorschlagen. Außerdem empfiehlt $Suchmaschine z. B. https://linux.die.net/man/ oder zum Selbermachen http://www.squarebox.co.uk/users/rolf/download/manServer.shtml ;-) Gruß Christian Boltz [1] unter der Annahme, dass ich beim Testen nichts falsch gemacht habe ;-) - bevor ich mich endgültig festlege, warte ich noch die Testergebnisse mindestens eines anderen AppArmor-Entwicklers ab. -- As usual, I'm voicing my opinion on this topic, not announcing "truth" ;) [Cristian Rodríguez in opensuse-factory] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/3ce160b3500131402c3a29bfb24732cc.jpg?s=120&d=mm&r=g)
Hallo Christian, Am 22.10.2016 um 21:20 schrieb Christian Boltz:
Hallo Thomas, hallo zusammen,
Am Samstag, 22. Oktober 2016, 16:05:01 CEST schrieb Thomas Michalka:
Am 21.10.2016 um 21:03 schrieb Christian Boltz:
Hallo Thomas, hallo zusammen,
Am Freitag, 21. Oktober 2016, 16:23:53 CEST schrieb Thomas Michalka:
[...]
[...] Es heißt ja auch "Unix perms seem to be ok (ACL/MAC wrong?)". Sonst hätte ich mich gar nicht an die Liste
MAC steht für Mandatory Access Control. AppArmor ist so ein MAC, SELinux ein anderes.
Danke, wieder eine dreibuchstabige Abkürzung gelernt ;-)
Dovecot ist also schon deutlich hilfreicher als die meisten anderen Programme, die einfach nur "Permission denied" melden ;-)
Ja, wenn man die Abkürzungen kennt ;-) Nein, es stimmt schon: die Meldungen sind ziemlich ausführlich. ACL hat so mancher schon gehört, kommt ja sogar im Konqueror/Dolphin. Aber MAC kannte ich bisher nur aus der Netzwerkterminologie.
gewandt, wenn ich an den Unix Permissions noch hätte drehen können. Oder AppArmor könnte sich gegenüber Dovecot offenbaren.
_Vermutlich_ wird das etwas schwierig. AppArmor arbeitet ja innerhalb des Kernels, und nach außen wird dann nur ein "Permission denied" (EPERM) rausgegeben, und eben der Eintrag im audit.log.
Das kannte ich auch noch nicht. Läuft das grundsätzlich das grundsätzlich neben dem syslog oder heute journal her?
Nebenfrage: Gibt's eigentlich eine zentrale Datei, wo eingetragen ist, was auf einem System per Distri-Default läuft bzw. aktiviert ist, und wo am besten auch automatisch eingetragen wird, wann man selber einen Dienst oder was auch immer aktiviert, neu konfiguriert u.s.w. [...]
Laut Beschreibung von etckeeper ist zumindest das "dass man sie pflegen muss" automatisiert.
Werde ich mir ansehen. Vielleicht passt das zu meinem Bedarf.
Ich muss auch gar nicht genau wissen, was ich in Configs und in welchen Schritten verändert habe (kann ich mit diffs zw. der Originalversion und dem aktuellen File rausbekommen), sondern ich hätte nur gerne einen Automatismus, der mir aufzeichnet, wann ich welche Dateien verändert und Dienste neu gestartet habe bzw. Configs neu eingelesen wurden. Könnte man mit einigem Aufwand sicher aus den Logs herausfiltern.
hmm, regelmäßig /root/.bash_history sichern? ;-)
Mache ich. Aber da stehen so viel irrelevante Dinge drin, dass man auch viel filtern muss.
Gibt's irgendwo eine Stelle, wo man alle Neuerungen von Distri-Version zu Distri-Version gesammelt und möglichst schön gegliedert und in einer gewissen Tiefe (oder gerne mit Links auf entsprechende Doku) nachlesen kann, damit man besser auf dem Laufenden bleibt?
[...]
Neue standardmäßig eingeschaltete Dienste würde ich sogar als wichtig genug für die Release Notes bezeichnen.
Schon, aber solche Infos müssen auch in einer deutlich kanppere Zusammenfassung rein.
Die schreiben sich natürlich nicht von selbst ;-) sondern es muss sich zumindest jemand beim Doku- Team melden und ein Stichwort (oder im Idealfall) gleich einen Text) mitliefern.
Dann müsste diese/r jemand aber aus erster Hand die Neuerungen erfahren und gleich einem Redakteur diese redaktioniell aufbereiten und veröffentlichen. Ich nehme an, den/die Redakteur/e/innen gibt es. Dann müsste es dafür einen Blog oder eine ML geben, wie z.B. für KDE die Neuerungen bzgl. der Versionen veröffentlicht werden.
Zum Vergleich: Tumbleweed hat im Schnitt 4 Releases pro Woche,
Mir würden Infos über größere Änderungen von Hauptversion zu Hauptversion genügen.
und die Changelog-Mail (für jedes dieser Releases, also für 2 Tage) ist meistens mehrere hundert Zeilen lang. Jetzt rechne Dir das auf ein jährliches Release hoch ;-)
Ja, klar, deswegen müsste man eher an der Oberfläche bleiben bzw. einen sinnvollen Kompromiss darüber finden, was man bringt und was nicht -- natürlich nur in einer extra Datei mit den großen Änderungen, nicht in den Release Notes, denn Kleinigkeiten können auch wichtig sein.
Damit hast Du schon die wichtigsten Probleme selbst rausgefunden ;-) - welche Meldungen sind zu unwichtig für die Release Notes,
Keine, denn ich verstehe die Release Notes so, dass alles, was geändert bzw. neu ist, dort drinsteht. Oder verstehe ich den Sinn der RN falsch?
aber wichtig genug für die ausführlichere Datei?
Nicht ausführlicher, denn das ausführlichste sind doch die Release Notes, oder? Es braucht eine _zusammenfassende_ Beschreibung von Änderungen. Ob von Hauptversion zu Hauptversion oder von Unterversion (.x) zu Unterversion, muss man sich überlegen bzw. hängt davon ab, ob es gravierende Neuerungen gibt. Nur als Beispiel: als Kriterium könnte gelten, dass man eine Konfig (Dovecot 1.x -> 2.2) anpassen muss, oder das etwas grundlegend anders funktioniert und das Verständnis darüber ist wichtig.
Und was ist unwichtig genug, um es zu ignorieren?
Für die RN nichts. Für eine Zusammenfassung der wichtigsten Änderungen fast alles ;-)
- wer macht sich die Mühe, das rauszufiltern und zusammenzuschreiben?
Ein/e Redakteur/in oder ein entsprechendes Team.
- selbst wenn pro Paket nur zwei Zeilen drinstehen, sind das in der Summe mehrere tausend Zeilen - wer liest das?
Kaum jemand. Aber warum wird es dann so detailliert aufgeschrieben? Ich nehme aber an, dass die RN automatisch erzeugt werden.
(Manchmal wäre ich schon froh, wenn jeder wenigstens die Release Notes lesen würde ;-)
Warum, was bringt dir das? Die Anwender (hierunter fallen für mich jetzt auch solche, die die Syteme administrativ 'anwenden') wollen zunächst möglichst wenig lesen. Nur für die von Ihnen genutzen oder betreuten Funktionen brauchen sie detalliertere Infos, die man sich dann aber meistens aus der Doku oder aus dem Netz holt (von denen, die schon einige Zeit damit umgehen und somit über die entsprechenden Detailerfahrungen verfügen). Aber die Anwender und Admins brauchen bei brandneuen Änderungen knappe, aussagekräftige Infos über die gravierendsten dieser Änderungen. Tatsächlich braucht es für solche Zusammenfassungen redaktionelle Arbeit, die gerade die Aufgabe hat, das Wesentliche von den vielen Details zu trennen. Die Leserzielgruppe wären, wie gesagt, Anwender, Admins u.s.w. Wer es dann noch detaillierter braucht, kann ja die Release Notes und andere Quellen lesen. Allerdings sollten schon die Paket-Maintainer die 'größeren' Änderungen in ein paar Zeilen mit Stichworten aufschreiben können. Findet ein/e Redakteur/in etwas davon interessant genug, könnte er/sie dem genauer nachgehen, falls man damit etwas verständlicher machen kann. Es ist ja gerade die Kunst, so wenig wie möglich, aber so viel wie nötig (damit es verständlich ist) zu schreiben.
Es gibt aber vermutlich wichtigere Baustellen (z. B. Aktualisierung der Wiki-Inhalte), bei denen der Nutzen der investierten Zeit größer ist.
Schon, aber das kommt doch meistens erst allmählich nach den neuen Distri-Versionen, wenn die Masse der Anwender und Admins (nicht die ersten Tester) die neuen Sachen ausführlich ausprobiert haben. Das braucht ja Zeit.
Trotzdem: Wenn Du sowas machen willst oder jemanden findest, der es machen will, wirst Du keine Gegenwehr sehen ;-)
Wenn ich von einer zentralen Stelle in Stichworten die Infos bekäme, könnte ich daraus schon zusammenhängenden Text machen.
Mein Rat ist: Lies die Release Notes, und bei den für Dich "lebenswichtigen" Paketen zusätzlich rpm -q --changes
Du meintest wohl --changelog. Die Crux damit ist aber, dass man daraus nur erfährt, was sich innerhalp des Pakets geändert hat, aber nicht, wenn z.B. ein Dienst wie AppArmor neu eingeführt und standardmäßig eingeschaltet wird. Und, ehrlich gesagt -- ich habe mir gerade den Changelog von Dovecot 2.2 angesehen --, was interessieren mich als Anwender bzw. Admin die einzelnen Fixes? Anwender brauchen Infos darüber, was die Fixes für Konsequenzen im Anwender- bzw. Adminleben haben, also in einer anderen Form, auf einer anderen Ebene. Leider können oder wollen sich Entwickler oft nicht in andere Menschen hineinversetzen. Dabei sind sie doch auch Menschen, die nicht in allen Dingen Experten sind und sich deshalb nicht so leicht tun mit dieser oder jener Expertensprache. Weniger TechSpeech, dann hätten es viele leichter.
[...]
Ich komme schon klar mit man <Befehl> im Terminal, aber ein Doku-Crawler, von dem aus man zentral ein System oder sogar ein ganzes LAN, wenn man Doku-Server hat, nach Doku durchsuchen kann, wäre schon praktisch, auch zum Schmökern, wie in einer Buchhandlung. Da kommt man auf Schätzchen, die man sonst nicht finden würde.
Ich würde mal spontan man2html vorschlagen. Außerdem empfiehlt $Suchmaschine z. B. https://linux.die.net/man/ oder zum Selbermachen http://www.squarebox.co.uk/users/rolf/download/manServer.shtml ;-)
Mir geht es nicht nur um Manpages, sondern um die ganze Doku, die auf meinen Systemen mitgeliefert ist. Die würde ich gerne über eine einzige Webadresse intern oder auf eine andere Weise durchsuchen können. So, dass ich sicher sein kann, keine Stelle zu übersehen. Gruß, Thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/b58101fb24c64d0ff1d0f918e61cedd2.jpg?s=120&d=mm&r=g)
Hallo Thomas, hallo zusammen, Am Mittwoch, 26. Oktober 2016, 18:13:48 CEST schrieb Thomas Michalka:
Am 22.10.2016 um 21:20 schrieb Christian Boltz:
Am Samstag, 22. Oktober 2016, 16:05:01 CEST schrieb Thomas Michalka:
Am 21.10.2016 um 21:03 schrieb Christian Boltz:
Am Freitag, 21. Oktober 2016, 16:23:53 CEST schrieb Thomas Michalka: [...] gewandt, wenn ich an den Unix Permissions noch hätte drehen können. Oder AppArmor könnte sich gegenüber Dovecot offenbaren.
_Vermutlich_ wird das etwas schwierig. AppArmor arbeitet ja innerhalb des Kernels, und nach außen wird dann nur ein "Permission denied" (EPERM) rausgegeben, und eben der Eintrag im audit.log.
Das kannte ich auch noch nicht. Läuft das grundsätzlich das grundsätzlich neben dem syslog oder heute journal her?
"Eintrag ins audit.log" war stark vereinfacht ;-) Ich versuche es mal zu erklären - allerdings ohne Gewähr, weil ich nicht alle Kernel-Details kenne. Falls Du es ganz genau wissen willst, frag auf der AppArmor-Mailingliste oder im IRC-Channel nach. John Johansen kennt vermutlich die ganzen Details und kann das auch gut erklären. Also: der Kernel schreibt die Meldungen erstmal in den "kernel ring buffer", den Du mit dmesg abfragen kannst. Außerdem gibt es im Kernel ein sogenanntes "audit subsystem", das u. a. für die AppArmor- Meldungen zuständig ist, aber auf Wunsch auch beliebige Dateien, Syscalls etc. überwachen kann [1]. Falls Du auditd laufen hast (ja, parallel zu syslog oder journal), greift der die Kernel-Meldungen des audit subsystem ab und schreibt sie nach /var/log/audit/audit.log Ohne laufenden auditd landen die Meldungen übers dmesg-Interface im normalen Syslog oder journal. Die haben allerdings ein rate limiting - falls also viele Meldungen auf einmal kommen, geht ein Teil verloren. Sprich: auditd ist optional, aber empfehlenswert. Wenn man AppArmor ernsthaft nutzt, sogar ziemlich empfehlenswert ;-)
Gibt's irgendwo eine Stelle, wo man alle Neuerungen von Distri-Version zu Distri-Version gesammelt und möglichst schön gegliedert und in einer gewissen Tiefe (oder gerne mit Links auf entsprechende Doku) nachlesen kann, damit man besser auf dem Laufenden bleibt?
[...]
Neue standardmäßig eingeschaltete Dienste würde ich sogar als wichtig genug für die Release Notes bezeichnen.
Schon, aber solche Infos müssen auch in einer deutlich kanppere Zusammenfassung rein.
Das wäre quasi rpm -q --changelog systemd-presets-branding-openSUSE
Die schreiben sich natürlich nicht von selbst ;-) sondern es muss sich zumindest jemand beim Doku- Team melden und ein Stichwort (oder im Idealfall) gleich einen Text) mitliefern.
Dann müsste diese/r jemand aber aus erster Hand die Neuerungen erfahren und gleich einem Redakteur diese redaktioniell aufbereiten und veröffentlichen. Ich nehme an, den/die Redakteur/e/innen gibt es. Dann müsste es dafür einen Blog oder eine ML geben, wie z.B. für KDE die Neuerungen bzgl. der Versionen veröffentlicht werden.
Neuerungen erfahren ist einfach, z. B. - durch Mitlesen der opensuse-factory-ML - durch Lesen der "New Tumbleweed snapshot released"-Mails auf der factory-ML - oder zumindest Lesen der wöchentlichen Zusammenfassung zu Tumbleweed auf news.opensuse.org - wobei diese (händische) Zusammenfassung schon wieder viele Details auslässt. Das Problem ist, "diese/r jemand", der/die das filtert, zusammenfasst und aufbereitet, zu finden ;-))
Zum Vergleich: Tumbleweed hat im Schnitt 4 Releases pro Woche,
Mir würden Infos über größere Änderungen von Hauptversion zu Hauptversion genügen.
Da sind wir wieder bei der Definitionsfrage von "große Änderungen" ;-)
Damit hast Du schon die wichtigsten Probleme selbst rausgefunden ;-) - welche Meldungen sind zu unwichtig für die Release Notes,
Keine, denn ich verstehe die Release Notes so, dass alles, was geändert bzw. neu ist, dort drinsteht. Oder verstehe ich den Sinn der RN falsch?
Die Release Notes für verschiedene Releases kannst Du auf https://en.opensuse.org/Release_Notes nachlesen. Im Verhältnis zur Menge der Änderungen sind die ziemlich kurz. Außerdem gibt es Seiten wie https://en.opensuse.org/Features die etwas ausführlicher, aber eher mit Marketing-Hintergrund geschrieben sind.
aber wichtig genug für die ausführlichere Datei?
Nicht ausführlicher, denn das ausführlichste sind doch die Release Notes, oder? Es braucht eine _zusammenfassende_ Beschreibung von Änderungen. Ob von Hauptversion zu Hauptversion oder von Unterversion (.x) zu Unterversion, muss man sich überlegen bzw. hängt davon ab, ob es gravierende Neuerungen gibt. Nur als Beispiel: als Kriterium könnte gelten, dass man eine Konfig (Dovecot 1.x -> 2.2) anpassen muss, oder das etwas grundlegend anders funktioniert und das Verständnis darüber ist wichtig.
Und alle, die kein Dovecot nutzen (vermutlich 95% der User, weil es ja auch etliche Desktop-User gibt), interessieren sich nicht dafür ;-) Ich sage nicht, dass Dein Beispiel nicht in die Release Notes gehört - aber mit mehreren tausend Paketen könnte auf diese Art eine ziemlich lange Liste zusammenkommen. Daher kommen nur die wichtigsten in die Release Notes.
Und was ist unwichtig genug, um es zu ignorieren?
Für die RN nichts. Für eine Zusammenfassung der wichtigsten Änderungen fast alles ;-)
Die RN sind (zumindest derzeit) eher letzteres ;-)
- wer macht sich die Mühe, das rauszufiltern und zusammenzuschreiben?
Ein/e Redakteur/in oder ein entsprechendes Team.
Ach, der/die "jemand", die wir oben schon gesucht haben? ;-)
- selbst wenn pro Paket nur zwei Zeilen drinstehen, sind das in der
Summe mehrere tausend Zeilen - wer liest das?
Kaum jemand. Aber warum wird es dann so detailliert aufgeschrieben?
Es gibt verschiedene Ebenen von Changelogs ;-) Erstmal eins pro Paket - da macht es Sinn, alles detailiert aufzuschreiben, um Änderungen nachvollziehen zu können (z. B. wann ein Patch aufgenommen wurde, wann und warum ein configure-Parameter geändert wurde etc.). Tatsächlich gelesen wird das a) von den Reviewern, wenn ein Paket zu Leap oder Tumbleweed submitted wird b) von Review-Bots (die prüfen z. B., ob neue oder entfernte Patches im Changelog stehen) und c) wenn man irgendwann mal einem Fehler nachjagt. In der Summe also eher selten. Die "ChangeLog"-Datei im Repo [2] wird automatisch (aus allen Paket- Changelogs) erzeugt. Alles, was kürzer und zusammengefasst ist (siehe die Links weiter oben), ist Handarbeit.
Ich nehme aber an, dass die RN automatisch erzeugt werden.
Nö, die sind Handarbeit.
(Manchmal wäre ich schon froh, wenn jeder wenigstens die Release Notes lesen würde ;-)
Warum, was bringt dir das? Die Anwender (hierunter fallen für mich jetzt auch solche, die die Syteme administrativ 'anwenden') wollen zunächst möglichst wenig lesen. Nur für die von Ihnen genutzen oder betreuten Funktionen brauchen sie detalliertere Infos, die man sich dann aber meistens aus der Doku oder aus dem Netz holt (von denen, die schon einige Zeit damit umgehen und somit über die entsprechenden Detailerfahrungen verfügen). Aber die Anwender und Admins brauchen bei brandneuen Änderungen knappe, aussagekräftige Infos über die gravierendsten dieser Änderungen.
Tatsächlich braucht es für solche Zusammenfassungen redaktionelle Arbeit, die gerade die Aufgabe hat, das Wesentliche von den vielen Details zu trennen. Die Leserzielgruppe wären, wie gesagt, Anwender, Admins u.s.w. Wer es dann noch detaillierter braucht, kann ja die Release Notes und andere Quellen lesen. Allerdings sollten schon die
Siehe oben - die Release Notes sind genau die zusammengefassten wichtigen Änderungen, die Du suchst. (Wäre es jetzt boshaft zu fragen, ob Du die gelesen hast? ;-)
Paket-Maintainer die 'größeren' Änderungen in ein paar Zeilen mit Stichworten aufschreiben können. Findet ein/e Redakteur/in etwas davon interessant genug, könnte er/sie dem genauer nachgehen, falls man damit etwas verständlicher machen kann. Es ist ja gerade die Kunst, so wenig wie möglich, aber so viel wie nötig (damit es verständlich ist) zu schreiben.
So funktioniert das prinzipiell - die Paket-Maintainer (und jeder andere) können Einträge für die Release Notes einreichen. Nur machen das leider nicht alle Paket-Maintainer, sodass manchmal etwas unentdeckt am Doku-Team vorbeirauscht.
Es gibt aber vermutlich wichtigere Baustellen (z. B. Aktualisierung der Wiki-Inhalte), bei denen der Nutzen der investierten Zeit größer ist. Schon, aber das kommt doch meistens erst allmählich nach den neuen Distri-Versionen, wenn die Masse der Anwender und Admins (nicht die ersten Tester) die neuen Sachen ausführlich ausprobiert haben. Das braucht ja Zeit.
Das braucht leider _viiiiieeeel_ Zeit. Die meisten Wiki-Seiten sind mehrere Releases alt... Das ist nicht immer schlimm, in einigen Fällen aber schon.
Trotzdem: Wenn Du sowas machen willst oder jemanden findest, der es machen will, wirst Du keine Gegenwehr sehen ;-)
Wenn ich von einer zentralen Stelle in Stichworten die Infos bekäme, könnte ich daraus schon zusammenhängenden Text machen.
Siehe meine Vorschläge oben ;-)
Mein Rat ist: Lies die Release Notes, und bei den für Dich "lebenswichtigen" Paketen zusätzlich rpm -q --changes
Du meintest wohl --changelog. Die Crux damit ist aber, dass man daraus
Äh, ja. rpm -q --cha<tab> eben ;-)
nur erfährt, was sich innerhalp des Pakets geändert hat, aber nicht, wenn z.B. ein Dienst wie AppArmor neu eingeführt und standardmäßig eingeschaltet wird. Und, ehrlich gesagt -- ich habe mir gerade den Changelog von Dovecot 2.2 angesehen --, was interessieren mich als Anwender bzw. Admin die einzelnen Fixes? Anwender brauchen Infos darüber, was die Fixes für Konsequenzen im Anwender- bzw. Adminleben haben, also in einer anderen Form, auf einer anderen Ebene. Leider können oder wollen sich Entwickler oft nicht in andere Menschen hineinversetzen. Dabei sind sie doch auch Menschen, die nicht in allen Dingen Experten sind und sich deshalb nicht so leicht tun mit dieser oder jener Expertensprache. Weniger TechSpeech, dann hätten es viele leichter.
Siehe die Zielgruppe der Paket-Changelogs weiter oben. Ich wage zu behaupten, dass die wenigsten Benutzer je ein Paket-Changelog gelesen haben. Klar, es gibt verständliche und weniger verständliche Wege, das Changelog zu schreiben. Trotzdem werden die Paket-Changelogs nie meine Oma als Zielgruppe ansehen ;-) sondern mindestens Admins, die zumindest etwas Ahnung haben.
[...]
Ich komme schon klar mit man <Befehl> im Terminal, aber ein Doku-Crawler, von dem aus man zentral ein System oder sogar ein ganzes LAN, wenn man Doku-Server hat, nach Doku durchsuchen kann, wäre schon praktisch, auch zum Schmökern, wie in einer Buchhandlung. Da kommt man auf Schätzchen, die man sonst nicht finden würde.
Ich würde mal spontan man2html vorschlagen. Außerdem empfiehlt $Suchmaschine z. B. https://linux.die.net/man/ oder zum Selbermachen http://www.squarebox.co.uk/users/rolf/download/manServer.shtml ;-)
Mir geht es nicht nur um Manpages, sondern um die ganze Doku, die auf meinen Systemen mitgeliefert ist. Die würde ich gerne über eine einzige Webadresse intern oder auf eine andere Weise durchsuchen können. So, dass ich sicher sein kann, keine Stelle zu übersehen.
Keine Ahnung, ob es sowas gibt. IIRC wurden die Handbücher immer auch als Pakete mit angeboten, den aktuellen Stand kenne ich aber nicht. Davon abgesehen - besser als Google/Startpage/$andere_Suchmaschine wirst Du eine interne Suche nicht hinbekommen ;-) Die einzige Doku, die ich noch lokal lese, sind manpages. Alles andere ist online deutlich einfacher. Gruß Christian Boltz [1] siehe dazu http://security.blogoverflow.com/2013/01/a-brief-introduction-to-auditd/ [2] http://download.opensuse.org/distribution/leap/42.2/repo/oss/ -> ChangeLog -- There are likely quite some packages where the daemon itself is worse than the init script anyways :-) [Ludwig Nussel in opensuse-packaging] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (2)
-
Christian Boltz
-
Thomas Michalka