How easy/simple is cfengine?

[Mark Burgess]

Mikhail, one of our very brilliant developers, recently brought this 
talk to my attention. I just had time to look at this and it is very 
good. The talk is a most excellent discussion about making choices about 
easy versus simple in software. I recommend everyone to watch this and 
absorb its content.

It is very relevant to the discussion about making CFEngine 
easier/simpler, also vis a vis the choices made by Puppet/Chef versus 
CFEngine, etc etc - and I very much agree with the speaker's viewpoint. 
He does not provide any answers, but he poses important questions: the 
best kind of talk.

M

PS - Category theory (re: monads) is a form of mathematics, akin to set 
theory which is often used to explain anything by pulling the wool over 
people's eyes :)


___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Re: How easy/simple is cfengine?

[Natxo Asenjo]

On Sat, Dec 17, 2011 at 10:09 AM, Mark Burgess  wrote:
>
> Mikhail, one of our very brilliant developers, recently brought this
> talk to my attention. I just had time to look at this and it is very
> good. The talk is a most excellent discussion about making choices about
> easy versus simple in software. I recommend everyone to watch this and
> absorb its content.
>
> It is very relevant to the discussion about making CFEngine
> easier/simpler, also vis a vis the choices made by Puppet/Chef versus
> CFEngine, etc etc - and I very much agree with the speaker's viewpoint.
> He does not provide any answers, but he poses important questions: the
> best kind of talk.

hi,

which talk? Should there be a link in your message maybe?

-- 
groeten,
natxo
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Re: How easy/simple is cfengine?

[Mikhail Gusarov]

On 17.12.2011 11:57, Natxo Asenjo wrote:

> which talk? Should there be a link in your message maybe?

Here it is: http://www.infoq.com/presentations/Simple-Made-Easy

-- 
Mikhail Gusarov
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Re: How easy/simple is cfengine?

[Mark Burgess]

On 12/17/2011 01:08 PM, Mikhail Gusarov wrote:
> On 17.12.2011 11:57, Natxo Asenjo wrote:
>
>> which talk? Should there be a link in your message maybe?
> Here it is: http://www.infoq.com/presentations/Simple-Made-Easy
>

Thanks, I'm an idiot


___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

(addendum) How easy/simple is cfengine?

[Mark Burgess]

Addendum:

Sorry again for forgetting the link

 http://www.infoq.com/presentations/Simple-Made-Easy

It is worth commenting on two ways in which this talk applies to CFEngine, (in 
my personal view).

What I like about the talk is that it is not dogmatic, but poses questions. The 
speaker
says that certain things are good and bad, but does not claim that certain bad 
things are unavoidable, only
undesirable in a perfect world. CFEngine was needed because we don't live in a 
perfect world.

The talk is about how to limit it to what is "necessary and sufficient" and it 
applies to CFEngine at two levels:

1. the design and principles used by CFEngine for the problem of modelling 
configuration

e.g. CFEngine's language design seems to satisfy all the speaker's requirements 
for simplicity.
With reference to the inline body-syntax we discussed recently in the forum, I 
believe inline
syntax complects "what" with "how" by abusing syntax to mis-represent 
information (that puts it
strongly to underline the point).

The speaker suggests that one should *try* to avoid complexity, but CFEngine's 
job is to cope with / model
configuration complexity that others have created, i.e. (state) in a simple 
way. The disciplines it brings
encourages users to design simplicity, making things more declarative and 
non-intertwined (autonomous) and eliminating
imperative threads that complect what with how.

This complexity cannot necessarily be removed (there is a concept of necessary 
and sufficient complexity),
so we should not *oversimplify* a model.

We try to cope by imposing a simple discipline on the representation of state 
by disentangling independent issues
into promise types with body types, using a meta-model called "Promises", 
together with the concept of convergence
(persistence of state).

2. the internal design of CFEngine's implementation.

In writing CFEngine 3, the use of the promise model led to considerable 
disentanglement of code, compared to CFEngine 2,
though there might still be parts in the lower subsystems that could be 
further disentangled. It was necessary
to have a model to understand how to disentangle issues. In my view 
Puppet more deeply entangled the modelling

issues, sacrificing simple for easy.

It would be an interesting exercise for the development team to discuss 
how the principles the speaker expounds

apply to different parts of the code.

Personally, I would have liked to hear what the speaker had to say about 
global data/variables, since this is an area where
I noted the speaker's words (paraphrased): "Let data be data, don't hide 
it behind an API" with agreement. I read this as
an argument that global data/variables have a valid place in 
programming, as long as one copes with the inevitable

changes of state.

M

 Original Message 
Subject:How easy/simple is cfengine?
Date:   Sat, 17 Dec 2011 10:09:12 +0100
From:   Mark Burgess 
To: help-cfengine 



Mikhail, one of our very brilliant developers, recently brought this
talk to my attention. I just had time to look at this and it is very
good. The talk is a most excellent discussion about making choices about
easy versus simple in software. I recommend everyone to watch this and
absorb its content.

It is very relevant to the discussion about making CFEngine
easier/simpler, also vis a vis the choices made by Puppet/Chef versus
CFEngine, etc etc - and I very much agree with the speaker's viewpoint.
He does not provide any answers, but he poses important questions: the
best kind of talk.

M

PS - Category theory (re: monads) is a form of mathematics, akin to set
theory which is often used to explain anything by pulling the wool over
people's eyes :)



___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Re: (addendum) How easy/simple is cfengine?

[Mike Svoboda]

Hey Mark

The most difficult time I had with Cfengine was going from nothing, to having 
network transfers working.  Once I understood the concepts of failsafe.cf / 
promises.cf, things started to make sense and building upon that base 
configuration was pretty straightforward.   I know that you guys are shipping 
sample configs now with the source code.  What I would suggest, is to create a 
new "users guide" that went through step-by-step and line-by-line to describe 
what exactly was happening in those basic configs and why..

Then, since "sharing policies" is such a taboo subject for whatever reason (we 
all really need to work on sharing some of the best / coolest things we're 
using Cfengine for)  — actually include in that base configurations some 
policies to do stuff.  Not just the unit tests.  Lets show snmpd or ntpd being 
configured and daemons bounced. Show command execution.  Show file changes. 
 Show file changes raising a class, which is used to execute a command and then 
fire a report..   Show an example of how processes / linux services / packages 
/ template substitution works.We've all submitted some of our policies to 
this mailing list.  Lets collect a few of those examples and include them in 
this new users guide.  The RHEL6 services policy and /etc/sysctl.conf policies 
that I submitted I think would be a great introduction as long as they're 
explained.  Once you provide those policies, then spend a few pages explaining 
what design decisions happened behind them.

Once you are able to show policies and explain exactly whats happening in them, 
I think the learning curve of Cfengine will decrease.  You'll have less 
frustrated folks, and I think newbies will start doing things "the right way" 
by having Cfengine execute promises as designed.  I think a lot of people are 
using Cfengine as a distributed platform to launch shell scripts because they 
just don’t want to learn / deal with what Cfengine is.  If we show policies and 
explain the design decisions behind them, the n00bs are going to have a better 
experience.

I wish the recent Cfengine 3 book did this.  I begged them not to publish what 
they were putting out, because just throwing Cfengine policies / config is 
worthless unless there is some meaningful discussion behind what this stuff 
actually means.

Thanks
Mike

From: Mark Burgess mailto:m...@cfengine.com>>
Date: Sat, 17 Dec 2011 14:58:59 +0100
To: mailto:help-cfengine@cfengine.org>>
Cc: "develop...@cfengine.com" 
mailto:develop...@cfengine.com>>
Subject: (addendum) How easy/simple is cfengine?


Addendum:

Sorry again for forgetting the link

 http://www.infoq.com/presentations/Simple-Made-Easy

It is worth commenting on two ways in which this talk applies to CFEngine, (in 
my personal view).

What I like about the talk is that it is not dogmatic, but poses questions. The 
speaker
says that certain things are good and bad, but does not claim that certain bad 
things are unavoidable, only
undesirable in a perfect world. CFEngine was needed because we don't live in a 
perfect world.

The talk is about how to limit it to what is "necessary and sufficient" and it 
applies to CFEngine at two levels:

1. the design and principles used by CFEngine for the problem of modelling 
configuration

e.g. CFEngine's language design seems to satisfy all the speaker's requirements 
for simplicity.
With reference to the inline body-syntax we discussed recently in the forum, I 
believe inline
syntax complects "what" with "how" by abusing syntax to mis-represent 
information (that puts it
strongly to underline the point).

The speaker suggests that one should *try* to avoid complexity, but CFEngine's 
job is to cope with / model
configuration complexity that others have created, i.e. (state) in a simple 
way. The disciplines it brings
encourages users to design simplicity, making things more declarative and 
non-intertwined (autonomous) and eliminating
imperative threads that complect what with how.

This complexity cannot necessarily be removed (there is a concept of necessary 
and sufficient complexity),
so we should not *oversimplify* a model.

We try to cope by imposing a simple discipline on the representation of state 
by disentangling independent issues
into promise types with body types, using a meta-model called "Promises", 
together with the concept of convergence
(persistence of state).

2. the internal design of CFEngine's implementation.


In writing CFEngine 3, the use of the promise model led to considerable 
disentanglement of code, compared to CFEngine 2,
though there might still be parts in the lower subsystems that could be further 
disentangled. It was necessary
to have a model to understand how to disentangle issues. In my view Puppet more 
deeply entangled the modelling
issues, sacrificing simple for easy.

It would be an interesting exercise for the development team to discuss how the 
principles the speaker expounds
apply

Re: (addendum) How easy/simple is cfengine?

[Mark Burgess]

Sharing policies is not a taboo subject. It is just something that few 
people seem to be willing to do. We can only keep trying to offer the 
right forum.


M

On 12/17/2011 05:54 PM, Mike Svoboda wrote:

Hey Mark

The most difficult time I had with Cfengine was going from nothing, to 
having network transfers working.  Once I understood the concepts of 
failsafe.cf / promises.cf, things started to make sense and building 
upon that base configuration was pretty straightforward.   I know that 
you guys are shipping sample configs now with the source code.  What I 
would suggest, is to create a new "users guide" that went through 
step-by-step and line-by-line to describe what exactly was happening 
in those basic configs and why..


Then, since "sharing policies" is such a taboo subject for whatever 
reason (we all really need to work on sharing some of the best / 
coolest things we're using Cfengine for)  — actually include in that 
base configurations some policies to do stuff.  Not just the unit 
tests.  Lets show snmpd or ntpd being configured and daemons bounced. 
Show command execution.  Show file changes.  Show file changes 
raising a class, which is used to execute a command and then fire a 
report..   Show an example of how processes / linux services / 
packages / template substitution works.We've all submitted some of 
our policies to this mailing list.  Lets collect a few of those 
examples and include them in this new users guide.  The RHEL6 services 
policy and /etc/sysctl.conf policies that I submitted I think would be 
a great introduction as long as they're explained.  Once you provide 
those policies, then spend a few pages explaining what design 
decisions happened behind them.


Once you are able to show policies and explain exactly whats happening 
in them, I think the learning curve of Cfengine will decrease.  You'll 
have less frustrated folks, and I think newbies will start doing 
things "the right way" by having Cfengine execute promises as 
designed.  I think a lot of people are using Cfengine as a distributed 
platform to launch shell scripts because they just don’t want to learn 
/ deal with what Cfengine is.  If we show policies and explain the 
design decisions behind them, the n00bs are going to have a better 
experience.


I wish the recent Cfengine 3 book did this.  I begged them not to 
publish what they were putting out, because just throwing Cfengine 
policies / config is worthless unless there is some meaningful 
discussion behind what this stuff actually means.


Thanks
Mike

From: Mark Burgess mailto:m...@cfengine.com>>
Date: Sat, 17 Dec 2011 14:58:59 +0100
To: mailto:help-cfengine@cfengine.org>>
Cc: "develop...@cfengine.com " 
mailto:develop...@cfengine.com>>

Subject: (addendum) How easy/simple is cfengine?

Addendum:

Sorry again for forgetting the link

  http://www.infoq.com/presentations/Simple-Made-Easy

It is worth commenting on two ways in which this talk applies to CFEngine, (in 
my personal view).

What I like about the talk is that it is not dogmatic, but poses questions. The 
speaker
says that certain things are good and bad, but does not claim that certain bad 
things are unavoidable, only
undesirable in a perfect world. CFEngine was needed because we don't live in a 
perfect world.

The talk is about how to limit it to what is "necessary and sufficient" and it 
applies to CFEngine at two levels:

1. the design and principles used by CFEngine for the problem of modelling 
configuration

e.g. CFEngine's language design seems to satisfy all the speaker's requirements 
for simplicity.
With reference to the inline body-syntax we discussed recently in the forum, I 
believe inline
syntax complects "what" with "how" by abusing syntax to mis-represent 
information (that puts it
strongly to underline the point).

The speaker suggests that one should *try* to avoid complexity, but CFEngine's 
job is to cope with / model
configuration complexity that others have created, i.e. (state) in a simple 
way. The disciplines it brings
encourages users to design simplicity, making things more declarative and 
non-intertwined (autonomous) and eliminating
imperative threads that complect what with how.

This complexity cannot necessarily be removed (there is a concept of necessary 
and sufficient complexity),
so we should not *oversimplify* a model.

We try to cope by imposing a simple discipline on the representation of state 
by disentangling independent issues
into promise types with body types, using a meta-model called "Promises", 
together with the concept of convergence
(persistence of state).

2. the internal design of CFEngine's implementation.
In writing CFEngine 3, the use of the promise model led to 
considerable disentanglement of code, compared to CFEngine 2,
though there might still be parts in the lower subsystems that could 
be further disentangled. It was necessary
to have a model to understand how to disentangle iss

Re: (addendum) How easy/simple is cfengine?

[Jesse Becker]

I agree.  I don't think that people object to it--in fact there have
been quite a few people who have posted very detailed examples to the
list (or posted links to websites that have them).  The issue (IMO) is
one of security.  By it's nature, posting production policies will expose
information about a live enironment, and this could be of value to an
attacker.  Consider that if, for example, you use CF3 to manage
/etc/password directly, and your have password hashes in your .cf files.
Posting that file to the mailing list is probably a bad idea...

The community also used to have cfwiki.org as a place to post snippets,
and it was quite active for some time.  However, it fell victem to
spambots and has been taken offline.  In an attempt to replace it, I've
created cfengineers.org (also a wiki), and I'm quite happy for people to
post snippets and full-blow examples.

But perhaps we need something more like pastebin.com?


On Sat, Dec 17, 2011 at 12:19:59PM -0500, Mark Burgess wrote:
>
>Sharing policies is not a taboo subject. It is just something that few people 
>seem to be willing to do. We can only keep trying to offer the right forum.
>
>M
>
>On 12/17/2011 05:54 PM, Mike Svoboda wrote:
>Hey Mark
>
>The most difficult time I had with Cfengine was going from nothing, to having 
>network transfers working.  Once I understood the concepts of failsafe.cf / 
>promises.cf, things started to make sense and building upon that base 
>configuration was pretty straightforward.   I know that you guys are shipping 
>sample configs now with the source code.  What I would suggest, is to create a 
>new "users guide" that went through step-by-step and line-by-line to describe 
>what exactly was happening in those basic configs and why..
>
>Then, since "sharing policies" is such a taboo subject for whatever reason (we 
>all really need to work on sharing some of the best / coolest things we're 
>using Cfengine for)  — actually include in that base configurations some 
>policies to do stuff.  Not just the unit tests.  Lets show snmpd or ntpd being 
>configured and daemons bounced. Show command execution.  Show file 
>changes.  Show file changes raising a class, which is used to execute a 
>command and then fire a report..   Show an example of how processes / linux 
>services / packages / template substitution works.We've all submitted some 
>of our policies to this mailing list.  Lets collect a few of those examples 
>and include them in this new users guide.  The RHEL6 services policy and 
>/etc/sysctl.conf policies that I submitted I think would be a great 
>introduction as long as they're explained.  Once you provide those policies, 
>then spend a few pages explaining what design decisions happened behind them.
>
>Once you are able to show policies and explain exactly whats happening in 
>them, I think the learning curve of Cfengine will decrease.  You'll have less 
>frustrated folks, and I think newbies will start doing things "the right way" 
>by having Cfengine execute promises as designed.  I think a lot of people are 
>using Cfengine as a distributed platform to launch shell scripts because they 
>just don’t want to learn / deal with what Cfengine is.  If we show policies 
>and explain the design decisions behind them, the n00bs are going to have a 
>better experience.
>
>I wish the recent Cfengine 3 book did this.  I begged them not to publish what 
>they were putting out, because just throwing Cfengine policies / config is 
>worthless unless there is some meaningful discussion behind what this stuff 
>actually means.
>
>Thanks
>Mike
>
>From: Mark Burgess mailto:m...@cfengine.com>>
>Date: Sat, 17 Dec 2011 14:58:59 +0100
>To: mailto:help-cfengine@cfengine.org>>
>Cc: "develop...@cfengine.com" 
>mailto:develop...@cfengine.com>>
>Subject: (addendum) How easy/simple is cfengine?
>
>
>Addendum:
>
>Sorry again for forgetting the link
>
> http://www.infoq.com/presentations/Simple-Made-Easy
>
>It is worth commenting on two ways in which this talk applies to CFEngine, (in 
>my personal view).
>
>What I like about the talk is that it is not dogmatic, but poses questions. 
>The speaker
>says that certain things are good and bad, but does not claim that certain bad 
>things are unavoidable, only
>undesirable in a perfect world. CFEngine was needed because we don't live in a 
>perfect world.
>
>The talk is about how to limit it to what is "necessary and sufficient" and it 
>applies to CFEngine at two levels:
>
>1. the design and principles used by CFEngine for the problem of modelling 
>configuration
>
>e.g. CFEngine's language design seems to satisfy all the speaker's 
>requirements for simplicity.
>With reference to the inline body-syntax we discussed recently in the forum, I 
>believe inline
>syntax complects "what" with "how" by abusing syntax to mis-represent 
>information (that puts it
>strongly to underline the point).
>
>The speaker suggests that one should *try* to avoid complexi

Re: CFEngine Help: Thoughts about some cfengine design decisions?

[Jesse Becker]

On Fri, Dec 16, 2011 at 08:48:49AM -0500, Mark Burgess wrote:
>The syntax highlighting in the the docs now make this clear. Red words
>are CFEngine and blue words are user defined.

Would it be possible to publish the regexes uses for syntax
highlighting?  (Yes, I understand that it will change over time).

I've been working on one for the GeSHi syntax highlighter, which
admittedly has some oddities to it, and I'll try to make the styles
match.



>On 12/16/2011 12:27 PM, Erlend Leganger wrote:
>> And here is another thing I'd like to see: When learning cf3, I always
>> had problems figuring out which names were part of the language and
>> which were user defined. For example, my previous example read:
>> ...
>>depth_search =>  recurse,
>> ...
>> body depth_search recurse {
>> depth =>  "inf";
>> }
>>
>> I always had to think twice about terms like "recurse" - is it a part
>> of the language or not? This is easy to fix (and I have done this
>> across all my cf3 code) - just prefix every non-cf3 term with
>> something that is clearly not part of the language. In my case I use a
>> company specific string, for example "xyz_recurse".  Another approach
>> is use use for example "my_recurse" - also very clearly not part of
>> cf3.
>>
>> Here's an existing example from the tutorial[1]:
>> ...
>> perms =>  m("600"),
>> copy_from =>  remote_cp("$(master_location)","localhost"),
>> depth_search =>  recurse("inf"),
>> action =>  immediate;
>> ...
>>
>> For the beginner (and myself...), the following is easier to read:
>> ...
>>perms =>  my_mode("600"),
>>copy_from =>  my_remote_cp("$(master_location)","localhost"),
>>depth_search =>  my_recurse("inf"),
>>action =>  immediate;
>> ...
>> This would also be nice to have for the common body library, meaning
>> that each body or bundle for example had a copbl_ prefix:
>>
>> - body acl copbl_access_generic
>> - body acl copbl_ntfs
>> - body acl copbl_strict
>> - body action copbl_bg
>> - body action copbl_if_elapsed
>> - body action copbl_ifwin_bg
>> ...
>>
>> - Erlend
>>
>>
>> [1]: http://cfengine.com/manuals/cf3-tutorial.html#Remote-file-distribution
>> ___
>> Help-cfengine mailing list
>> Help-cfengine@cfengine.org
>> https://cfengine.org/mailman/listinfo/help-cfengine
>
>___
>Help-cfengine mailing list
>Help-cfengine@cfengine.org
>https://cfengine.org/mailman/listinfo/help-cfengine

-- 
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: Re: CFEngine Help: Thoughts about some cfengine design decisions?

[Jesse Becker]

On Fri, Dec 16, 2011 at 09:34:12AM -0500, no-re...@cfengine.com wrote:
>This is an excellent discussion.  

I concur. 

>Class scope should be clear and defined.  I don't like the idea of loosening 
>this.  It reminds me of the looseness of PHP and the breaches it caused.  
>Don't go for the quick and easy fix.

You mean common vs bundle scope here?

Ditto with variables, I'd suggest, although this has been discussed
elsewhere.


>With regards to anonymous subroutines, or inline body parts if you prefer. 
>Both sides have a point but, I agree with Mark.  The suggested changes look 
>nice from a programmer's point of view.  However, I don't like treating 
>Cfengine syntax as a programming language.  I see many examples of that and 
>the results are mostly unreadable.  Add in line body parts and we'll be back 
>to the very long promises we hand in Cfengine 2.  When we first start we 
>usually view the body parts with apathy.  They seem tedious and unnecessary.  
>However, once we have a good library of body parts under our belt we usually 
>forget about them.  In exchange promises are short and easy to read.

I should clarify that I do *not* think that long inlined promises are a
good idea.  Mark's example of a promise whith a long list of ignore=*
statesments is a good example.  I understand, and like, having a rigid
"API" for using bodies in various places.  My main issue is that you
have to make full duplication of various bodies to make what I think
are minor changes.  For example, if I want to assert N classes, that
requires almost full duplication of a body to define N+1 classes, which
is different from N-1, N+2, etc...

In my experience, any time you have to start doing things like "thing1" and
"thing2", you're doing it wrong.  It's one thing to have a good library
of body parts.  It's quite another to have a large library of bodies
that are fundamentally similar to each other because they are all minor
variations on each other.

>"Let us change our traditional attitude to the construction of programs. 
>Instead of imagining that our main task is to instruct a computer what to do, 
>let us concentrate rather on explaining to human beings what we want a 
>computer to do. " -- Knuth.

So why not, to pick a specific example, allow for more flexible, but
*unambiguous* and *consistant* language constructs?  If the point is
clarity, duplicating code isn't a solution, and I've seen a number of
examples of people jumping thorugh syntaxtic hoops to accomplish
something that could be much simpler (and still "clean/pure/etc").


>Which brings me to data structures.  I agree that the current batch leaves a 
>bit to be desired.  I avoid using more than a list because I find them so 
>difficult to follow.  I'm all for improving them for better function and 
>readability.
>
>In template file promises I would like to see lists other data structures work 
>with them.  I do not agree that the required two promises is too much to bear. 
> Yes, you have to cache the template file.  I suggest caching all files anyway 
>in order to survive communication loss with the policy host. The alternative 
>is a files promise for every iteration of the promiser file.  At that price 
>the current template file method is a good bargain!

This is all good, but why does it need to be broken up?  You're
templating.  Make caching the intermediate file automatic.  If you
really want to maintain twice the promises, that's still certainly possible.

>Which brings me to efficiency.  When you start to work with very large 
>policies Cfengine 3 does noticeably slow down.  The slow down is not a show 
>stopper but, for a C program we know this should not happen.  I'd like to see 
>a major effort on the part of Cfengine developers towards large scale 
>performance tests to fix these issues.

Better timestamps in the logs would allow for better profiling.  Of
course, profiling the code would do much the same. ;-)

-- 
Jesse Becker
NHGRI Linux support (Digicon Contractor)
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

can't find defined bundle

[Carl E. Ma]

Hi,

I am trying to create a checking script  to report core files on my server. But 
it keeps complaining no defined bundle, which I did. The line number "5,31" 
doesn't make sense either. What did I miss?

Thanks,

carl

$ ./1.cf
cf3> ./1.cf:5,31: syntax error, near token '.'
Bundle "“invalidfiles”" listed in the bundlesequence is not a defined bundle
Fatal cfengine error: Errors in promise bundles
cf-agent was not able to get confirmation of promises from cf-promises, so 
going to failsafe
 !!! No bundlesequence in the common control body
Fatal cfengine error: Errors in promise bundles

$more 1.cf
#!/usr/local/sbin/cf-agent -f
body common control
{
bundlesequence => { “invalidfiles” };
inputs => { “cfengine_stdlib.cf” };
version => “1.0.0”
}
bundle agentinvalidfiles
{
files:
“dir_list” slist => {“/etc”,”/var/spool/mail”,”/var/core”,”/var/tmp”,”/tmp”};
file_select => cores
}
body file_select cores
{
leaf_name => {“$dir_list/*.core”,”$dir_list/core.*” };
file_result => "leaf_name";

reports:

Time: $(sys.date)
Please arrange to remove following core files - $file_result.

}
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

CFEngine Help: Re: can't find defined bundle

[no-reply]

Forum: CFEngine Help
Subject: Re: can't find defined bundle
Author: zzamboni
Link to topic: https://cfengine.com/forum/read.php?3,24359,24360#msg-24360

Carl,

Your sample policy is ridden with errors. Some noticeable ones:

- "Pretty" quotes - not sure if this is the result of copy-and-paste or you 
typed the policy in some editor that does conversion. They need to be plain 
ASCII quotes.
- Missing semicolons at the end of several statements.
- Declaration of "dir_list" inside a files: section, needs to be inside a vars: 
section.
- String in reports: is not inside quotes.

I would suggest reading through the documentation on agent structure, files: 
promises, and file_select in particular. In the meantime, I think what you want 
is something like this:


#!/usr/local/sbin/cf-agent -f
body common control
{
  inputs => { "cfengine_stdlib.cf" };
  bundlesequence => { "invalidfiles" };
  version => "1.0.0";
}

bundle agent invalidfiles
{
  vars:
  "dir_list" slist => { "/tmp/", "/etc/" };
  files:
  "$(dir_list)"
file_select => by_name(".*\.core"),
transformer => "/bin/echo Please delete $(this.promiser)",
#delete => tidy,
depth_search => recurse("inf");
}


When run it gives:

$ cf-agent  -K -f ./t.cf
Please delete /tmp/foo.core


If you comment out the "transformer" line and uncomment the "delete" line, it 
will remove the files itself:

$ cf-agent  -KI -f ./t.cf
 -> Deleted file /tmp/foo.core


Hope this helps.

___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

CFEngine Help: Re: can't find defined bundle

[no-reply]

Forum: CFEngine Help
Subject: Re: can't find defined bundle
Author: roadtest
Link to topic: https://cfengine.com/forum/read.php?3,24359,24361#msg-24361

Diego, thanks for your reply. I should use the default locale:-). If I don't 
use transformer, may i have the file_list in the report output?  In following 
output, sys.date is substituted but file_result is not.

root@jumpstart2:/var/cfengine/inputs# cf-agent  -f ./1.cf.revised -K
R: 
Time: Sat Dec 17 23:43:01 2011
Please arrange to remove following core files - $(file_result).



$more 1.cf.revised

body common control
{
bundlesequence => { "invalidfiles" };
inputs => { "cfengine_stdlib.cf" };
}
bundle agent invalidfiles
{
vars:
"dir_list" slist => {"/etc","/var/spool/mail","/var/core","/var/tmp","/tmp"};

classes:

"ok" expression => "any";

files:

"$(dir_list)"
file_select => by_core;

reports:
ok::
"
Time: $(sys.date)
Please arrange to remove following core files - $(file_result).
";
}

body file_select by_core
{
#leaf_name => {"/*.core","$(dir_list)/core.*" };
leaf_name  => {"*.core" };
file_result => "leaf_name";

}

___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

CFEngine Help: Re: can't find defined bundle

[no-reply]

Forum: CFEngine Help
Subject: Re: can't find defined bundle
Author: zzamboni
Link to topic: https://cfengine.com/forum/read.php?3,24359,24362#msg-24362

I don't think there is a way to produce a list with all the files that were 
matched by a promise with a file_select attribute. file_result is not a 
variable you can expand, it's used in the file_select body to indicate the 
boolean expression to use when matching files.

To produce a list of files to delete without using a transformer, you could use 
the warn_only action policy:


bundle agent invalidfiles
{
  vars:
  "dir_list" slist => { "/tmp/", "/etc/" };
  files:
  "$(dir_list)"
file_select => by_name(".*\.core"),
#transformer => "/bin/echo Please delete $(this.promiser)",
delete => tidy,
action => warn_only,
depth_search => recurse("inf");
}


However, I should ask why you want CFEngine to just warn you about something? 
CFEngine is best when it can remediate problems itself. If your ultimate 
objective is to remove those files, you should just have CFEngine do it.

Side note: you do not have to define the "ok" class to use in the reports: 
section. You could use any other class that is always defined, such as 
"cfengine".

___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Re: can't find defined bundle

[Mark Burgess]

I see you don't have quotes around your reports promise, which probably 
invalidates the whole bundle.


reports:

  !xyz::

"

  

";


On 12/18/2011 02:59 AM, Carl E. Ma wrote:

Hi,

I am trying to create a checking script  to report core files on my 
server. But it keeps complaining no defined bundle, which I did. The 
line number "5,31" doesn't make sense either. What did I miss?


Thanks,

carl

$ ./1.cf
cf3> ./1.cf:5,31: syntax error, near token '.'
Bundle "“invalidfiles”" listed in the bundlesequence is not a defined 
bundle

Fatal cfengine error: Errors in promise bundles
cf-agent was not able to get confirmation of promises from 
cf-promises, so going to failsafe

 !!! No bundlesequence in the common control body
Fatal cfengine error: Errors in promise bundles

$more 1.cf
#!/usr/local/sbin/cf-agent -f
body common control
{
bundlesequence => { “invalidfiles” };
inputs => { “cfengine_stdlib.cf” };
version => “1.0.0”
}
bundle agentinvalidfiles
{
files:
“dir_list” slist => 
{“/etc”,”/var/spool/mail”,”/var/core”,”/var/tmp”,”/tmp”};

file_select => cores
}
body file_select cores
{
leaf_name => {“$dir_list/*.core”,”$dir_list/core.*” };
file_result => "leaf_name";

reports:

Time: $(sys.date)
Please arrange to remove following core files - $file_result.

}


___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine


___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine