CFEngine Help: Private decrypt failed = padding check failed
Forum: CFEngine Help Subject: Private decrypt failed = padding check failed Author: davidlee Link to topic: https://cfengine.com/forum/read.php?3,24303,24303#msg-24303 (Set of 15 machines, all RHEL 5.6, all cfengine community 3.1.4) >From time to time (every few days or so) the main cfengine server throws out >sets of three error messages: Dec 15 03:10:30 <1.3> srv-host cf-serverd[26325]: Private decrypt failed = padding check failed Dec 15 03:10:30 <1.3> srv-host community>[14994]: BAD: Unspecified server refusal (see verbose server output) Dec 15 03:10:30 <1.3> srv-host community>[14994]: !! Authentication dialogue with iii.jjj.kkk.lll failed (I've obfuscated the server name and IP number above.) This starts seemingly at random, continues for a few minutes, then goes away. Any ideas? Is this a known problem? Fixed in later releases? Although we have a fair amount of local detail in our cfengine configuration, the overall set-up (including the usual 5-minute crontab "cf-execd") are as per the RPM downloaded from the cfengine website. ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: Policy Servers
Forum: CFEngine Help Subject: Re: Policy Servers Author: lauwersw Link to topic: https://cfengine.com/forum/read.php?3,24302,24304#msg-24304 tjavo87 Wrote: > - Do we need to bootstrap to both policy servers? I wouldn't know why: bootstrapping is just making sure that you have some initial code to run with. That code should be identical, independent of the bootstrap server it comes from. So no. > - I created a variable that defines multiple > policy servers (slist) and used that during > secure_cp. Is this a correct approach? That can be one approach, but it won't loadbalance, it will try every server in that list in order until one answers. Here's an example on loadbalancing: https://cfengine.com/forum/read.php?3,22618,22640 > - If we have multiple policy servers, how to be > sure the client/servers have both keys? You can either distribute the keys upfront (outside of cfengine), or you have to use "trustkey", as explained in the docs http://cfengine.com/manuals/cf3-reference.html#Key-exchange . With trustkey => "true" the keys will be automatically exchanged upon first contact. So even if a client always communicated with server1, upon failure of server1 it can connect to server2, exchange keys and keep on working from server2. > - How to keep the policy servers in sync with each > other? I recommend to put all your cfengine files in source control and regularly update all policy servers from there. They should always have identical code that way. Theoretically you could also have a number of "slave" policy servers syncing from one "master" policy server, but that's definitely less robuts. ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: Policy Servers
Forum: CFEngine Help Subject: Re: Policy Servers Author: tjavo87 Link to topic: https://cfengine.com/forum/read.php?3,24302,24306#msg-24306 lauwersw Wrote: --- > tjavo87 Wrote: > > - Do we need to bootstrap to both policy > servers? > > I wouldn't know why: bootstrapping is just making > sure that you have some initial code to run with. > That code should be identical, independent of the > bootstrap server it comes from. So no. > Now the bootstrap process is clear. > > > - I created a variable that defines multiple > > policy servers (slist) and used that during > > secure_cp. Is this a correct approach? > > That can be one approach, but it won't > loadbalance, it will try every server in that list > in order until one answers. Here's an example on > loadbalancing: > https://cfengine.com/forum/read.php?3,22618,22640 > > > > - If we have multiple policy servers, how to be > > sure the client/servers have both keys? > > You can either distribute the keys upfront > (outside of cfengine), or you have to use > "trustkey", as explained in the docs > http://cfengine.com/manuals/cf3-reference.html#Key > -exchange . With trustkey => "true" the keys will > be automatically exchanged upon first contact. So > even if a client always communicated with server1, > upon failure of server1 it can connect to server2, > exchange keys and keep on working from server2. > That's clear. I've enabled the trustkey option in the cfengine_stdlib.cf under secure_cp. > > - How to keep the policy servers in sync with > each > > other? > > I recommend to put all your cfengine files in > source control and regularly update all policy > servers from there. They should always have > identical code that way. Theoretically you could > also have a number of "slave" policy servers > syncing from one "master" policy server, but > that's definitely less robuts. Thanx! ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
Re: Is this the idiom for if...else?
On Wed, 14 Dec 2011 15:50:13 + (GMT) Mark Dixon
wrote:
MD> OK, so this works because of rule 5 of agent normal ordering ("The
MD> order of promises within one of the above types follows their top-down
MD> ordering within the bundle itself") from the reference manual?
MD> http://cfengine.com/manuals/cf3-reference.html#Agent-normal-ordering
Yes, and if you look at the log files and source code you'll see how it
works in practice. Reading the source is not bad if you know C at all :)
Ted
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
On Wed, Dec 14, 2011 at 05:28:10AM -0500, Marco Marongiu wrote:
>Hi
>
>I can't be as specific as lauwersw. I've been a cfengine2 user for some
>time, but my experience with cfengine3 is still too small.
>
>1) So, on a general note, and resuming what I already said in other
>threads, simple file editing is sometimes too hard. E.g.: placing pieces
>of text in a very well defined position inside a file is too difficult,
>and template files are too feature-poor to be 100% feasible.
>
>For computers, it may not matter where a comment or a configuration
>directive is placed inside a file. But configuration files are also read
>by humans, and providing comments and directives in the places a human
>expects them to be _is_ important. Placeholders or pseudo-tags are not
>the solution: they are workarounds, and may make a file more difficult
>to read.
I'll 2nd this as well. It seems that the overall functionality of file
editing has gotten *worse* in CF3, relative to CF2. I realize that
there may be issues with convergence, but I think there is quite a bit
of room for improvement in the current implementation as well.
>2) Documentation as a whole is not easy to use. We have:
>
>* a bare-bones tutorial (too bare bones be really useful)
>* a complete reference (a bit less than 600 pages...)
>* a standard library reference (i.e.: the "Cfengine Open Promise Body
>Library" reference)
>* a best practices guide
>* a number of "Special Topics" guides (more than 30)
>
>Guess yourself how easy is to find the right path through all these
>documents. A reorganization is definitely needed, and a better, richer
>tutorial is, too.
I'll actually put in a *good* word for the the reference manual, in that
it *is* comprehensive. Overwhelming and hard to use as a learning tool
to be sure, but it is mostly complete. (Given the choice between a full
reference and a tutorial, I'll take the reference.)
That said, I think that a lot of the smaller examples for attributes
body attributes, functions and variables need to be a lot longer. This is
especially true for functions like canonify(), classify() and the like.
The entire block of ${mon.*} variables as well. The explation for all
of them reads something like:
"Observational measure collected every 2.5 minutes from cf-monitord,
description: %CPU utilzation 3."
Nor is there much explanation about different dev_*, value_* and av_*
variables, or how to use them, or what they actually mean.
(That said, if anyone is interested, I've tried posted this page to help
see what values are recorded:
http://cfengineers.org/wiki/index.php/Mon.*_context_variables)
>3) Maybe connected to the previous problem: the language itself is too
>complicated for beginners. It would be nice to have sort of a simplified
>language (cfScript?), and a compiler to translate it into cfengine3
>native policies.
I'm not sure that introducing an intermediate language is a good idea.
Now we have yet another language to learn, and haven't fixed any of the
fundamental syntax problems that already exist.
Of course, there are some pretty strange by oddities in the language,
which does not help matters.
Some places have constructs that "look like strings", but do not follow
the rules for string interpolation. Examples include defining variables
and classes, for example. It'd be awfully handy to do something like
this:
vars:
'list' slist => { 'foo', 'bar', 'baz' };
classes:
"Has_${list}" => isplain("/tmp/${list}");
Some intrinsic values are strings, others are not. I don't know how many times
I've been tripped up by the two errors in this snippet:
files:
"/some/file"
perms => "paf", # WRONG! should not be quoted
create => true; # WRONG! should be quoted
One is an intrinsic, and needs quotes. The other is a user-defined
body, and doesn't. That's backwards from what I would normally expect.
Integers, floats and strings are considered different data types, for no
obvious user-level reason. At a high level--the global infrastructure
systems administration, datacenter management level--these distinctions
are arbitrary and more than a little strange. If we were dealing with
low-level libraries, I'd have a different view of things, and indeed
the underlying C code should care a great deal about about it. But the
cfengine promise language should not.
List and arrays are granted "second class" status. Using them is
difficult, outside of trivial list iteration, and anything more than a
basic list or associative array is impossible to create. It is very
confusing when a list should be dealt with "as a list" or "iterated over
as individual items". This leads to *very* messy and unmaintainable
code.
The rigidity of bodies and bundles is incredibly frustrating, and
inflexible. Take 'classes =>' bodies, for example
(http://cfengine.com/manuals/cf3-re
Re: CFEngine Help: Thoughts about some cfengine design decisions?
This is not true. The file editing has been greatly simplified in appearance
but it now a lot *more* powerful in cf3. It is expressed more convergently
however so more consistent syntax, unlike 2.
If you need some tips help us to improve the special topics guide on editing by
suggesting examples we can give, and you might find a present in your stocking!
;-)
--
Sent from my Android phone with probably ridiculous and involuntary spelling
corrections
Jesse Becker wrote:
On Wed, Dec 14, 2011 at 05:28:10AM -0500, Marco Marongiu wrote:
>Hi
>
>I can't be as specific as lauwersw. I've been a cfengine2 user for some
>time, but my experience with cfengine3 is still too small.
>
>1) So, on a general note, and resuming what I already said in other
>threads, simple file editing is sometimes too hard. E.g.: placing pieces
>of text in a very well defined position inside a file is too difficult,
>and template files are too feature-poor to be 100% feasible.
>
>For computers, it may not matter where a comment or a configuration
>directive is placed inside a file. But configuration files are also read
>by humans, and providing comments and directives in the places a human
>expects them to be _is_ important. Placeholders or pseudo-tags are not
>the solution: they are workarounds, and may make a file more difficult
>to read.
I'll 2nd this as well. It seems that the overall functionality of file
editing has gotten *worse* in CF3, relative to CF2. I realize that
there may be issues with convergence, but I think there is quite a bit
of room for improvement in the current implementation as well.
>2) Documentation as a whole is not easy to use. We have:
>
>* a bare-bones tutorial (too bare bones be really useful)
>* a complete reference (a bit less than 600 pages...)
>* a standard library reference (i.e.: the "Cfengine Open Promise Body
>Library" reference)
>* a best practices guide
>* a number of "Special Topics" guides (more than 30)
>
>Guess yourself how easy is to find the right path through all these
>documents. A reorganization is definitely needed, and a better, richer
>tutorial is, too.
I'll actually put in a *good* word for the the reference manual, in that
it *is* comprehensive. Overwhelming and hard to use as a learning tool
to be sure, but it is mostly complete. (Given the choice between a full
reference and a tutorial, I'll take the reference.)
That said, I think that a lot of the smaller examples for attributes
body attributes, functions and variables need to be a lot longer. This is
especially true for functions like canonify(), classify() and the like.
The entire block of ${mon.*} variables as well. The explation for all
of them reads something like:
"Observational measure collected every 2.5 minutes from cf-monitord,
description: %CPU utilzation 3."
Nor is there much explanation about different dev_*, value_* and av_*
variables, or how to use them, or what they actually mean.
(That said, if anyone is interested, I've tried posted this page to help
see what values are recorded:
http://cfengineers.org/wiki/index.php/Mon.*_context_variables)
>3) Maybe connected to the previous problem: the language itself is too
>complicated for beginners. It would be nice to have sort of a simplified
>language (cfScript?), and a compiler to translate it into cfengine3
>native policies.
I'm not sure that introducing an intermediate language is a good idea.
Now we have yet another language to learn, and haven't fixed any of the
fundamental syntax problems that already exist.
Of course, there are some pretty strange by oddities in the language,
which does not help matters.
Some places have constructs that "look like strings", but do not follow
the rules for string interpolation. Examples include defining variables
and classes, for example. It'd be awfully handy to do something like
this:
vars:
'list' slist => { 'foo', 'bar', 'baz' };
classes:
"Has_${list}" => isplain("/tmp/${list}");
Some intrinsic values are strings, others are not. I don't know how many times
I've been tripped up by the two errors in this snippet:
files:
"/some/file"
perms => "paf", # WRONG! should not be quoted
create => true; # WRONG! should be quoted
One is an intrinsic, and needs quotes. The other is a user-defined
body, and doesn't. That's backwards from what I would normally expect.
Integers, floats and strings are considered different data types, for no
obvious user-level reason. At a high level--the global infrastructure
systems administration, datacenter management level--these distinctions
are arbitrary and more than a little strange. If we were dealing with
low-level libraries, I'd have a different view of things, and indeed
the underlying C code should care a great deal about about it. But the
cfengine promise language should not.
List and arrays are granted "second cl
Re: CFEngine Help: Thoughts about some cfengine design decisions?
On 14/12/2011 09:45, no-re...@cfengine.com wrote: > 3) Why is there a difference between global and local classes? In many cases > I would prefer to have my local classes to be global. On the other hand I > didn't see a case yet where I wanted a global class to be local. If you're > afraid of name collisions, you could always apply the "ifvarclass" trick and > put a variable in the class name. Now it's just confusing that ifvarclass > does generate global classes inside a "local" bundle, while regular class > defintions don't. > > I find the difference between local and global classes to be very useful. I tend to reuse class name a lot, between bundles (on bundle defines classes as the outcome of a promise, another one uses it), or use same name and know there won't be any name collision (the example given with the ifvarclass won't help, i reuse my variable name a lot, like "isfile_1" and file[1]) > 4) While talking about ifvarclass: this function is very useful, but it also > feels a bit unnatural and makes the code hard to read, as you have to look at > two places for class restrictions. It would be much nicer if you could just > put it all in front, like this: > > commands: >restart_$(service):: > > I realize it might violate the syntax rules because there are no quotes > around the class, but it would feel so much more natural... > That would ease some writing for sure, but is it really feasible ? Regards Nicolas ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
On 14/12/2011 15:25, Nick Anderson wrote:
> On 12/14/2011 07:58 AM, Ted Zlatanov wrote:
>> 1) allow passing body parameters as JSON, not just positional
>> parameters. Take the standard file permissions promise:
>>
>>"$(crond)/cfrun"
>>perms => mo("644","root");
>>
>> it instead becomes:
>>
>>"$(crond)/cfrun"
>>perms => "{ mode: 644, owners: ['root'] }";
> I think that is infinitely more readable.
>
>
I think I've just fallen in love with this notation
Nicolas CHARLES
Normation SAS - http://www.normation.com
87 rue de Turbigo - 75003 Paris
+33 (0)1 83 62 26 96 - +33 (0)6 14 63 25 18
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
On Thu, Dec 15, 2011 at 03:11:25PM -0500, Mark Burgess wrote:
>This is not true. The file editing has been greatly simplified in appearance
>but it now a lot *more* powerful in cf3. It is expressed more convergently
>however so more consistent syntax, unlike 2.
Oh, that I agree with--the syntax is certainly more consistent, and
that's a very good thing. But, and this is a personal view, I find it
harder to "edit files" in CF3 than I did in CF2. Of course, in both
cases, I try to avoid it as much as possible as it generally seems is
fraught with peril. :-/
>If you need some tips help us to improve the special topics guide on
>editing by suggesting examples we can give, and you might find a
>present in your stocking! ;-)
Well, that's a nice piece of bait to put on a hook...
I'd like to see a solid example of managing a well structured
configuration file that is *NOT* strictly line based. It's one thing to
append stuff to /etc/aliases as needed. It's another thing entirely to
add new blocks to httpd.conf. Or ensure that only
certain shares are defined in smb.conf (adding *and* removing as needed)
based on various class and variable definitions.
As a related issue, I will also still echo others' comments that templates
are entirely too difficult to manage. I've also said this before
myself: I believe that there should be an intrinsic "template()"
function that handles all of the internal workings needed for sane
templating. Ideally you should be able to do something like this (and
I'm expanding on the classes => abilities as well, since I'm
daydreaming...):
vars:
smb_shares slist => readstringlist(
'/data/smb_shares.lst',
'#',
"\n\n",
"1000",
"64000");
files:
"/etc/samba/smb.conf"
perms => mog('644','root','root'),
create => true,
template_from => template('/templates/smb.conf'),
classes => {
promise_repaired('bounce_smbd',
'bounce_nmbd'),
promise_kept(canonify("smbd.conf okay")),
repair_failed('smbd_conf_error'),
cancel_notkept(canonify("smbd.conf okay")),
};
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
> vars:
> smb_shares slist => readstringlist(
> '/data/smb_shares.lst', '#',
> "\n\n",
> "1000",
> "64000");
> files:
> "/etc/samba/smb.conf"
> perms => mog('644','root','root'),
> create => true,
> template_from => template('/templates/smb.conf'),
> classes => { promise_repaired('bounce_smbd', 'bounce_nmbd'),
> promise_kept(canonify("smbd.conf okay")),
> repair_failed('smbd_conf_error'),
> cancel_notkept(canonify("smbd.conf okay")), };
>
I don't understand where the smb shares comes into it, but any reason
why this doesn't work?
files:
"/etc/samba/smb.conf"
perms => mog('644','root','root'),
create => true,
edit_line => expand_template('/templates/smb.conf'),
...
If you imply that the file contains lists, then that brings up a few
issues about semantics that are unclear, but some solutions are given here:
http://cfengine.com/manuals/st-editing.html#File-templates
Lists inside template files are worth revisiting.
Non-line based editing was never supported in CFEngine 2 or 3 (yet) but
if your files are reasonably well behaved, you can approimate a context
free language like sgml as a regular one, e.g. if the tags are on
separate lines
Item 1
Item 2
You could use
body select_region MySection(x)
{
select_start => "<$(x)>";
select_end => "";
}
To edit only within the section. I should add some examples of sections
to the STG...
M
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
On Thu, Dec 15, 2011 at 03:46:40PM -0500, Mark Burgess wrote:
>
>> vars:
>> smb_shares slist => readstringlist(
>> '/data/smb_shares.lst', '#',
>> "\n\n",
>> "1000",
>> "64000");
>> files:
>> "/etc/samba/smb.conf"
>> perms => mog('644','root','root'),
>> create => true,
>> template_from => template('/templates/smb.conf'),
>> classes => { promise_repaired('bounce_smbd', 'bounce_nmbd'),
>> promise_kept(canonify("smbd.conf okay")),
>> repair_failed('smbd_conf_error'),
>> cancel_notkept(canonify("smbd.conf okay")), };
>>
>
>I don't understand where the smb shares comes into it, but any reason
>why this doesn't work?
I was using smb.conf as an example of a structured file that operates in
"blocks" instead of "lines" (such as /etc/aliases, or resolv.conf).
>
> files:
> "/etc/samba/smb.conf"
>perms => mog('644','root','root'),
> create => true,
> edit_line => expand_template('/templates/smb.conf'),
> ...
Because you still have to, as a separate step with additional complexity,
write a promise to fetch the template from the server before you can do
local expansion. Yes, I undestand that this is what must happen at a
low level, but who cares? If I'm managing $BIGNUM systems, anything I
can do to simplify the management process is a huge benefit.
Instead, for any file I want to template, I have to write twice as many
promises as I think should be nessacary, and deal with a "2nd tier" file
repository location (i.e. "/templates") as well. I thought the idea was
to make less work, not more?
>If you imply that the file contains lists, then that brings up a few
>issues about semantics that are unclear, but some solutions are given here:
>
>http://cfengine.com/manuals/st-editing.html#File-templates
>
>Lists inside template files are worth revisiting.
Indeed.
And permit nested lists and arrays as well.
With those three things: 1-step templates, list iteration in templates
and complex data structures, CFEngine would gain a tremendous amount of
power.
>Non-line based editing was never supported in CFEngine 2 or 3 (yet) but
>if your files are reasonably well behaved, you can approimate a context
>free language like sgml as a regular one, e.g. if the tags are on
>separate lines
In CF2, there was a concept of BeginGroup*, which I thought could be
nested. It was, admittedly, an impartive way of dealing with files, and
I understand that it doesn't fit well with a purely declaritive model.
>
>
> Item 1
> Item 2
>
>
>
>
>
>You could use
>
>body select_region MySection(x)
>
>{
>select_start => "<$(x)>";
>select_end => "";
>}
>
>To edit only within the section. I should add some examples of sections
>to the STG...
>
>
>M
>
>
>
>
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
As far as I see my example is a direct translation of yours? No additional
steps... What am I missing?
--
Sent from my Android phone with probably ridiculous and involuntary spelling
corrections
Jesse Becker wrote:
On Thu, Dec 15, 2011 at 03:46:40PM -0500, Mark Burgess wrote:
>
>> vars:
>> smb_shares slist => readstringlist(
>> '/data/smb_shares.lst', '#',
>> "\n\n",
>> "1000",
>> "64000");
>> files:
>> "/etc/samba/smb.conf"
>> perms => mog('644','root','root'),
>> create => true,
>> template_from => template('/templates/smb.conf'),
>> classes => { promise_repaired('bounce_smbd', 'bounce_nmbd'),
>> promise_kept(canonify("smbd.conf okay")),
>> repair_failed('smbd_conf_error'),
>> cancel_notkept(canonify("smbd.conf okay")), };
>>
>
>I don't understand where the smb shares comes into it, but any reason
>why this doesn't work?
I was using smb.conf as an example of a structured file that operates in
"blocks" instead of "lines" (such as /etc/aliases, or resolv.conf).
>
> files:
> "/etc/samba/smb.conf"
> perms => mog('644','root','root'),
> create => true,
> edit_line => expand_template('/templates/smb.conf'),
> ...
Because you still have to, as a separate step with additional complexity,
write a promise to fetch the template from the server before you can do
local expansion. Yes, I undestand that this is what must happen at a
low level, but who cares? If I'm managing $BIGNUM systems, anything I
can do to simplify the management process is a huge benefit.
Instead, for any file I want to template, I have to write twice as many
promises as I think should be nessacary, and deal with a "2nd tier" file
repository location (i.e. "/templates") as well. I thought the idea was
to make less work, not more?
>If you imply that the file contains lists, then that brings up a few
>issues about semantics that are unclear, but some solutions are given here:
>
>http://cfengine.com/manuals/st-editing.html#File-templates
>
>Lists inside template files are worth revisiting.
Indeed.
And permit nested lists and arrays as well.
With those three things: 1-step templates, list iteration in templates
and complex data structures, CFEngine would gain a tremendous amount of
power.
>Non-line based editing was never supported in CFEngine 2 or 3 (yet) but
>if your files are reasonably well behaved, you can approimate a context
>free language like sgml as a regular one, e.g. if the tags are on
>separate lines
In CF2, there was a concept of BeginGroup*, which I thought could be
nested. It was, admittedly, an impartive way of dealing with files, and
I understand that it doesn't fit well with a purely declaritive model.
>
>
> Item 1
> Item 2
>
>
>
>
>
>You could use
>
>body select_region MySection(x)
>
>{
>select_start => "<$(x)>";
>select_end => "";
>}
>
>To edit only within the section. I should add some examples of sections
>to the STG...
>
>
>M
>
>
>
>
--
Jesse Becker
NHGRI Linux support (Digicon Contractor)
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: Policy Servers
Forum: CFEngine Help Subject: Re: Policy Servers Author: n...@cmdln.org Link to topic: https://cfengine.com/forum/read.php?3,24302,24317#msg-24317 Does policy_server.dat support multiple entries? The generated bootstrap policy doesn't appear so ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
On 14 December 2011 09:45, wrote: > reports: > any:: > > This is not allowed, if you didn't know it yet. Still what everybody does > now is this: > > reports: > cfengine:: > I knew about the any:: restriction, but not the workaround - thanks! - Erlend ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
2011/12/14 Ted Zlatanov
>
> "$(crond)/cfrun"
> perms => "{ mode: 644, owners: ['root'] }";
>
A definitive +1 - as a Perl user, I've always missed this syntax shortcut.
It's compact and readable - I can't see any drawbacks with it.
- Erlend
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: Thoughts about some cfengine design decisions?
Please forget you ever saw this.
This might look superficially attractive to a programmer but it suffers from
many problems, not the least of which would be a major increase in the size and
complexity of the parser. This approach does not satisfy the criteria for good
knowledge management. It appeals only to programmers - and would allow
programmers to gratify themselves at the expense of communicating policy to
other stakeholders.
If there were ever a valid use case for sharing data as json, an intermediate
function interface would be a defensible approach. Embedding a sub-language
within cf3 would repeat the mistakes made in the cf2 which led to chaos and
feature creep.
The goal of cf3 core is to be small and stable. We are looking at other
mechanisms to simplify body templating.
--
Sent from my Android phone with probably ridiculous and involuntary spelling
corrections
Erlend Leganger wrote:
2011/12/14 Ted Zlatanov
"$(crond)/cfrun"
perms => "{ mode: 644, owners: ['root'] }";
A definitive +1 - as a Perl user, I've always missed this syntax shortcut. It's
compact and readable - I can't see any drawbacks with it.
- Erlend
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
