About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 11 Nov 2002 - 15:37:14 GMT


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


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 11 Nov 2002 - 16:56:08 GMT by hypermail 2.1.3