RE: Request

[Patrice GUERLAIS]

Hi,

If I well understand what you mean, you want some sort of an "heritage" : your 
"master" section defines defaults, whereas your
"local" section defines overloads. Am I right ?

If I'm right, here are the conclusions I drawn for my own purposes (partially 
as the result from a previous thread with Mark Lindsey
and Andrew Mayhew, thanks to them) :
- store in a directory (or a dir tree) the default files
- store in another directory (or dir tree) the "client" specific files
- write a cf conf file with something like :
<excerpt>
copy:
        ${origin}/${client}
                dest=${dest}
                server=...
                recurse=inf
                action=fix
                force=true

        ${origin}/DEFAULT
                dest=${dest}
                server=...
                recurse=inf
                action=fix
                type=mtime
</excerpt>

How it works :
- the first copy clause copies _always_ the specific files
- the second copy clause copies files only if they are newer. As the first 
clause already copied overloading files, the default ones
are older and can't be copied.

The bad thing with that organization is that it is limited to 2 levels : 1 for 
specific and 1 for default files. You can't define an
"object-looking file structure", that is :
- a default set
- a set for classes of clients (client with Sparc CPU, client with Intel CPU, 
...)
- within each class, define sub-classes (Sparc CPU with 1 CPU, Sparc CPU with 2 
CPUs, ...)
- within each sub-classes, define ...
I suggested the addition of a new option to the copy section, a "path" option 
defined for each copy clause :
<example>
copy:
        ${origin}
                dest=${dest}
                server=...
                path=<dir1>:<dir2>:<dir3>:...
                action=fix
                type=mtime
                ...
</example>
The result would then be the union of all the dir/file names found in the path, 
but the copy would be done in the order of the path.
Thus you can "heritate" by specifying the path from the more to the less 
specific : path=client:sub-class just one step
over:sub-class 2 steps over:...:default. But had no echo about that idea :-(

HIH
Patrice


> -----Message d'origine-----
> De : help-cfengine-admin@gnu.org [mailto:help-cfengine-admin@gnu.org]De
> la part de Michael Coffman
> Envoye : jeudi 21 septembre 2000 19:15
> A : help-cfengine@gnu.org
> Objet : Request
>
>
> I am new to using cfengine and have a question/request.
>
> I would like to use cfengine to manage files on a group of systems.
> I want to:
>
>  - maintain a central or master section
>  - Allow the addition of a local section, or single entries
>  - Allow local entries to override the master entries
>  - Eliminate duplicate entries
>
> >From what I know of cfengine, I am thinking of creating a kind of work
> directory where I would store both the local and master copies on each
> system.  I would maintain a check sum database for the local file.  If
> either file changes, I would update the copies in the work directory.
>
> I now need to write a script to assemble the files into the actual system
> config file.
>
> Is anyone doing anything similar to this?
> Would you be willing to share scripts/templates?
>
> Thanks.
>
> -MichaelC
> ------------------------------------------------------------------
> -- Life is lived forward but understood backward.
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine