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