Upgrading to cfengine-3.4.x branch, and getting stuck cf-execd processes?

The behavior of -F flag has changed from 3.3.x to 3.4.x branch:

    Changed functionality:
    
    - cf-execd -F switch no longer implies 'run once'. New -O/--once
    option is added to achieve this behaviour. This makes cf-execd
    easier to run from systemd, launchd and other supervision
    systems.

So you need to update your crontab promises to add *-O* flag to *cf-execd -F*, to get the old (and correct for crontab) behavior:

    */5 * * * * root /var/cfengine/bin/cf-execd -FO

With its group commands (groupinstall, groupremove, …), Yum is able to install a set of packages to quickly set up a system for a specific task.

This blog post is a great introduction to Yum software groups

In CFEngine, it is now possible (feature merged in master, but not yet released) to handle such groups through yum_group package_method.

Some examples:

• Installing perl-runtime and basic-desktop groups:

body common control {
  bundlesequence => { "foo" };
  inputs  =>  { "/var/cfengine/inputs/libraries/cfengine_stdlib.cf" };
}

bundle agent foo {

  vars:
    "packages"      slist   =>      { "perl-runtime", "basic-desktop" };

  packages:
    "$(packages)"
      package_policy        =>      "add",
      package_method        =>      yum_group;
}

• Removing debugging group:

body common control {
  bundlesequence => { "foo" };
  inputs  =>  { "/var/cfengine/inputs/libraries/cfengine_stdlib.cf" };
}

bundle agent foo {

  vars:
    "packages"  slist   =>  { "debugging" };

  packages:
    "$(packages)"
      package_policy    =>  "delete",
      package_method    =>  yum_group;
}

You can find here a full example (with runtime output), and here the body of the yum_group package_method

Update 2013-03-20: hcgrep has been merged into CFEngine design center

Because cf-promises -v displays hard classes as a single line, it requires a thorough read to determine if a specific hard class is defined, and grep did not help much because they are returned as a single line:

(wrapped for lisibility)

# cf-promises -v|grep freebsd
cf3> Operating System Type is freebsd
cf3> Using internal soft-class freebsd for host bsd82.local
cf3> Additional hard class defined as: freebsd_8_2_RELEASE_p4
cf3> Additional hard class defined as: freebsd_amd64
cf3> Additional hard class defined as: freebsd_amd64_8_2_RELEASE_p4
cf3> GNU autoconf class from compile time: compiled_on_freebsd8_2
cf3>  -> Hard classes = { 172_16_100_1 172_16_2_1 192_168_2_14 1_cpu 64_bit Afternoon Day17 GMT_Hr12 Hr13 Hr13_Q1 Lcycle_0 March Min00
 Min00_05 PK_MD5_e964d2ce7a4dd7887a7374142cff1fb7 Q1 Sunday Yr2013 amd64 any bsd82 bsd82_local cfengine cfengine_3 cfengine_3_5
cfengine_3_5_0a2 common community_edition compiled_on_freebsd8_2 freebsd freebsd_8_2 freebsd_8_2_RELEASE_p4 freebsd_amd64
freebsd_amd64_8_2_RELEASE_p4 ipv4_172 ipv4_172_16 ipv4_172_16_100 ipv4_172_16_100_1 ipv4_172_16_2 ipv4_172_16_2_1 ipv4_192
ipv4_192_168 ipv4_192_168_2 ipv4_192_168_2_14 local mac_unknown net_iface_em0 net_iface_gif0 net_iface_le0 verbose_mode }

Awk can help to split each hard class over separate lines, to render them prettier:

Some time ago, with cfengine-3.3.5 clients I started getting this error server side:

Jan  2 10:26:33 serv cf3[7732]:  Private decrypt failed = padding check failed
Jan  2 10:29:15 serv cf3[7732]:  Private decrypt failed = block type is not 02
Jan  2 10:31:47 serv cf3[7732]:  Private decrypt failed = padding check failed 

The clients could no longer authenticate themselves against the server, and became isolated. I was not able to determine reasons of the error, which seems to happen randomly, at any time, even without policies update. Operating system, architecture, ip subnet didn’t matter in occurrence of the problem.