CFEngine Help: Re: Problem accessing list variables in hash
Forum: CFEngine Help Subject: Re: Problem accessing list variables in hash Author: nickanderson Link to topic: https://cfengine.com/forum/read.php?3,26268,26273#msg-26273 Of course I come back and look at it in the morning and see some things I don't like. Anyway if you didnt want to make a second higher level method call you could of course bury that bundle method call inside of your create_users bundle and call it if sshkeys was specified for that user. ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: 3.1.4 => 3.3.4: has something changed regarding classes in bundles?
Forum: CFEngine Help Subject: 3.1.4 => 3.3.4: has something changed regarding classes in bundles? Author: davidlee Link to topic: https://cfengine.com/forum/read.php?3,26274,26274#msg-26274 (RHEL 5.x; cfengine community 3.1.4, just started migrating to 3.3.4) In RHEL the files that control network interfaces are "/etc/sysconfig/network-scripts/ifcfg-eth*" and look like: == DEVICE=eth0 HWADDR=aa:bb:cc:dd:ee:ff ONBOOT=yes BOOTPROTO=static IPADDR=10.156.164.33 NETMASK=255.255.252.0 == The natural cfengine way to maintain these is with "set_variable_values". We have been doing this reasonably happily for 15 months or more with version 3.1.4 (modulo a niggle described in bug 679). Today I have just been trying the latest 3.3.4, and something has changed. It sometimes isn't inserting lines because (according to a "-v" run of cf-agent) it reckons, incorrectly, that a pattern-matching line is already present. --- For the reader not familiar with COPBL's "set_variable_values": If a pattern-matched line is absent, "set_variable_values" inserts it; if it already present, "set_variable_values" edits it. This is internally controlled by setting a class within the "set_variable_values" bundle, e.g. "ONBOOT_in_file". --- We have several such files. So "set_variable_values" is being called several times, once per interface-file. My suspicion is that, under 3.3.4 but not 3.1.4, the class-setting is leaking from one invocation to the next. So that if a call for one interface-file sets a class (e.g. "ONBOOT_in_file"), I suspect that the behaviour of the next call will be affected by this class's existence from earlier call. (So if an early-checked file includes an "ONBOOT" line, this sets the class; a later-checked file, lacking such a line, will fail to get the line inserted because the earlier class setting seems to leak through.) My understanding is that such a class should be local to the invocation, and should evaporate immediately afterwards. But I suspect that it may be persistent (global?). As I say, this is a well-established, well-used piece of our config; the change is that I'm running it under 3.3.4 rather than 3.1.4. Before I put too much effort into trying to debug this further, is anyone able to say whether this is a known issue? (Is my understanding of the intended class (non-)persistence correct?) ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
Re: which cfengine_stdlib.cf
On Thu, 21 Jun 2012 15:44:48 +0200 Bas van der Vlies wrote: BvdV> On 06/21/2012 02:50 PM, Ted Zlatanov wrote: >> On Thu, 21 Jun 2012 13:46:15 +0200 Bas van der Vlies wrote: >> I have not updated CFEngine::stdlib in Design Center from the copbl >> repository because the newer stdlib version has service promises, while >> Design Center supports 3.2.x, which doesn't have service promises. >> >> There are very exciting changes coming in 3.4 (see the cfengine core >> Github repository, and Mark Burgess tweeted about metadata and >> namespaces) so when that's out we're very likely to make it the minimum >> required version for Design Center, and to do minor sketch rewrites to >> make use of the new functionality. >> BvdV> I have seen and read them ;-). So the copbl will be the leading one. Then i will use this one and forget the others. BvdV> Will the metadata or name space solve the problem of multiple includes of copbl library or is this senario impossible with cf-sketch? This is exactly how we will solve it, with namespaces. CFEngine::stdlib will have the default namespace, to preserve backward compatibility and to make it easier to use. CFEngine::stdlib::x_y_z will have the stdlib__x_y_z namespace. This approach will work for other sketches as well that wish to provide multiple versions, of course. From experience I think it's better to provide this kind of versioning explicitly than automatically, based on the module version in sketch.json. Doing it automatically can cause some nasty bugs. So I won't have any built-in support in cf-sketch to set the namespace based on the sketch name. Ted ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: High Availability / High Performance Advanced Automation Cfengine Architecture
On Mon, 18 Jun 2012 18:26:48 +0200 (CEST) msvob...@linkedin.com wrote:
Hi Mike,
that was a very interesting and useful post.
I wanted to bring up a tool I wrote on my own recently, and it's not
CFEngine-specific (although it can produce a CFEngine config, it can
also produce JSON and eventually YAML).
https://github.com/tzz/jim
It lets you do the kind of structured assignments you show in the vars:
section using a purely data-driven structure.
n> 7 vars:
n> 8 PROD::
n> 9 "environment" string =>
"PROD";
...
n> 30 ### dc1
##
n> 31 (dc1|dc5)::
n> 32 "mps1" string =>
"dc1-cage1-mps01.corp.cfengine.com",
n> 33 policy =>
"free";
...
n>127 "master_policy_servers" or =>
{
n>128
"dc3_cage6_mps01_prod_cfengine_com",
n>129
"dc3_cage6_mps02_prod_cfengine_com",
n>130
"dc3_cage7_mps01_prod_cfengine_com",
n>131
"dc3_cage7_mps02_prod_cfengine_com",
n>132
"dc3_cage9_mps01_prod_cfengine_com",
n>133
"dc3_cage9_mps02_prod_cfengine_com",
n>134
"dc1_cage1_mps01_corp_cfengine_com",
n>135
"dc1_cage1_mps02_corp_cfengine_com",
n>136
"dc2_cage1_mps01_prod_cfengine_com",
n>137
"dc2_cage1_mps02_prod_cfengine_com",
n>138
"dc2_cage5_mps01_prod_cfengine_com",
n>139
"dc2_cage5_mps02_prod_cfengine_com",
n>140
"dc2_cage2_mps01_prod_cfengine_com",
n>141
"dc2_cage2_mps02_prod_cfengine_com",
n>142
"dc2_cage4_mps01_prod_cfengine_com",
n>143
"dc2_cage4_mps02_prod_cfengine_com",
n>144
"dc4_cage10_mps01_corp_cfengine_com",
n>145
"dc4_cage10_mps02_corp_cfengine_com",
n>146
"dc6_cage11_mps01_prod_cfengine_com",
n>147
"dc6_cage11_mps02_prod_cfengine_com", };
...
n>285 "CORP" xor =>
{"dc4_corp_cfengine_com", "dc5_corp_cfengine_com", "dc1_corp_cfengine_com",
"dc6_corp_cfengine_com", };
...
n> 7 PROD.dc1::
n> 8 "site_specific_policy_location" string =>
"/var/cfengine/masterfiles/PROD/dc1/cf-agent";
The last one, especially, where you repeatedly define the masterfiles
location based on some classes, can be greatly simplified through jim.
Let me know if the README.md for jim makes sense, and if you are
interested in how it could handle your use case. I can write out an example.
Thanks
Ted
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: 3.1.4 => 3.3.4: has something changed regarding classes in bundles?
Forum: CFEngine Help Subject: Re: 3.1.4 => 3.3.4: has something changed regarding classes in bundles? Author: bahamat Link to topic: https://cfengine.com/forum/read.php?3,26274,26277#msg-26277 Can you show us the offending promises? ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: 3.1.4 => 3.3.4: has something changed regarding classes in bundles?
Forum: CFEngine Help
Subject: Re: 3.1.4 => 3.3.4: has something changed regarding classes in bundles?
Author: davidlee
Link to topic: https://cfengine.com/forum/read.php?3,26274,26278#msg-26278
I've been doing a little more digging. I think the main fault is a
long-standing one in the COPBL "set_variable_values()". A coding bug in the
old code (e.g. 3.1.4) masked it; some sort of coding change (probably to fix
other manifestations of that underlying bug) since then now exposes it.
Firstly, from the manual:
Another type of class definition happens when you define classes based on the
outcome of a promise, e.g. to set a class if a promise is repaired, one might
write:
"promiser..."
...
classes => if_repaired("signal_class");
These classes are global in scope. [...]
Note that final "global in scope". This suggests that a class that is set in
this manner in the depths of one call to "set_variable_values" SHOULD be
preserved, and could be expected to affect subsequent actions.
Here is COPBL's "set_variable_values" (slightly simplified for clarity here):
bundle edit_line set_variable_values(v)
{
vars:
"index" slist => getindices("$(v)");
# Be careful if the index string contains funny chars
"cindex[$(index)]" string => canonify("$(index)");
field_edits:
# match a line starting like the key = something
"\s*$(index)\s*=.*"
edit_field => col("=","2","$($(v)[$(index)])","set"),
classes => if_ok("$(cindex[$(index)])_in_file"),
comment => "Match a line starting like key = something";
insert_lines:
"$(index)=$($(v)[$(index)])",
comment => "Insert a variable definition",
ifvarclass => "!$(cindex[$(index)])_in_file";
}
Focus on those two "XXX_in_class" occurrences.
Suppose the user edits two similar files, using similar data, e.g. pattern "v
=> VALUE1" etc. Suppose, too, that the first file already includes a "KEY1..."
line, and the second does not have such a line.
Then the first file will use the "field_edits" section, and will set a class
"KEY1_in_file". (It will also be prevented from using its "insert_lines"
section, which is exactly want we want.) Good. But the problem is the class
"KEY1_in_file" is globally scoped. So what happens next?
In the second file, which lacks "KEY1", the user would expect a "KEY1" line to
be inserted. But the "KEY1_in_file" is still lurking from the distant past on
the first file; it will prevent the use of "insert_lines" on the second file,
even though the user's intention is that it should insert the line.
So it looks like the older version of cfengine was doing what the user
intended, but by accident. The newer version is behaving in the technically
correct fashion (according to the manual page), but not how the user intended.
To test this, I made a private copy of "set_variable_values()", but instead of
calling the class (on its two occurrences) "XXX_in_file", I called it
"XXX_in_$(edit.filename)". (I used "XXX" there merely as shorthand for
clarity; my new class is actually "$(cindex[$(index)])_in_$(edit.filename)".)
This version seems to behave as the user intends for both 3.1.4 and 3.3.4.
Summary:
Old code had a bug, "set_variable_values()" also has a bug.
Old combination worked as the user expected, but by accident.
New code corrects its own bug, but now exposes the "set_variable_values()" bug.
Suggested fix: "set_variable_values()" should include $(edit.filename) in the
class it sets.
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: feature proposal for cfengine.el
On Fri, 15 Jun 2012 10:47:23 -0500 Ron Parker wrote: RP> On Fri, Jun 15, 2012 at 9:57 AM, Marco Marongiu wrote: >> I found that having the promises laid out in normal order in the bundles >> can help a lot in understanding how things actually go on when the >> policy is run. >> >> It would be nice if we had a key combination that, once pressed, detects >> the bundle the cursor is in, and sets out the correspondent promises. >> E.g., in an agent bundle it would produce something like: RP> This is really orthogonal to cfengine-mode. A number of emacs RP> packages support the functionality you are seeking including skeleton, RP> auto-insert, yasnippet, srecode. See RP> http://www.emacswiki.org/emacs/CategoryTemplates lists most of them, RP> however auto-insert is conspicuously absent, RP> http://www.emacswiki.org/emacs/AutoInsertMode. I thought about it and agree with Ron. I personally use skeleton the most but the others Ron mentioned are good too. That template could live in cfengine-mode itself, but I don't think we want to tie it any deeper to the parser state (trust me, you don't want to know about the Emacs parser states :) Marco and others, do you want to suggest some good blank templates for the various bundles and bodies? I'll take care of integrating them with cfengine-mode.el. They'll be in the menus somewhere. Thanks Ted ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: 3.1.4 => 3.3.4: has something changed regarding classes in bundles?
Forum: CFEngine Help Subject: Re: 3.1.4 => 3.3.4: has something changed regarding classes in bundles? Author: zzamboni Link to topic: https://cfengine.com/forum/read.php?3,26274,26280#msg-26280 David - good and correct analysis. Indeed by definition all classes set by the "classes" attribute are global. Your addition of the filename to the class name makes sense. I will add it to the stdlib. Thanks! ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: It is possible to uses a slist variable in the inputs directive ?
Forum: CFEngine Help
Subject: It is possible to uses a slist variable in the inputs directive ?
Author: ydast...@caesars.com
Link to topic: https://cfengine.com/forum/read.php?3,26281,26281#msg-26281
Hello,
I try to used a string list variable in the inputs directive without success
here is the code snippet:
body common control
{
bundlesequence => { "environments", "main", "env_main" };
inputs => {
"cfengine_stdlib.cf",
"environment_$(environments.active)/env_promises.cf",
"@(environments.cffiles)",
};
}
bundle common environments {
vars:
any::
"active" string => "testing", policy => "overridable";
"cffiles" slist => lsdir("/home/yves/cferules/environment_$(active)",
"p-.*", "true");
}
There is a way to obtain this kind of behavior ?
At the moment I received an error of type:
Can't stat file "./@(environments.cffiles)" for parsing
Yves
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: It is possible to uses a slist variable in the inputs directive ?
no-re...@cfengine.com wrote:
>Forum: CFEngine Help
>Subject: It is possible to uses a slist variable in the inputs
>directive ?
>Author: ydast...@caesars.com
>Link to topic:
>https://cfengine.com/forum/read.php?3,26281,26281#msg-26281
>
>Hello,
>
>I try to used a string list variable in the inputs directive without
>success here is the code snippet:
>
>
>
>body common control
>{
> bundlesequence => { "environments", "main", "env_main" };
>
> inputs => {
>"cfengine_stdlib.cf",
>"environment_$(environments.active)/env_promises.cf",
>"@(environments.cffiles)",
> };
>}
>
>bundle common environments {
> vars:
>any::
> "active" string => "testing", policy => "overridable";
>"cffiles" slist => lsdir("/home/yves/cferules/environment_$(active)",
>"p-.*", "true");
>}
>
>
>There is a way to obtain this kind of behavior ?
>
>
>At the moment I received an error of type:
>
>
>Can't stat file "./@(environments.cffiles)" for parsing
>
>
>Yves
>
>___
>Help-cfengine mailing list
>Help-cfengine@cfengine.org
>https://cfengine.org/mailman/listinfo/help-cfengine
What version of cfengine?
--
Sent from Kaiten Mail for Android. Please excuse my brevity.
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Re: CFEngine Help: It is possible to uses a slist variable in the inputs irective ?
You need to remove the quotes around the list.
--Diego
>
> > Forum: CFEngine Help
> > Subject: It is possible to uses a slist variable in the inputs
> > directive ?
> > Author: ydast...@caesars.com
> > Link to topic:
> > https://cfengine.com/forum/read.php?3,26281,26281#msg-26281
> >
> > Hello,
> >
> > I try to used a string list variable in the inputs directive without
> > success here is the code snippet:
> >
> >
> >
> > body common control
> > {
> > bundlesequence => { "environments", "main", "env_main" };
> >
> > inputs => {
> > "cfengine_stdlib.cf",
> > "environment_$(environments.active)/env_promises.cf",
> > "@(environments.cffiles)",
> > };
> > }
> >
> > bundle common environments {
> > vars:
> > any::
> > "active" string => "testing", policy => "overridable";
> > "cffiles" slist => lsdir("/home/yves/cferules/environment_$(active)",
> > "p-.*", "true");
> > }
> >
> >
> > There is a way to obtain this kind of behavior ?
> >
> >
> > At the moment I received an error of type:
> >
> >
> > Can't stat file "./@(environments.cffiles)" for parsing
> >
> >
> > Yves
> >
> > ___
> > Help-cfengine mailing list
> > Help-cfengine@cfengine.org
> > https://cfengine.org/mailman/listinfo/help-cfengine
> >
>
>
> What version of cfengine?
> --
> Sent from Kaiten Mail for Android. Please excuse my brevity.
> ___
> 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
Cfengine license
In the LICENSE file included with the cfengine the contents of the GPLv3 is included. It also states "CFEngine is provided under the terms of the GNU General Public License..." The GPL itself in section 14 states "If the Program doesn't specify a version number...you may choose any version ever published". Given that the line that states that cfengine is under the GPL doesn't explicitly state a version number, can I use cfengine3 under the terms of the GPLv2? Or is it really exactly version 3? -- Brian smime.p7s Description: S/MIME cryptographic signature ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: It is possible to uses a slist variable in the inputs directive ?
Forum: CFEngine Help Subject: Re: It is possible to uses a slist variable in the inputs directive ? Author: nickanderson Link to topic: https://cfengine.com/forum/read.php?3,26281,26284#msg-26284 I think Diego is right, you have to remove the quotes around the list in inputs. That has caught me before too. ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: It is possible to uses a slist variable in the inputs directive ?
Forum: CFEngine Help
Subject: Re: It is possible to uses a slist variable in the inputs directive ?
Author: ydast...@caesars.com
Link to topic: https://cfengine.com/forum/read.php?3,26281,26286#msg-26286
Same results with the quotes removes:
body common control
{
version => "$Id: promises.cf 17 2012-06-21 19:51:23Z $";
bundlesequence => { "environments", "main", "env_main" };
inputs => { "cfengine_stdlib.cf", @(environments.cffiles) };
}
give:
cf-promises -f ./promises.cf
Can't stat file "./@(environments.cffiles)" for parsing
!!! System error for stat: "No such file or directory"
snif!
Yves
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
Removed packages treated as installed by stdlib
I ran in to an issue with a package that got removed but not
reinstalled by CFE. The dpkg-related patterns were matching anything
in the output as installed. But if you remove or purge a package after
installing it, it still shows up in the output of 'dpkg -l'. I just
threw a pull request over the wall that corrected it on the Ubuntu box
I was working with, https://github.com/cfengine/copbl/pull/10.
--
Ron Parker
Don't type things you find on the Internet into your computer!
:(){ :|:&};:
___
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: Cfengine license
Forum: CFEngine Help Subject: Re: Cfengine license Author: zzamboni Link to topic: https://cfengine.com/forum/read.php?3,26285,26288#msg-26288 Hi Brian, CFEngine is licensed under GPL v3, since that is the license included with the code, even if there are some references that do not specify the number. We will be updating the references to make this clear. Best regards, --Diego ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: Removed packages treated as installed by stdlib
Forum: CFEngine Help Subject: Re: Removed packages treated as installed by stdlib Author: zzamboni Link to topic: https://cfengine.com/forum/read.php?3,26287,26289#msg-26289 Ron, thank you for the patch. I have merged it. ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
CFEngine Help: Re: It is possible to uses a slist variable in the inputs directive ?
Forum: CFEngine Help Subject: Re: It is possible to uses a slist variable in the inputs directive ? Author: zzamboni Link to topic: https://cfengine.com/forum/read.php?3,26281,26290#msg-26290 Yves, The example without the quotes works fine for me. Are there any files that are matches by the lsdir() function? If there are none, and the slist is left undefined, then interpolation will fail and the string gets used as-is. ___ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
