Passing bodies to (method) bundles?

[miekg]

Hi,

If got the following code (based of https://northerntech.atlassian.net/browse/CFE-4225):

bundle agent sync_cp_annotated_files(files,from,to,pattern)
{
  defaults:

    "pattern"
      string         => "(?i:.*by cfengine.*)",
      if_match_regex => "";


  vars:

    "found"          slist  => lsdir("$(to)", "^(?!(\.$|\.\.$)).*", false);

    "dest[$(found)]"
      string => "$(found)",
      if     => regline("$(pattern)", "$(to)/$(found)");

    "dests"          slist  => getindices(dest);

    "remove"         slist  => difference(dests, files);


  files:

    "$(to)/"
      perms     => mog(0755, root, root),
      create    => "true";

    "$(to)/$(files)"
      copy_from => no_backup_rdcp("$(def.distr_files_dir)/$(from)/$(files)", $(sys.policy_hub)),
      perms     => mog(0644, root, root);

    "$(to)/$(remove)" delete    => tidy;
}

which is most often called like this:

vars:
 crond" slist => { "mailman", "kwal" };      
methods:
 "any"
    usebundle => sync_cp_annotated_files(@(crond), "etc/cron.d", "/etc/cron.d, ""),
    classes => if_repaired("files_synced");

Now you see those mog(0644, root, root) and mog(0755, root, root) is there any way to make that configurable other than adding them to the bundle's parameters?

Or should I make a prototype like: bundle agent sync_cp_annotated_files(files,from,to,pattern, mogfile, mogdir) and then use them as perms => $(mogfile); (if that works at all)

I looked at with which may or may not do what I need here, but that seems to be limited to variable passing.

(unrelated I may drop the directory creation from this bundle, with would leave only one mog to be configured - this may make things easier).

Thanks,
Miek

[nickanderson]

Scanning the policy, I saw this directory creation promise:

"$(to)/"
  perms     => mog(0755, root, root),
  create    => "true";

I think you should add a trailing dot so that it's very explicitly a directory.

"$(to)/."
  perms     => mog(0755, root, root),
  create    => "true";

Next I saw this:

"any"
   usebundle => sync_cp_annotated_files(@(crond), "etc/cron.d", "/etc/cron.d, ""),
   classes => if_repaired("files_synced");

/me get's on soap-box to rail against the if_repaired classes body.

I do not like this body:

• I often see it used for something like if_repaired( "restart_ssh" ) then later in the policy you see restart_ssh:: "ssh" service_policy => "restart" which tells you hardly anything about the context under which ssh is being restarted. now, you did not fall in to that trap here huzah, but none the less I still dislike this body.
• It always defines namespace scoped classes. So if you sync some other files not cron related and you use the same if_reparied( "files_synced" ) classes attribute value then something that class guarded will be triggered in a completely unrelated policy.
• I recommend using body classes results.
  • It takes two parameters, scope and prefix letting you specify if you want to use the class in other bundles by having the class namespace scoped or defining classes that are scoped to the current bundle only.
    • classes => results( "bundle", "cron_d_files" )
    • classes => results( "namespace", "cron_d_files" )
• It defines classes for all outcomes of the promise. So, you would get classes like cron_d_files_repaired, cron_d_files_reached, cron_d_files_not_kept, cron_d_files_error, cron_d_files_failed, cron_d_files_denied, cron_d_files_timeout, and cron_d_files_kept. The _reached suffixed class is defined no matter the outcome. This also exposes the information necessary to dissect cases where promises have multiple concurrent outcomes.

Then I got to your question:

Now you see those mog(0644, root, root) and mog(0755, root, root) is there any way to make that configurable other than adding them to the bundle's parameters?

They could be variables instead of values there, then the variables they use could hinge on different contexts, but for what you are doing here, parameters would probably be what you are looking for.

It seems like you should be able to set the attribute based on a variable (you can do this for usebundle values), but it doesn't work, the agent complains about the unresolved variable being undefined.

body perms open
{
      mode => "666";
}
body perms closed
{
      mode => "444";
}
bundle agent __main__
{

  methods:
      "My file 1"
        usebundle => my_bundle( "/tmp/file1.txt", "open" );

      "My file 2"
        usebundle => my_bundle( "/tmp/file2.txt", "closed" );
}
bundle agent my_bundle( file, perms_body_name )
{
  files:
      "$(file)"
        content => "$(file) perms body $(perms_body_name)",
        perms => $(perms_body_name);

}

I thought that you might be able to do some dynamic inheritance, but no, that doesn't work either.

body perms open
{
      mode => "666";
}
body perms closed
{
      mode => "444";
}
body perms use_body( body_name )
{
      inherit_from => "$(body_name)";
}
bundle agent __main__
{

  methods:
      "My file 1"
        usebundle => my_bundle( "/tmp/file1.txt", "open" );

      "My file 2"
        usebundle => my_bundle( "/tmp/file2.txt", "closed" );
}
bundle agent my_bundle( file, perms_body_name )
{
  files:
      "$(file)"
        content => "$(file) perms body $(perms_body_name)",
        perms => use_body( $(perms_body_name) );

}

Or should I make a prototype like: bundle agent sync_cp_annotated_files(files,from,to,pattern, mogfile, mogdir) and then use them as perms => $ (mogfile); (if that works at all)

I wondered about that as well, but no, it seems like you can't do dynamic body names. It complains if it's quoted and it complains about not being defined if it's not quoted.

[miekg]

Thanks for your comment Nick. I missed the /. and only saw the / so thanks for pointing that out.

The comment about classes is on point. I'm afraid 100% of our policies look like that... so that will take a while to convert. (note: our repo was converted from cfengine2, and it probably more than 30y old. Our git repo "only" goes back to 2011).

Thanks for answering my question. I probably go for multiple version of this and add rdcp variant or something, not super elegant but it may be enough.

[miekg]

closing this, because per my question and ensuing discussion this does not seem possible.

Thanks all!