Hallo Forum
Ich suche eine Möglichkeit, wie ich über den Journal (ext3 / ext4) die letzten Änderungen am Dateisystem (z.B. Neu erstellte Dateien, veränderte Dateien, gelöschte Dateien, usw.) auslesen kann.
inotify habe ich bereits entdeckt, und es funktioniert auch super, jedoch muss ich doch dazu so etwas wie ein Daemon laufen lassen, der mir ständig die Filesystem-Events abgreift ... und wenn dieser Daemon mal nicht läuft, gehen die Events "flöten" ... mit dem Journal hätte ich dieses Problem nicht.
Mit ext3grep --journal /dev/sda1 bekomme ich bereits heraus, von wann der letzte Journal-Eintrag ist (The oldest inode block that is still in the journal, appears to be from ...).
Aber wie bekomme ich die Einträge in ähnlicher Form wie bei inotify ... ?
Gruss & Danke
Lousek
[gelöst]ext3 / ext4 journal auslesen?
[gelöst]ext3 / ext4 journal auslesen?
Zuletzt geändert von Lousek am 10.01.2011 18:16:28, insgesamt 1-mal geändert.
Re: ext3 / ext4 journal auslesen?
inotify kenne ich nicht, aber was bitte willst du aus dem Journal auslesen?
wenn du sowas suchst, c_time für alle Änderungen(außer löschen) ; d_time für Löschungen; und wenn vorhanden bei ext4 cr_time für das Neuanlegen von Dateien dann schau mal hier vorbei. Kann einiges mehr als ext3grep unter anderem auch ext4 das in ext3grep gar nicht funktioniert. Ist dafür aber etwas komplizierter in der Anwendung, man sollte sich schon ein bischen einlesen bevor man die Welt verstehen will. Sind auch Möglichkeiten eingebaut alle Veränderungen von einzelnen Verzeichnisen oder Dateien soweit die Daten dazu noch im Journal enthalten sind, zeitlich über den Inodeprintout zu verfolgen. Ebenso die Möglichkeit Journalaktivitäten auf bestimmte Daten- oder Inodeblöcke zu lokalisieren, bei Inode auch Zeitlich genau. Das Programm ist zwar nicht für diesen Zweck konzipiert hat aber eine Menge Möglichkeiten forensische Untersuchungen bei ext3 und ext4 vorzunehmen. Allerdings hierbei sollte das Filesystem umountet sein, bzw du musst mit einer Kopie des Journals arbeiten, da das Auslesen des Journals eines readwrite gemounteten Filesystems Cacheeffekte bewirkt, welche bei erneutem Auslesens der Journaldaten zu falschen Ergebnissen führen. siehe Problem hier Ich vermute andere Programme werden an dieser Stelle das selbe Problem bekommen, beim erneuten auslesen mit debugfs tritten solche Datenverfälschungen genauso auch auf.
robi1
Das ist nicht ganz unmöglich aber doch ehr ungewöhnlich. Normalerweise ließt man das aus den Inode des Filesystems und nicht aus dem Journal. ZB.(z.B. Neu erstellte Dateien, veränderte Dateien, gelöschte Dateien, usw.)
Code: Alles auswählen
ROBI@LINUX:/tmp/test1 # ext4magic testfile.iso -H -a 1272329366 -b 1272329672
Filesystem in use: testfile.iso
|-----------c_time Histogram----------------- after -------------------- Tue Apr 27 02:49:26 2010
1272329396 : 0 | | Tue Apr 27 02:49:56 2010
1272329426 : 5 |************************* | Tue Apr 27 02:50:26 2010
1272329456 : 0 | | Tue Apr 27 02:50:56 2010
1272329486 : 5 |************************* | Tue Apr 27 02:51:26 2010
1272329516 : 0 | | Tue Apr 27 02:51:56 2010
1272329546 : 0 | | Tue Apr 27 02:52:26 2010
1272329576 : 0 | | Tue Apr 27 02:52:56 2010
1272329606 : 1 |***** | Tue Apr 27 02:53:26 2010
1272329636 : 0 | | Tue Apr 27 02:53:56 2010
1272329666 : 0 | | Tue Apr 27 02:54:26 2010
|-----------d_time Histogram----------------- after -------------------- Tue Apr 27 02:49:26 2010
1272329396 : 0 | | Tue Apr 27 02:49:56 2010
1272329426 : 0 | | Tue Apr 27 02:50:26 2010
1272329456 : 0 | | Tue Apr 27 02:50:56 2010
1272329486 : 0 | | Tue Apr 27 02:51:26 2010
1272329516 : 0 | | Tue Apr 27 02:51:56 2010
1272329546 : 7 |**** | Tue Apr 27 02:52:26 2010
1272329576 : 3 |** | Tue Apr 27 02:52:56 2010
1272329606 : 93 |**************************************************| Tue Apr 27 02:53:26 2010
1272329636 : 0 | | Tue Apr 27 02:53:56 2010
1272329666 : 0 | | Tue Apr 27 02:54:26 2010
|-----------cr_time Histogram----------------- after -------------------- Tue Apr 27 02:49:26 2010
1272329396 : 0 | | Tue Apr 27 02:49:56 2010
1272329426 : 25 |***************** | Tue Apr 27 02:50:26 2010
1272329456 : 0 | | Tue Apr 27 02:50:56 2010
1272329486 : 75 |**************************************************| Tue Apr 27 02:51:26 2010
1272329516 : 7 |***** | Tue Apr 27 02:51:56 2010
1272329546 : 3 |** | Tue Apr 27 02:52:26 2010
1272329576 : 3 |** | Tue Apr 27 02:52:56 2010
1272329606 : 0 | | Tue Apr 27 02:53:26 2010
1272329636 : 0 | | Tue Apr 27 02:53:56 2010
1272329666 : 0 | | Tue Apr 27 02:54:26 2010
wenn du sowas suchst, c_time für alle Änderungen(außer löschen) ; d_time für Löschungen; und wenn vorhanden bei ext4 cr_time für das Neuanlegen von Dateien dann schau mal hier vorbei. Kann einiges mehr als ext3grep unter anderem auch ext4 das in ext3grep gar nicht funktioniert. Ist dafür aber etwas komplizierter in der Anwendung, man sollte sich schon ein bischen einlesen bevor man die Welt verstehen will. Sind auch Möglichkeiten eingebaut alle Veränderungen von einzelnen Verzeichnisen oder Dateien soweit die Daten dazu noch im Journal enthalten sind, zeitlich über den Inodeprintout zu verfolgen. Ebenso die Möglichkeit Journalaktivitäten auf bestimmte Daten- oder Inodeblöcke zu lokalisieren, bei Inode auch Zeitlich genau. Das Programm ist zwar nicht für diesen Zweck konzipiert hat aber eine Menge Möglichkeiten forensische Untersuchungen bei ext3 und ext4 vorzunehmen. Allerdings hierbei sollte das Filesystem umountet sein, bzw du musst mit einer Kopie des Journals arbeiten, da das Auslesen des Journals eines readwrite gemounteten Filesystems Cacheeffekte bewirkt, welche bei erneutem Auslesens der Journaldaten zu falschen Ergebnissen führen. siehe Problem hier Ich vermute andere Programme werden an dieser Stelle das selbe Problem bekommen, beim erneuten auslesen mit debugfs tritten solche Datenverfälschungen genauso auch auf.
robi1
Re: ext3 / ext4 journal auslesen?
Hallo robi1
Das mit den File-Attributen ist nicht ganz dass was ich will
Wenn ich es richtig verstanden habe: inotify ist seit dem Kernel 2.6.12 dabei. mit inotfiy kann man Filesystem-Events "abfangen" ... z.B. MOVE, DELETE, OPEN, CLOSED, CREATED, MODIFIED, ...
Ich liebäugle gerade damit, eine DFSR-ähnliche Lösung zu programmieren ... tönt im ersten Moment vieleicht etwas extrem, aber wenn man sich etwas damit auseinander gesetzt hat, ist es gar nicht so kompliziert.
Da es kein Sinn macht, alle z.B. 5 Minuten das ganze Filesystem auf Änderungen zu durchsuchen (also die file-attribute zu verwenden), wäre inotify eine Lösung. Auch bei vielen tausend Dateien bekommt man innert Sekunden Ändernungen am Filesystem / Ordner angezeigt, da dies direkt über den Kernel läuft.
Jetzt ist einfach das Problem: Wenn ich ein Daemon habe, der die ganze Zeit die Filesystem-Events "abfängt" (z.B. incrond oder iwatch), und dieser dann auch nur für kurze Zeit (sagen wir eine Minute oder ein paar Sekunden) weg ist (z.B. neustart), dann bekomme ich Änderungen an den Dateien nicht mit.
Eigentlich würde es schon reichen, wenn ich das File oder den Ordner, der sich verändert hat, aus dem Journal auslesen kann. Falls man den Daemon, der den Journal überwacht, neu starten müsste, wäre dies nicht tragisch ... solange der Journal noch bis VOR das herunterfahren des Daemons reicht. Danach müsste logischerweise alle Dateien auf Änderungen überprüft werden.
Aber da im Journal relativ viel Platz hat, und man ein extrem schreiblastiges Filesystem eh nicht auf diesem Weg replizieren würde, wäre der Journal genau das richtige.
Edit: Zuerst ganz lesen wäre etwas ... aber dennoch bringt mich das nicht wirklich weiter ...
Gruss
Lousek
Das mit den File-Attributen ist nicht ganz dass was ich will
Wenn ich es richtig verstanden habe: inotify ist seit dem Kernel 2.6.12 dabei. mit inotfiy kann man Filesystem-Events "abfangen" ... z.B. MOVE, DELETE, OPEN, CLOSED, CREATED, MODIFIED, ...
Ich liebäugle gerade damit, eine DFSR-ähnliche Lösung zu programmieren ... tönt im ersten Moment vieleicht etwas extrem, aber wenn man sich etwas damit auseinander gesetzt hat, ist es gar nicht so kompliziert.
Da es kein Sinn macht, alle z.B. 5 Minuten das ganze Filesystem auf Änderungen zu durchsuchen (also die file-attribute zu verwenden), wäre inotify eine Lösung. Auch bei vielen tausend Dateien bekommt man innert Sekunden Ändernungen am Filesystem / Ordner angezeigt, da dies direkt über den Kernel läuft.
Jetzt ist einfach das Problem: Wenn ich ein Daemon habe, der die ganze Zeit die Filesystem-Events "abfängt" (z.B. incrond oder iwatch), und dieser dann auch nur für kurze Zeit (sagen wir eine Minute oder ein paar Sekunden) weg ist (z.B. neustart), dann bekomme ich Änderungen an den Dateien nicht mit.
Eigentlich würde es schon reichen, wenn ich das File oder den Ordner, der sich verändert hat, aus dem Journal auslesen kann. Falls man den Daemon, der den Journal überwacht, neu starten müsste, wäre dies nicht tragisch ... solange der Journal noch bis VOR das herunterfahren des Daemons reicht. Danach müsste logischerweise alle Dateien auf Änderungen überprüft werden.
Aber da im Journal relativ viel Platz hat, und man ein extrem schreiblastiges Filesystem eh nicht auf diesem Weg replizieren würde, wäre der Journal genau das richtige.
Edit: Zuerst ganz lesen wäre etwas ... aber dennoch bringt mich das nicht wirklich weiter ...
Gruss
Lousek
Re: ext3 / ext4 journal auslesen?
Im Journal stehen Filesystemblockkopien,
Selbst wenn du zeitlich eingegrenzt anschauen würdest welche Blöcke in einer gewissen Zeit ins Journal geschrieben worden sind, hast du nur erst einmal die Blockkopien von den Inodeblöcken. Die Inodeblöcke sind relativ leicht von den anderen Blockkopien im Journal zu unterscheiden. Aber, In diesen befinden sich allerdings dann auch nicht nur eine Inode sondern zB 16 oder 32
Es ist auch ersteinmal nicht klar warum diese Kopie jetzt geschrieben wurde, es hat sich eine oder mehrere Inode davon geändert aber welche und was genau? oder wurde nur eine Datei ausgelesen und wegen Änderung der atime diese Inodblockkopie angelegt. ? Auch sind hier Dateiverschiebungen nicht zu erkennen, da sich dabei die Inode der Dateien selbst nicht ändert, nur die Inode des Verzeichnisses selbst. Die wirklich relevanten Änderungen die du in diesem Fall brauchen würdest, würden ansonsten nur in den Blockkopien der Directorydatenblöcken zu finden sein, aber diese Änderungen in diesen Blöcken sind noch weitaus schwieriger zu ermitteln, da diese Blöcke noch seltener im Journal vorkommen, du also sehr oft keine ältere Kopie zum Vergleichen finden wirst.
Du müsstest Inodeblockkopie mit der letzten von diesem Filesystemblock davor vergleichen, um zu erkennen was sich wirklich verändert hat. Ob du eine vorherige Kopie dieses Blockes aber im Journal auch wirklich findest ist nicht wirklich sicher.
Die andere Richtung, diese Inodekopie gegen das orginal im Filesystem zu vergleichen funktioniert in diesem Fall nicht, da im Filesystem das genaue Orginal ist, von dem die Kopie im Journal steht. Also in diese Richtigung in diesem Moment kein Unterschied ermittelbar ist.
robi
Code: Alles auswählen
Found 24318 copy of Filesystemblock in Journal
FS-Block Journal Transact Time in sec Time of Transaction
528253 2 160836 1274608139 Sun May 23 11:48:59 2010
526364 3 160836 1274608142 Sun May 23 11:49:02 2010
528252 4 160836 1274608144 Sun May 23 11:49:04 2010
530214 5 160836 1274608139 Sun May 23 11:48:59 2010
528644 6 160836 1274608143 Sun May 23 11:49:03 2010
529252 7 160836 1274608139 Sun May 23 11:48:59 2010
528109 8 160836 1274608139 Sun May 23 11:48:59 2010
527224 9 160836 1274608139 Sun May 23 11:48:59 2010
531243 10 160836 1274608139 Sun May 23 11:48:59 2010Es ist auch ersteinmal nicht klar warum diese Kopie jetzt geschrieben wurde, es hat sich eine oder mehrere Inode davon geändert aber welche und was genau? oder wurde nur eine Datei ausgelesen und wegen Änderung der atime diese Inodblockkopie angelegt. ? Auch sind hier Dateiverschiebungen nicht zu erkennen, da sich dabei die Inode der Dateien selbst nicht ändert, nur die Inode des Verzeichnisses selbst. Die wirklich relevanten Änderungen die du in diesem Fall brauchen würdest, würden ansonsten nur in den Blockkopien der Directorydatenblöcken zu finden sein, aber diese Änderungen in diesen Blöcken sind noch weitaus schwieriger zu ermitteln, da diese Blöcke noch seltener im Journal vorkommen, du also sehr oft keine ältere Kopie zum Vergleichen finden wirst.
Du müsstest Inodeblockkopie mit der letzten von diesem Filesystemblock davor vergleichen, um zu erkennen was sich wirklich verändert hat. Ob du eine vorherige Kopie dieses Blockes aber im Journal auch wirklich findest ist nicht wirklich sicher.
Die andere Richtung, diese Inodekopie gegen das orginal im Filesystem zu vergleichen funktioniert in diesem Fall nicht, da im Filesystem das genaue Orginal ist, von dem die Kopie im Journal steht. Also in diese Richtigung in diesem Moment kein Unterschied ermittelbar ist.
robi
Re: ext3 / ext4 journal auslesen?
hallo robi
vielen dank für deine Antwort, jetzt ist mir einiges klarer!
Nebenbei: unter Windows wird der USN Journal benützt ... aber demfall geht dies wohl unter linux nicht auf diesem weg ...
dann werde ich doch wohl oder übel auf inotify zurückgreifen müssen (wobei inotify natürlich schon klasse ist). beim Start des daemons muss ich demfall halt das ganze filesystem auf Änderungen durchsuchen ...
nochmals vielen dank, ich glaube, damit wäre dieses Thema beendet
Gruss
lousek
vielen dank für deine Antwort, jetzt ist mir einiges klarer!
Nebenbei: unter Windows wird der USN Journal benützt ... aber demfall geht dies wohl unter linux nicht auf diesem weg ...
dann werde ich doch wohl oder übel auf inotify zurückgreifen müssen (wobei inotify natürlich schon klasse ist). beim Start des daemons muss ich demfall halt das ganze filesystem auf Änderungen durchsuchen ...
nochmals vielen dank, ich glaube, damit wäre dieses Thema beendet
Gruss
lousek