cfengine 3 only seems to update on bootstrap

[apg]

I am making changes in /var/cfengine/masterfiles/promises.cf on the master server. It doesn't appear that any of the changes are propagated until I do a boot strap:
cf-agent --bootstrap --policy-server 10.10.0.28 on both the master and the client.

Is that normal?

Once I do a bootstrap on the server and client, the files are copied and promises are kept/repaired. Watching cf-serverd -F -v on the master, the only time the client talks to the master is when its bootstrapped:
cf-agent --bootstrap --policy-server 10.10.0.28

Is that normal?

Thanks,

-al

[Nick Anderson]

Hi Al,

The default policy does updates in failsafe.cf, and the default exec command in body executor control is 

 exec_command => "$(sys.cf_twin) -f failsafe.cf && $(sys.cf_agent)";

--bootstrap executes failsafe.cf if it exists, and if not it uses an embeded failsafe to copy the policy down the first time.

You might find this post about how cf_promises_validated plays into the default update policy useful.

http://www.cmdln.org/2012/10/24/cfengine-3-policy-update-or-how-cf_promises_validated-works/

[apg]

Hey, thanks Nick! I had the day off today. I will take a look first thing tomorrow morning.

[apg]

so, if I understand this correctly, if there is a mismatch of cf_promises_validated between the hub and "not hub" the "not hub" should then scan and download masterfiles/* from the hub? I deleted cf_promises_validated from the "not hub", a new cf_promises_validated was generated on the not hub, but it did not download the changes from the hub.

One other thing, obviously I'm a noob with cfengine, but I can not find where things like u_m, u_rcp, u_input_files, etc are defined. I did not find anything about them in cf3-Reference manual? Some of them look like constants, others look like functions. This is really confusing.
 

[Brad Beyenhof]

On Fri, Nov 16, 2012 at 1:29 PM, apg <allen...@gmail.com> wrote:
> so, if I understand this correctly, if there is a mismatch of
> cf_promises_validated between the hub and "not hub" the "not hub" should
> then scan and download masterfiles/* from the hub? I deleted
> cf_promises_validated from the "not hub", a new cf_promises_validated was
> generated on the not hub, but it did not download the changes from the hub.

It doesn't look for a mismatch... it actually compares the timestamps,
and only copies new policies if the hub file is newer. You seem to
have shown experimentally that lacking the file on the "not hub" will
compare as if its file was labeled with the current timestamp, and
will therefore be artificially newer than the hub and will not copy
new policies.

--
Brad Beyenhof . . . . . . . . . . . . . . . . http://augmentedfourth.com
There are only two kinds of men: the righteous, who believe themselves
sinners; the rest, sinners, who believe themselves righteous.
~ Blaise Pascal (1623–1662)

[Nick Anderson]

On 11/16/2012 03:29 PM, apg wrote:
> so, if I understand this correctly, if there is a mismatch of
> cf_promises_validated between the hub and "not hub" the "not hub" should
> then scan and download masterfiles/* from the hub? I deleted
> cf_promises_validated from the "not hub", a new cf_promises_validated was
> generated on the not hub, but it did not download the changes from the hub.

Where did you delete cf_promises_validated from on the "not hub"?
You should have two, one in /var/cfengine/masterfiles (that one is
generated when new policy is validated), and one in /var/cfengine/inputs
(that one was copied from the hub and is used to see if its time to do a
full update or not)

If you deleted the one from inputs, I would like to take a closer look
at it with you because if cf_promises_validated does not exist in
inputs, it should be copied from the hub, and the
validated_updates_ready class should be raised which is used to restrict
the promise with handle name update_files_inputs_dir that performs the
full update.

At least, that's my understanding.

> One other thing, obviously I'm a noob with cfengine, but I can not find
> where things like u_m, u_rcp, u_input_files, etc are defined. I did not
> find anything about them in cf3-Reference manual? Some of them look like
> constants, others look like functions. This is really confusing.

Don't worry about it, if you aren't still learning, your probably dead.

Those things are bodies (if i am correct on my terminology, if not
hopefully someone will kindly correct me), you may see their types in
the reference manual (for example u_rcp is a copy_from body. See
copy_from in files in the Reference manual
https://cfengine.com/manuals/cf3-Reference#copy_005ffrom-in-files).

Most right hand side values are user definable like copy_from, I think
these are called external bodies, others like create in files
https://cfengine.com/manuals/cf3-Reference#create-in-files have a
pre-defined list of valid options. Typically the stdlib is a good place
to look for those, but failsafe.cf should be self contained.

You can use this grep to help find where bodies or bundles are defined
grep -nRP "(body\s*|bundle\s*).* u_rcp" /var/cfengine/masterfiles

Example result:
failsafe.cf:190:body copy_from u_rcp(from,server)

So its found on line 190 of failsafe.cf

[Nick Anderson]

On 11/16/2012 03:56 PM, Brad Beyenhof wrote:
> You seem to
> have shown experimentally that lacking the file on the "not hub" will
> compare as if its file was labeled with the current timestamp, and
> will therefore be artificially newer than the hub and will not copy
> new policies.

I would not expect this behaviour. I have a suspicion that the
cf_promises_validated file that was deleted on "not hub" was the one
located in /var/cfengine/masterfiles.

[Nick Anderson]

On 11/16/2012 03:56 PM, Brad Beyenhof wrote:

> It doesn't look for a mismatch... it actually compares the timestamps,

actually actually, it used to only compare timestamps (when
cf_promises_validated was young and was just an empty file).

More recent policies have u_rcp using digest for comparison, and
cf_promises_validated now contains a datestamp.

https://github.com/cfengine/core/blob/master/masterfiles/failsafe/failsafe.cf

body copy_from u_rcp(from,server)
{
source => "$(from)";
compare => "digest";
trustkey => "false";

!am_policy_hub::

servers => { "$(server)" };
}

[Brad Beyenhof]

On Fri, Nov 16, 2012 at 2:11 PM, Nick Anderson <ni...@cmdln.org> wrote:
> On 11/16/2012 03:56 PM, Brad Beyenhof wrote:
>> It doesn't look for a mismatch... it actually compares the timestamps,
>
> actually actually, it used to only compare timestamps (when
> cf_promises_validated was young and was just an empty file).
>
> More recent policies have u_rcp using digest for comparison, and
> cf_promises_validated now contains a datestamp.

Actually actually actually, :)

That's what I meant, but didn't explain well. The 'timestamp' to which
I was referring was the datestamp written to the file, not the
timestamp of the file's inode. You get used to these things and forget
about the history/explanations sometimes...

[apg]

Yes! That is correct. I deleted it from /var/cfengine/masterfiles. So, I deleted /var/cfengine/inputs/cf_promises_validated*, AND from /var/cfengine/masterfiles/. cf_promises_validated is re-created with a new timestamp in /var/cfengine/masterfiles, not in inputs/ and it still doesn't update. I think I might  edit failsafe.cf on the client and comment out the checks for cf_promises_validated, just as a test.

[apg]

Right, so the timestamps in the files are different, because I deleted them on the client.

[Nick Anderson]

Yeah, so if I recall correctly it used to check if the mtime of the file on the hub was newer, if it was it would update. Now it uses digest so it just looks for content difference, it doesn't actually compare the timestamps for what's newer. Date stamp is just sufficiently different and likely to assist a human looking at the file more than a uuid or something.

--
Sent from Kaiten Mail. Please excuse my brevity.

[Nick Anderson]

What command are you running and expecting am update to happen.

[Nick Anderson]

On Friday, November 16, 2012 4:35:59 PM UTC-6, apg wrote:

Yes! That is correct. I deleted it from /var/cfengine/masterfiles. So, I deleted /var/cfengine/inputs/cf_promises_validated*, AND from /var/cfengine/masterfiles/. cf_promises_validated is re-created with a new timestamp in /var/cfengine/masterfiles, not in inputs/ and it still doesn't update. I think I might  edit failsafe.cf on the client and comment out the checks for cf_promises_validated, just as a test.

Updates happen when failsafe.cf is executed.

see exec command from body executor control in promises.cf

   exec_command => "$(sys.cf_twin) -f $(sys.workdir)/inputs/failsafe/failsafe.cf && $(sys.cf_agent)";

cf-execd is the daemon that updates and executes your policy, and this is the command that it executes by default ever 5 minutes.

You can see that it executes failsafe.cf to perform the update, then does a normal agent execution.

I suspect that your running cf-agent which would generate a new cf_promises_validated file in /var/cfengine/masterfiles (because new policy has been validated). But the one in inputs wont be there until you run with failsafe.cf and it looks to see that the cf_promises_validated file in inputs is the same as cf_promises_validated in masterfiles on the hub.

[apg]

ah, yes... I see the copy_from body definition. But I don't see the where u_rcp is defined? It sounds like I need to re-read about bodies. Thanks for pointing me in the right direction.

[Nick Anderson]

On Friday, November 16, 2012 4:49:51 PM UTC-6, apg wrote:

ah, yes... I see the copy_from body definition. But I don't see the where u_rcp is defined? It sounds like I need to re-read about bodies. Thanks for pointing me in the right direction.

Did you run that grep?

u_rcp you should be able to find in failsafe.cf 

[apg]

I was just running cf-agent -Kv. I sounded like cf-agent was meant to be re-run over and over again?

[apg]

Yes, I ran that grep command. I guess I didn't know what I was looking at. Knowing that's where it is defined really helps. Now I just need to keep reading so I understand what I am looking at! THANKS!!

[Nick Anderson]

This question of "where is blah defined" seems to come up fairly often.

So, I wrote a thing. Its pretty ugly but it might prove useful to someone.

It takes two arguments the bundle or body name

https://gist.github.com/4093338

Here is some example output.

% cf-locate u_rcp /var/cfengine/masterfiles
definition for u_rcp found in /var/cfengine/masterfiles/failsafe.cf on line 198

body copy_from u_rcp(from,server)
{
 source      => "$(from)";
 compare     => "digest";
 trustkey    => "false";

!am_policy_hub::

 servers => { "$(server)" };
}

#########################################################


% cf-locate main /var/cfengine/masterfiles
definition for main found in /var/cfengine/masterfiles/promises.cf on line 20

bundle agent main
{
 reports:
  am_policy_hub::
   "--> I'm a policy hub."
      comment => "Display message on screen/email",
       handle => "main_reports_i_am_hub";

  !am_policy_hub::
   "--> $(sys.policy_hub) is my policy hub."
      comment => "Display message on screen/email",
       handle => "main_reports_is_my_hub";
   "--> CFE is running on $(sys.fqhost)"
      comment => "Display message on screen/email",
       handle => "main_reports_cfe_running";
}

###############################################################################
#
# common def
#  - common/global variables and classes here  
#
###############################################################################

[apg]

Thanks Nick! This really helps. I'm still getting use to CFEngine syntax. I'm a perl hack. It looks a lot like perl, but, it isn't. Where u_rcp was being defined, looked to me like the function u_rcp being called. I bought the book Learning CFEngine 3. It's a great book but you don't really know what  you are not getting until you try and use it.

[Nick Anderson]

On 11/20/2012 11:21 AM, apg wrote:
> Thanks Nick! This really helps. I'm still getting use to CFEngine syntax.
> I'm a perl hack. It looks a lot like perl, but, it isn't. Where u_rcp was
> being defined, looked to me like the function u_rcp being called. I bought
> the book Learning CFEngine 3. It's a great book but you don't really know
> what you are not getting until you try and use it.

Absolutely, just need to get your feet wet, or jump into the frying pan
whichever you prefer.

There is a feature request for a cli reference tool. You might find the
thread interesting, also a couple scripts there the cf-locate version
there is slightly updated with a better regex match on the content of
the defined body or bundle.

https://cfengine.com/dev/issues/1562

[Bas van der Vlies]

On Friday, November 16, 2012 8:50:42 PM UTC-8, Nick Anderson wrote:
This question of "where is blah defined" seems to come up fairly often.

So, I wrote a thing. Its pretty ugly but it might prove useful to someone.

It takes two arguments the bundle or body name

https://gist.github.com/4093338

Here is some example output.

Nick this is a nice 'utility.

--
Bas van der Vlies
mail: ba...@sara.nl<mailto:ba...@sara.nl>
SARA - Academic Computing Services , Amsterdam, The Netherlands

[Nick Anderson]

On 11/21/2012 01:32 AM, Bas van der Vlies wrote:
> Nick this is a nice 'utility.

Thanks Bas,

One with a little tighter regex for the body/bundle is on this bug report
https://cfengine.com/dev/issues/1562

I think cf-promises --parse-tree that's coming in 3.4 could be useful
for some of this kind of thing as well.

[apg]

Just for reference, the fix for me was to download:
https://raw.github.com/cfengine/core/master/masterfiles/failsafe/failsafe.cf
...as Nick suggested below.

I then rm -r /var/cfengine/inputs/

on both the hub and clients and ran:
cf-agent --bootstrap --policy-server 10.10.0.XX

on both the hub, and client.

Now when I make a change on the hub in /var/cfengine/masterfiles/
that change propagates out as one would expect.

Thanks for the help!

-al