Mir ist das Kommando durchaus bekannt. Nur ersetzt es nicht die von mir bekannte Flexibilität.
Mit VIM habe ich sytax highlighting, kann alte Einträge schnell markieren und weglöschen. Kann schnell hin und herscrollen und finde mich allgemein besser zurecht.
Mit journalctl bekomne ich immer die Ausgaben des logs vom Tag 1 an. Habe mal was mit journalctl -b 1 gelesen. Hat aber auch nix gebracht. Ich muss aber zugeben, dass mich diese Binärsache so sehr ankotzt, dass ich mir nur 1-2x die manpage zu journalctl ansah. Für mich ist journalctl ein Fremdkörper.
Von Martin1991zab am Mo, 22. September 2014 um 13:18 #
Gut dann muss ich dir aber vorwerfen das du deine Anschuldigungen eher gegen dich selbst richten must.
Zum Punkt zum löschen einzelner Logeinträge hab ich jetzt auf die schnelle auch nichts gefunden, aber da muss ich auch aus Programmierer-/ Adminsicht sagen: es ist ein Log und aus einem Log löscht man keine einzelnen Einträge. Entweder man löscht es vollständig oder man kopiert/ filtert sich die benötigten raus. Bei allem anderen wäre es manipulierbar und somit weniger vertrauenswürdig.
Wenn du unbedingt vim zum verarbeiten nutzen willst besteht halt die Möglichkeit das ganze in eine Datei zu schubsten. Oder direkt zu verarbeiten: (*kurz mal googlen*) # journalctl | vim -
Von Trollhorst am Mo, 22. September 2014 um 14:11 #
aber da muss ich auch aus Programmierer-/ Adminsicht sagen
So etwas von bescheuert. Aus Programmierer-/Adminsicht muss ich mal sagen: Wenn solche einfachen Sachen nicht gehen und dann jemand kommt und sagt "du machst das falsch" gibts einen auf den Löffel. Wieder und wieder bis Verstand einkehrt.
Manipulierter geht's kaum. Du findest nichtmal Spuren vom Log, da alles binär ist. Beim alten Format hätte man noch die Festplatte per dump scannen können.
Bei ASCII Text kannst du mit einem normalen Hexeditor noch nach Einträgen in deinem Dumpfile suchen und sind somit leicht zu finden. Bei Binärdaten können die Informationen zwar auch noch vorhanden sein, aber diese zu finden, das dürfte das wesentliche Problem sein.
Bei Binärdaten kann man nach den Header-Informationen und der Dateistruktur suchen. Wird z.B. bei JPG Dateien genauso gemacht.
Aber abgesehen davon bringt das sowieso nichts. Wenn jemand mutwillig die Logs löscht, dann helfen auch die Hälfte der Logs nicht, denn woher will man wissen, dass die Logs nicht manipuliert sind? Oder auf Grund des Dateisystems gerade die Teile fehlen, die wichtig sind?
Achja? Systemd definiert sein Binärformat ausdrücklich nicht und warnt dafür darauf zu bauen. Man solle lieber die eigenen Tools nutzen. Und ob die Löschung/Manipulation unentdeckt bleibt, hängt von der Signierung ab. Es gibt Syslog die das auch schon vor Systemd getan haben, ist also kein wirkliche neues Feature.
Das Einzige, was in die Richtung geht ist die Aussage: "Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right."
Wird aber gleich wieder etwas entschärft mit: "That said we'll of course try hard to keep this document up-to-date and accurate."
Die Informationen würden jedenfalls reichen um die Dateien, soweit noch rekonstruierbar, aufzufinden und wiederherzustellen. Mal ganz abgesehen davon, dass das auch mit Dateien gemacht wird, deren Struktur nur per Reverse Engineering bekannt ist (z.B. RAW Dateien).
Man solle lieber die eigenen Tools nutzen.
Jein, das stimmt so nicht. Die eigentliche Aussage ist: "Instead of implementing your own reader or writer for journal files we ask you to use the Journal's native C API to access these files. It provides you with full access to the files, and will not withhold any data. If you find a limitation, please ping us and we might add some additional interfaces for you." Das ist aber ganz normal und logisch. Gehört meiner Meinung nach auch zu einem ordentlichen Logging-Dienst dazu, d.h. sowohl das Schreiben der Logdaten, als auch den Zugriff auf diese zu unterstützen. Egal, ob die Logdaten nun als ASCII Text gespeichert werden oder in einem anderen Format. Ist auch genau das was mir bei syslog-ng/rsyslog immer gefehlt hat, ein Programm, welches den Zugriff auf die Logdaten brauchbar gestaltet. Gäbe es sowas wie journalctl für diese, wäre ich ein Stück weit zufriedener gewesen. Mit grep & Co im Log rumwurschteln fand ich immer sehr halbgar.
Und ob die Löschung/Manipulation unentdeckt bleibt, hängt von der Signierung ab. Es gibt Syslog die das auch schon vor Systemd getan haben, ist also kein wirkliche neues Feature.
Das stimmt. Genutzt wurde es aber selten und schon gar nicht per Default.
Ist ein bisschen wie mit der Datei .xsession-errors. Inzwischen loggen ja immer mehr Programme ins Journal (soweit verfügbar) und nicht mehr in besagte Datei. Das ist wirklich ein Segen, denn die .xsession-errors war echt ein furchtbares Chaos. Prinzipiell hätte man das auch früher schon machen können. Hat in der Realität aber praktisch niemand gemacht. Zum Glück hat das Journal aber dazu geführt, dass (optional, soweit verfügbar) da ein Umdenken stattgefunden hat.
Nur ersetzt es nicht die von mir bekannte Flexibilität.
Tja, so unterschiedlich können die Ansprüche sein. Ich fand immer die fehlende Flexibiltät bei rsyslog/syslog-ng nervig, da ich mir mühsam die Information, die ich haben wollte, zusammenklauben musste. journalctl empfinde ich persönlich als wesentlich flexibler.
Mit VIM habe ich sytax highlighting, kann alte Einträge schnell markieren und weglöschen. Kann schnell hin und herscrollen und finde mich allgemein besser zurecht.
Man kann vim als Pager (vimpager) nutzen. journalctl kann auch in klassischer syslog-Formatierung ausgeben, damit sollte dann sogar das Syntax-Highlighting funktionieren.
Mit journalctl bekomne ich immer die Ausgaben des logs vom Tag 1 an. Habe mal was mit journalctl -b 1 gelesen.
Was du suchst ist journalctl -b0. -b1 ist der erste Boot. -b -1 der vorherige.
journalctl kann sehr sehr nützlich sein, da es direkt filtern kann, z.B. auch per Unit, Programm o.ä. Also das was man (teilweise sehr umständlich) mittels grep machte.
Das Grundproblem ist weniger journald oder dessen binären Log-Dateien, sondern die Gewohnheit des Benutzers.
Die IT-Historie ist gespickt mit solchen Geschichten. Alles was neu ist, wird erst einmal mit den haarsträubendsten Argumenten abgelehnt (Ich nehm mich da persönlich nicht aus). ITler sind mitunter die konservativsten Menschen die es gibt.
Ja, da ist teilweise sehr wenig Anpassungswillen da.
Zugegeben, am Anfang wirkt das schon etwas ungewohnt, die Logs mit journalctl auszugeben, allerdings habe ich das inzwischen wirkllich zu schätzen gelernt. Ich nutze z.B. sehr häufig so etwas wie: journalctl --user -b0 /usr/bin/irgendeinprogramm
Damit erhalte ich die für mich relevanten Daten, z.B. weil irgendwas gerade ein Problem hat, ohne groß vorher Zeit investieren zu müssen. Bei syslog hatte ich teilweise 2 Tage damit verbracht, verschiedene Dienste in verschiedene Dateien umzuleiten, damit ich schneller an die relevanten Infos komme und war trotzdem noch lange nicht zufrieden mit dem Ergebnis. Jetzt muss ich keine Vorbereitungen mehr treffen und erhalte trotzdem besser Informationen.
Dennoch ist journald/journalctl noch nicht komplett ausgereift, es fehlt hier und da noch an Funktionalität (wie z.B. bei besagten core dumps).
Zudem kommt der Umstand, dass sich die Verantwortung und Anforderungen an alte IT'ler auch ändert. Manche sind vom Admin auch in leitende apositionen versetzt worden und befassen sich nun mit anderen Aufgaben. Da hat man nicht immer Zeit fürs Neulernen der Tools. Man hat mit seinen Kernaufgaben u.U. bereits genug Neuland betreten.
Das heißt also, auf Grund der Tatsache, dass manche Menschen keine Zeit oder Motivation haben sich in etwas einzuarbeiten, darf es keine Veränderung mehr geben?
Naja...
Abgesehen davon kostet es gar nicht so viel Zeit sich in systemd einzuarbeiten. Es ist wohl doch eher eine Frage der Motivation. Die kann einem aber selbstverständlich niemand vorschreiben, das ist klar.
Versuche es mal ohne die Augen eines IT Menschen zu sehen. Es soll Menschen geben, die machen den ganzen Tag auch was anderes.
Was meinst du, warum Bei MS das Win 8 ziemlich extrem verrissen wurde? Da dachte so ein Heini, man müsste bewährte Konzepte grundlegend erneuern. Warum ist Gnome 3 im Nirvana verschwunden (bildlich gesprochen)? Weil da auch so ein Heini meinte, bewährtes grundlegend ändern zu müssen.
Änderungen müssen kommuniziert und iterativ eingeführt werden.
Von Martin1991zab am Mo, 22. September 2014 um 15:47 #
Aber hier geht es um Hintergrundtätigkeiten und nicht um grafische Oberflächen. Was im Hintergrund passiert ist dem "normalen" Anwender herzlich egal (solange es läuft).
Du hörst auch selten (eigentlich fast nie) Beschwerden von "normalen" Anwendern das Windows alleine jetzt 10 bis 30 Gb friesst. Nur über die Oberfläche wird gemotzt.
Von perter lustig am Mi, 1. Oktober 2014 um 17:10 #
lustig wie sich leute über binäre datei aufregen obwohl sie selber immer ein programm nutzen müssen um klartext auslesen zu können. bleibt im jahr 1980 aber lasst bitte die menschen inruhe die verbessern wollen. danke.
# journalctl
Quelle: https://wiki.archlinux.org/index.php/systemd#Journal
Mir ist das Kommando durchaus bekannt. Nur ersetzt es nicht die von mir bekannte Flexibilität.
Mit VIM habe ich sytax highlighting, kann alte Einträge schnell markieren und weglöschen. Kann schnell hin und herscrollen und finde mich allgemein besser zurecht.
Mit journalctl bekomne ich immer die Ausgaben des logs vom Tag 1 an. Habe mal was mit journalctl -b 1 gelesen. Hat aber auch nix gebracht. Ich muss aber zugeben, dass mich diese Binärsache so sehr ankotzt, dass ich mir nur 1-2x die manpage zu journalctl ansah. Für mich ist journalctl ein Fremdkörper.
Gut dann muss ich dir aber vorwerfen das du deine Anschuldigungen eher gegen dich selbst richten must.
Zum Punkt zum löschen einzelner Logeinträge hab ich jetzt auf die schnelle auch nichts gefunden, aber da muss ich auch aus Programmierer-/ Adminsicht sagen: es ist ein Log und aus einem Log löscht man keine einzelnen Einträge. Entweder man löscht es vollständig oder man kopiert/ filtert sich die benötigten raus. Bei allem anderen wäre es manipulierbar und somit weniger vertrauenswürdig.
Wenn du unbedingt vim zum verarbeiten nutzen willst besteht halt die Möglichkeit das ganze in eine Datei zu schubsten.
Oder direkt zu verarbeiten: (*kurz mal googlen*)
# journalctl | vim -
aber da muss ich auch aus Programmierer-/ Adminsicht sagen
So etwas von bescheuert. Aus Programmierer-/Adminsicht muss ich mal sagen: Wenn solche einfachen Sachen nicht gehen und dann jemand kommt und sagt "du machst das falsch" gibts einen auf den Löffel. Wieder und wieder bis Verstand einkehrt.
Es geht nicht um "falsch" sondern um Sicherheit. Solche Daten dürfen/ sollten nicht manipulierbar sein.
Toll:
rm -rf /var/log/journal*
Manipulierter geht's kaum. Du findest nichtmal Spuren vom Log, da alles binär ist. Beim alten Format hätte man noch die Festplatte per dump scannen können.
Bei ASCII Text kannst du mit einem normalen Hexeditor noch nach Einträgen in deinem Dumpfile suchen und sind somit leicht zu finden.
Bei Binärdaten können die Informationen zwar auch noch vorhanden sein, aber diese zu finden, das dürfte das wesentliche Problem sein.
Bei Binärdaten kann man nach den Header-Informationen und der Dateistruktur suchen. Wird z.B. bei JPG Dateien genauso gemacht.
Aber abgesehen davon bringt das sowieso nichts. Wenn jemand mutwillig die Logs löscht, dann helfen auch die Hälfte der Logs nicht, denn woher will man wissen, dass die Logs nicht manipuliert sind?
Oder auf Grund des Dateisystems gerade die Teile fehlen, die wichtig sind?
Ne, das finde ich nicht überzeugend.
Achja? Systemd definiert sein Binärformat ausdrücklich nicht und warnt dafür darauf zu bauen. Man solle lieber die eigenen Tools nutzen.
Und ob die Löschung/Manipulation unentdeckt bleibt, hängt von der Signierung ab. Es gibt Syslog die das auch schon vor Systemd getan haben, ist also kein wirkliche neues Feature.
Das Einzige, was in die Richtung geht ist die Aussage:
"Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right."
Wird aber gleich wieder etwas entschärft mit:
"That said we'll of course try hard to keep this document up-to-date and accurate."
Die Informationen würden jedenfalls reichen um die Dateien, soweit noch rekonstruierbar, aufzufinden und wiederherzustellen. Mal ganz abgesehen davon, dass das auch mit Dateien gemacht wird, deren Struktur nur per Reverse Engineering bekannt ist (z.B. RAW Dateien).
Jein, das stimmt so nicht. Die eigentliche Aussage ist:"Instead of implementing your own reader or writer for journal files we ask you to use the Journal's native C API to access these files. It provides you with full access to the files, and will not withhold any data. If you find a limitation, please ping us and we might add some additional interfaces for you."
Das ist aber ganz normal und logisch. Gehört meiner Meinung nach auch zu einem ordentlichen Logging-Dienst dazu, d.h. sowohl das Schreiben der Logdaten, als auch den Zugriff auf diese zu unterstützen. Egal, ob die Logdaten nun als ASCII Text gespeichert werden oder in einem anderen Format.
Ist auch genau das was mir bei syslog-ng/rsyslog immer gefehlt hat, ein Programm, welches den Zugriff auf die Logdaten brauchbar gestaltet. Gäbe es sowas wie journalctl für diese, wäre ich ein Stück weit zufriedener gewesen. Mit grep & Co im Log rumwurschteln fand ich immer sehr halbgar.Das stimmt. Genutzt wurde es aber selten und schon gar nicht per Default.
Ist ein bisschen wie mit der Datei .xsession-errors. Inzwischen loggen ja immer mehr Programme ins Journal (soweit verfügbar) und nicht mehr in besagte Datei. Das ist wirklich ein Segen, denn die .xsession-errors war echt ein furchtbares Chaos.
Prinzipiell hätte man das auch früher schon machen können. Hat in der Realität aber praktisch niemand gemacht. Zum Glück hat das Journal aber dazu geführt, dass (optional, soweit verfügbar) da ein Umdenken stattgefunden hat.
Nicht jein sondern ja, nur Deppen die ständig ihren Code nachziehen wollen, implementieren das selbst.[1]
http://www.freedesktop.org/wiki/Software/systemd/journal-files/
wieso die Daten wurden dann doch nicht manipuliert sondern gelöscht und sowas kiregt man schon mit (die verschwinden ja nicht einfach)
... hat das meistens einen guten Grund. Im Fall von journald wird der explizit in der Produktbeschreibung genannt. Stichwort Manipulationssicherheit.
Manipulationssicherheit löst man mit sign. Hashes, da brauchts keine BLOBs
So wird es bei journald ja auch gemacht.
journalctl empfinde ich persönlich als wesentlich flexibler.Man kann vim als Pager (vimpager) nutzen. journalctl kann auch in klassischer syslog-Formatierung ausgeben, damit sollte dann sogar das Syntax-Highlighting funktionieren.Was du suchst ist journalctl -b0. -b1 ist der erste Boot. -b -1 der vorherige.
journalctl kann sehr sehr nützlich sein, da es direkt filtern kann, z.B. auch per Unit, Programm o.ä.
Also das was man (teilweise sehr umständlich) mittels grep machte.
Das Grundproblem ist weniger journald oder dessen binären Log-Dateien, sondern die Gewohnheit des Benutzers.
Die IT-Historie ist gespickt mit solchen Geschichten. Alles was neu ist, wird erst einmal mit den haarsträubendsten Argumenten abgelehnt (Ich nehm mich da persönlich nicht aus). ITler sind mitunter die konservativsten Menschen die es gibt.
Ja, da ist teilweise sehr wenig Anpassungswillen da.
Zugegeben, am Anfang wirkt das schon etwas ungewohnt, die Logs mit journalctl auszugeben, allerdings habe ich das inzwischen wirkllich zu schätzen gelernt.
Ich nutze z.B. sehr häufig so etwas wie:
journalctl --user -b0 /usr/bin/irgendeinprogramm
Damit erhalte ich die für mich relevanten Daten, z.B. weil irgendwas gerade ein Problem hat, ohne groß vorher Zeit investieren zu müssen.
Bei syslog hatte ich teilweise 2 Tage damit verbracht, verschiedene Dienste in verschiedene Dateien umzuleiten, damit ich schneller an die relevanten Infos komme und war trotzdem noch lange nicht zufrieden mit dem Ergebnis. Jetzt muss ich keine Vorbereitungen mehr treffen und erhalte trotzdem besser Informationen.
Dennoch ist journald/journalctl noch nicht komplett ausgereift, es fehlt hier und da noch an Funktionalität (wie z.B. bei besagten core dumps).
Zudem kommt der Umstand, dass sich die Verantwortung und Anforderungen an alte IT'ler auch ändert. Manche sind vom Admin auch in leitende apositionen versetzt worden und befassen sich nun mit anderen Aufgaben. Da hat man nicht immer Zeit fürs Neulernen der Tools. Man hat mit seinen Kernaufgaben u.U. bereits genug Neuland betreten.
Wenn man keine Zeit hat, dann sollte man keine IT System betreuen. Da liegt das Problem eindeutig außerhalb der IT.
Steht doch da!
Man darf aber, auch wenn man wenig Zeit har, ein Linux System benutzen.
Was den nun, Admin oder Benutzer? Entscheide Dich mal!
Das heißt also, auf Grund der Tatsache, dass manche Menschen keine Zeit oder Motivation haben sich in etwas einzuarbeiten, darf es keine Veränderung mehr geben?
Naja...
Abgesehen davon kostet es gar nicht so viel Zeit sich in systemd einzuarbeiten. Es ist wohl doch eher eine Frage der Motivation.
Die kann einem aber selbstverständlich niemand vorschreiben, das ist klar.
Versuche es mal ohne die Augen eines IT Menschen zu sehen. Es soll Menschen geben, die machen den ganzen Tag auch was anderes.
Was meinst du, warum Bei MS das Win 8 ziemlich extrem verrissen wurde? Da dachte so ein Heini, man müsste bewährte Konzepte grundlegend erneuern. Warum ist Gnome 3 im Nirvana verschwunden (bildlich gesprochen)? Weil da auch so ein Heini meinte, bewährtes grundlegend ändern zu müssen.
Änderungen müssen kommuniziert und iterativ eingeführt werden.
Aber hier geht es um Hintergrundtätigkeiten und nicht um grafische Oberflächen. Was im Hintergrund passiert ist dem "normalen" Anwender herzlich egal (solange es läuft).
Du hörst auch selten (eigentlich fast nie) Beschwerden von "normalen" Anwendern das Windows alleine jetzt 10 bis 30 Gb friesst. Nur über die Oberfläche wird gemotzt.
lustig wie sich leute über binäre datei aufregen obwohl sie selber immer ein programm nutzen müssen um klartext auslesen zu können. bleibt im jahr 1980 aber lasst bitte die menschen inruhe die verbessern wollen. danke.