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