Re: Suche Tool: Aenderungen im Unterverzeichnis protokollieren

[Raphael Becker <rabe@xxxxxxxxx>]

On Sun, Jul 19, 2009 at 02:06:05PM +0000, Christian Weisgerber wrote:
> Raphael Becker <rabe@xxxxxxxxx> 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 gross.

---------------
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 fuehrenden Tabulatoren:

^File1
--> File1 wurde geloescht

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

--> File1 wurde veraendert

> 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) fuer 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 Primaerschluesseln 
auf Inode, Dateiname und spaeter auch auf Checksummen anlegen und darauf 
dann Abfragen formulieren.

In die inode-Tabelle passen alle Werte ausser 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, ... 

Gruss
Raphael


-- 
Raphael Becker          <rabe@xxxxxxxxx>          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/