Re: Suche Tool: Änderungen im Unterverzeichnis protokollieren

Autor: Raphael Becker <rabe_at_uugrn.org>
Datum: Sun, 19 Jul 2009 20:15:28 +0200
On Sun, Jul 19, 2009 at 02:06:05PM +0000, Christian Weisgerber wrote:
> Raphael Becker <rabe_at_uugrn.org> wrote:
> > ich bin auf der Suche nach einem Tool, mit dem ich einen
> > Vorher-Nachher-Diff auf einem Verzeichnisbaum anwenden kann.
> 
> mtree?

Das hab ich mal ausprobiert. 

Auf das aktuelle /usr/ports angewendet (ca 140k files) dauert das zwar
ne Weile, bis die sha256-Checksummen alle gezogen sind, das
resultierende mtree-File wird dabei ca 20MB groß.

---------------
NOW=$(date +%F_%X)
cd /usr/ports && mtree -c -K sha256digest > /tmp/mtree_usr_ports.${NOW}.before
[... Updates ...]
cd /usr/ports && mtree -c -K sha256digest > /tmp/mtree_usr_ports.${NOW}.after
mtree -f /tmp/mtree_usr_ports.${NOW}.before -f /tmp/mtree_usr_ports.${NOW}.after > /tmp/mtree_usr_ports.${NOW}.changed
---------------

Die Ausgabe von *.changed ist zwar strange, aber benutzbar:

     -f file
           Read the specification from file, instead of from the standard
           input.  
           If this option is specified twice, the two specifications are com-
           pared to each other rather than to the file hierarchy.  The speci-
           fications be sorted like output generated using -c.  The output
           format in this case is somewhat remniscent of comm(1), having "in
           first spec only", "in second spec only", and "different" columns,
           prefixed by zero, one and two TAB characters respectively.  Each
           entry in the "different" column occupies two lines, one from each
           specification.


Oder als Beispiel:

$ mtree -f before -f after

ergibt eine Ausgabe mit führenden Tabulatoren:

^File1
--> File1 wurde gelöscht

^\tFile1
--> File1 wurde angelegt
 
^\t\tFile1 
^\t\tFile1

--> File1 wurde verändert

> tripwire?

Schau ich mir noch an.


Mein Selbstbau-Ansatz zum Vergleich von Verzeichnissen ist folgender:

* Eisammeln aller Metadaten mit GNU-find
  - tabellarische Ausgabe mit Tabulator als Trennzeichen

gfind /usr/ports/ -printf "%i\t%n\t%y\t%U\t%G\t%m\t%s\t%k\t%p\t%l\t%h\t%f\t%d\t%CY-%Cm-%Cd %CT\t%TY-%Tm-%Td %TT\t\n" 

Das ergibt auf dem gleichen /usr/ports eine Datei mit rund 23MB plus
nochmal 11MB (ca 108k Zeilen) für die sha256-Summen im Format 
"checksumme_%p":

gfind /usr/ports/ -type f -exec sha256 -r {} +

Gleiche Checksummen bedeuten hier allerdings *nicht* notwendigerweise, 
dass es Hardlinks sind, also identische Inodes, sondern einfach Dateien 
gleichen Inhalts. Es gibt immerhin 1500 Checksummen, die in den Ports 
mehrfach ientisch vorkommen, im Wesentlichen pkg-{descr,plist} Dateien
und Patches, die in mehreren Generationen einer Software mitgezogen
werden.

Das Ganze muss man *irgendwie* sinnvoll aufteilen und in einer 
Datenbank versenken, d.h. verschiedene Tabellen mit Primärschlüsseln 
auf Inode, Dateiname und später auch auf Checksummen anlegen und darauf 
dann Abfragen formulieren.

In die inode-Tabelle passen alle Werte außer Datei- und
Verzeichnisnamen. 2 Dateinamen als Hardlink auf den gleichen inode haben
AFAIK immer den gleichen timestamp, die gleichen Attribute, die gleichen
Checksummen, uid/gid/permissions, ... 

Gruß
Raphael


-- 
Raphael Becker          <rabe@uugrn.org>          http://rabe.uugrn.org/
                                   https://blogs.uugrn.org/freebsdtipps/
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..


--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/

Empfangen am 19.07.2009

Dieses Archiv wurde generiert von hypermail 2.2.0 : 19.07.2009 CEST