targeting a specific system with a bundle

[Arne Hoffmann]

Hello,

I am unclear on how to apply a bundle to a single system (or a group of
systems). Let's say a have a large number of system, but only two
nameservers: ns1.example.com and ns2.example.com. How do I tell cfengine
that the bundle "nameserver" should only be applied to ns1 and ns1?

I know that I can include the class expression ns1_example_com:: in every
promise in my bundle "nameserver", but that doesn't seem to be very elegant.

Ideally I would have cf-agent read a list of bundle names from a file (or a
database) that are to be applied to the system it is running on. Is there a
way to do that?



Regards,
Arne

[Sean Johnson]

I think using methods or autorun is a good approach:

-----
classes:
"nameservers" or => { classmatch("ns1"), classmatch("ns2") };

methods:
any::
"system_config" usebundle => system;
nameservers::
"nameserver_config" usebundle => nameserver;
-----

With autorun, the class can be put as a constraint on the autorun tag.

-----
bundle agent nameserver
{
meta:
nameservers::
"tags" slist => { "autorun" };
.....
}
-----

Hope that helps. :)

Cheers,

sean

> --
> You received this message because you are subscribed to the Google Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
> To post to this group, send email to help-c...@googlegroups.com.
> Visit this group at https://groups.google.com/group/help-cfengine.
> For more options, visit https://groups.google.com/d/optout.

[Arne Hoffmann]

Sean Johnson wrote:
> I think using methods or autorun is a good approach:

OK, both methods and meta promises are new to me (still a cfengine newbie).

> methods:
> any::
> "system_config" usebundle => system;
> nameservers::
> "nameserver_config" usebundle => nameserver;

Nice.

I just wrote a bundle "default" that lists all the bundles for specific
systems or groups of systems. Did exactly what is was supposed to do.

Are there conventions about naming such a bundle? Or any kind of best
practices? I like to stick to those in the beginning.

> With autorun, the class can be put as a constraint on the autorun tag.

Still need to read and understand the docs on meta promises.


> Hope that helps. :)

It did. Thanks!



Regards,
Arne

[Marco Marongiu]

Hi Arne

I get from your question that you are using exclusively the
bundlesequence to decide what bundles should run. However, for your case
is kind of suboptimal and Sean has already suggested a different
solution (autorun). There is some info on cfengine.com itself:
https://cfengine.com/company/blog-detail/dynamic-bundlesequence-with-autorun-meta-tags-and-hard-classes/

Another solution would be dynamic bundles, the ancestor of autorun. Neil
Watson wrote about that in 2011:
http://watson-wilson.ca/blog/2011/09/16/cfengine-dynamic-bundlesequence/

What I usually do is to call a very few bundles from the bundlesequence,
and have a "main" bundle which contains primarily methods promises,
where each of them (or small groups of them) are conditioned by classes,
e.g.:

bundle agent main
{
methods:
class_condition_1::
"do this"
usebundle => this_bundle ;

class_condition_2::
"do that"
usebundle => that_bundle ;

...and so on and so forth.

For setting classes dynamically, depending on a number of different
conditions, I use hENC: https://github.com/brontolinux/hENC

hENC allows you to set classes and variables by reading one or more of
files, where the list of files to be read is built dynamically inside
the policies, hence adapting the execution of the policy to the
particular system. Where two files contain conflicting settings (e.g. a
variable is set to 1 in the first file and to 5 in another one), the
last file wins.

So you have plenty of solutions depending on how complex is the problem
you are trying to solve. Pick up the one that fits you best and... Good
luck ;-)

Ciao
-- bronto

[Sean Johnson]

> Are there conventions about naming such a bundle? Or any kind of best
> practices? I like to stick to those in the beginning.

Like most naming conventions, the best one is the one that makes the most sense to you and others that you're sharing the space with. In a generic sense, I try to keep bundle names both as concise and descriptive as possible. One of my litmus tests is if either I can come back around to it months later and still understand what the bundle is supposed to accomplish based on its name.

Also, don't fall into the trap of feeling like once bundle names are set that they can never be changed. Yes, it can be a little bit of a pain depending on how scattered the names become, but sometimes the naming convention that works best for you doesn't become apparent until you've gone through a few iterations. At least, that's been my experience. :)

Cheers,

sean

[Nick Anderson]

On Saturday, September 30, 2017 at 8:36:09 AM UTC-5, Sean Johnson wrote:

Also, don't fall into the trap of feeling like once bundle names are set that they can never be changed. Yes, it can be a little bit of a pain depending on how scattered the names become, but sometimes the naming convention that works best for you doesn't become apparent until you've gone through a few iterations. At least, that's been my experience. :)

Yes, don't fear refactoring. If you fear cleaning up names for breaking things you will dig your self a deeper hole that will be more confusing for your future self and those that follow you. 

[Bas van der Vlies]

As Marco managed their are several solutions. I am using another setup for def.json. In this file I define the variables and classes, see presentation at Ghent:
* http://cfgmgmtcamp.eu/schedule/cfengine/augments-def-json-bas-van-der-vlies.html

The spin of is the cf_surfsara_lib to generate template files via moustache/json:
* https://github.com/basvandervlies/cf_surfsara_lib

[mike.w...@verticalsysadmin.com]

Seconded.  Also, this is why you should use a good version control system.  :)  GitLab Community Edition is free, open source, easy to set up and a tremendous power tool.  There are other tools, too—if you're not using any VCS, pick one, quick!

I can't imagine handling a large refactor without breaking things in absence of a tool like Git.  And I can't imagine productively collaborating on a large codebase without a tool like GitLab.

Just my $0.02.

Best,

—Mike Weilgart

Vertical Sysadmin, Inc.

--

Need training on CFEngine, Bash or GitLab?  Email trai...@verticalsysadmin.com.