On Mon, Nov 11, 2002 at 02:41:46PM +0100, Christian wrote:
> hi,
> i'm planning to write an new vunify-like tool which only relies on files
> properties and not on any package-database (i need that because i'm on
> debian .. so no rpm-database and i would prefer tripwire, aide or such to
> ensure consistency).

hmm, so a configuration file, or a log file which would
not be used for some time, will become a candidate for
unification? what if the file then gets used in a way
not suited for the IMMUTABLE-UNLINK approach?

> It will take some time since i still have enough space and ram on my
> vserver and so it has low-pri. Anyways i would like to hear comments and
> ideas about it and i would like to know if someone else started on
> something similar.
> 
> short overview:
> planned features
> 
> Operation modes:
> --unify                       unify's the file
> --split                       un-unify files
> 
> File Selection
> options:              unify when:
> --minsize size                at least 'size' (would --maxsize be usefull? .. i think
> not)
> --mtime-eq-ctime      ctime and mtime are identical (thus the file seems not be
> used for writing)
> --include regex               file selection, first match applies
> --exclude regex               file selection, first match applies
> --with-modes mask     permission bits which must be set
> --without-modes mask  permission bits which must not be set
> --setmod modes                set modes on unified files
> --clrmod modes                clear modes
> --with-attr attrs     file attributes which must be set
> --without-attr attr   file attributes which must not be set
> --owner uid's         numeric owner comma seperated list and hyphen
>                       seperated ranges are aceptable 
> --group       gid's           same for guid

why not incorporate find? why not use file lists?
I would prefer to have a list of to-be-unified files
maybe from a database (or rpm package info) ...

> Modifications when selected:
> --unify                       unify's the file (implies immutable_link)
> --split                       un-unify files
> --setmod modes                set modes on unified files
> --clrmod modes                clear modes
> --setattr attr                set attributes (mostly for the immutable_link or
> immutable_file flags)
> --clrattr attr                clear attributes
> --chown uid           change uid
> --chgrp gid           change gid
> 
> stupid example:
> Note - the order of the options will be relevant, this will enable a very
> minimal scripting ability
> "unify all bin dirs and ensure that all files in sbin's are owned by
> root:root"
> vunite --unify --minsize 512 -mtime-eq-ctime --include '.*/bin/.*' --chown
> 0 --chgrp 0 --include '.*/sbin/.*' --exclude '.*' /vservers

how do you plan to match (compare) the files?
- by path/contents
- by hash values (md5,etc)

because you might run in an O(n^2) issue ...

a linear approach could be generating a list of hash 
values (sum, md5sum, cksum, fsum) for each vertual 
server (including a reference) and then only comparing 
a to-be-unified server (list) with the reference ... 
should give O(n)

best,
Herbert

> Note this tool will be be usefull to unify servers with diffrent
> installations. i'm not (yet) intend to provide the infrastucture to keep
> many servers in sync with a reference server. The big Pro is that it
> unifies files based on their content, no matter in which dir they are.
> 
> cya Christian

Reply via email to