2009/12/11 Mark Burgess :
>
...
> Collecting patterns of data in a simple format is not a bad idea, in the way
> that you
> suggest, then this can be read into an array by cfengine. The key is to make
> the pattern
> itself into a piece of documented system knowledge, not simply use it as a
> sh
This is a technician's point of view. It is only useful to an organization if
it is
clearly documented. The part I was objecting to was the perl script that
generated this
thing, which was a step backwards from comprehensibility.
Collecting patterns of data in a simple format is not a bad idea,
2009/12/11 Mark Burgess
>
> Forgive me for pouring scorn on this idea, but it has absolutely no
> conceivable merit to
> use an inappropriately cryptic script to generate something that is supposed
> to be a piece
> of documentation about the system. This is nonsense.
>
Someone could argue that
Read, Cfengine Nova
Ed Brown wrote:
> Christopher Browne wrote:
>> - In reflecting on it, I think I'd like for some of the derived classes
>> to be derived out of data residing in external sources like LDAP/DBMS.
>
> Yes, a native ability to import, AND export, class information would be
> th
Forgive me for pouring scorn on this idea, but it has absolutely no conceivable
merit to
use an inappropriately cryptic script to generate something that is supposed to
be a piece
of documentation about the system. This is nonsense.
Erlend Leganger wrote:
> 2009/12/9
>> ...
>> It looks neater.
help-cfengine-boun...@cfengine.org wrote on 2009-12-10 12:09:57:
> Christopher Browne wrote:
> > - In reflecting on it, I think I'd like for some of the derived
classes
> > to be derived out of data residing in external sources like
LDAP/DBMS.
>
> Yes, a native ability to import, AND export,
Christopher Browne wrote:
> - In reflecting on it, I think I'd like for some of the derived classes
> to be derived out of data residing in external sources like LDAP/DBMS.
Yes, a native ability to import, AND export, class information would be
the bees knees...
Maybe it can already be found in the documentation(anyone have a link?),
but I'd be interested to see how else one might structure a "files:"
example like Neil offered for any three particular files. I'm not so
much interested in modularization, as in simplification. I'd like for a
service ad
nwat...@symcor.com writes:
> It's too early for me to tell what the best methods of code style will be
> for CF. Experience tells me that as policies grow, are deployed to more
> hosts and are managed by multiple people such separation of data and
> function are very helpful. If others have di
It's too early for me to tell what the best methods of code style will be
for CF. Experience tells me that as policies grow, are deployed to more
hosts and are managed by multiple people such separation of data and
function are very helpful. If others have different styles that they
think are
2009/12/9
>
> ...
> It looks neater. Suppose I want to add a file that has a different user,
> group or mode? In a perfect world we'd be able to define data structures
> in CF as we would in Perl and loop through them.
> ...
Which puts me on to an idea I definitely will use - keep all file
prom
I tend to agree with you, Christopher, that the first priority is to make clear
the
*intentions* behind the configuration -- human understanding (knowledge
management) is
often sacrificed for efficiency. We should strike a balance.
Neil's solution is technically elegant, but by separating data
Am Mittwoch, den 09.12.2009, 19:30 +0100 schrieb nwat...@symcor.com:
> I've made good progress is producing reusable policies with CF3. Consider
> a security policy that checks the permissions of a motley group of files.
> At first one might consider setting a a list or two and going from there.
Used to dabble, but I've been clean for years.
nwat...@symcor.com wrote:
> Mark Burgess wrote on 2009-12-09 15:25:34:
>> For me the main thing has been to provide mechanisms - take them or
>> leave them - for
>> expressing complex patterns in different ways. You pick the approach
>> that floats
Mark Burgess wrote on 2009-12-09 15:25:34:
>
> For me the main thing has been to provide mechanisms - take them or
> leave them - for
> expressing complex patterns in different ways. You pick the approach
> that floats your
> particular boat.
tmtowtdi (
http://en.wikipedia.org/wiki/There%27s_mo
Thanks for the feedback Ed. It is possible to try to further hide some
repeated information such as owners and modes. However this value still
has to be set somewhere. If it is not in the current location as I have
shown you'll have to look in multiple places to find all the information.
Let
I am currently in Paris where we were having the discussion last night about
"what is
simple?" when it comes to configuration. There are so many answers -- there is
always a
tradeoff between abstraction and reusability. Sometimes more lines are an aid
to seeing
what is going on, and sometimes y
Neil,
I've not made the leap yet from cf2, but so far your practical use cases
and examples and questions on cf3 have been more useful even than the
reference guide in starting to "get" cf3. Thank you.
Maybe it's just that this is only an example, but I have to wonder about
the value or econo
I've made good progress is producing reusable policies with CF3. Consider
a security policy that checks the permissions of a motley group of files.
At first one might consider setting a a list or two and going from there.
vars:
"644-mode" string => "0644";
"644-usr" string
19 matches
Mail list logo
