Conventions for stagng imported templates?

[t.d...@servicemusic.org.uk]

Executive summary: Are there any conventions or recommendations for where to stage "on-demand" templates that are imported and then expanded?

Background (site):  Our CFEngine hub serves a few thousand clients.  The version is quite old, and I'm refactoring our config to MPF (Masterfile Policy Framework), not least to enable us to upgrade to newer versions of the CFEngine code.  We have many templates and some lack of consistency in how we handle them, and this refactoring is an ideal time to review this template-handling.

Throughout my 15+ years with CFEngine at three different places, I've always noticed the apparent lack of a conventions about the staging of templates imported "on demand" from the hub.  (This is somewhat different from templates that may be an integral part of general policy (whether MPF or local) which would be naturally handled by "update.cf" in later CFEngine releases.  This is out of scope of the question here.)  The client unpacking and installation is a sequence of two files promises: (1) import to the local machine with secure_cp (or similar) to a staging area; (2) install from that staging area.

Are there any conventions or recommendations for where, locally, to stage the imported template?

One possibility is in the final directory.  So if the aim is to end up with "/etc/foo", then its template is staged to "/etc/foo.staged-template" (or similar).  But this makes the destination direction look a little untidy.

Another practice is a subdirectory of something like "/tmp/".  A possible downside is that "/tmp" files can be volatile, so long-term stable templates may need periodically re-fetching.

I'm wondering if there is a conventional or recommended place somewhere under "$(sys.workdir)" or similar for such a template-staging directory?  If there are such conventions, this would be a good time for our site to consider adopting them.

-- David Lee

[Aleksey Tsalolikhin]

Hi David,

Folks, correct me if I’m mistaken, but I don’t believe that there is a convention in this regard.

An aspect of CFengine culture is it gives you all the low level pieces And you have the freedom and flexibility to put it together into whatever you want.

What I have done in this case is I’ve copied the templates into dot-files (hidden files) which helps with the pain point you mentioned about the Destination directory looking cluttered.  That’s not a prescription, I’m just sharing what I did.  Example, .httpd.conf.template.

Best,

Aleksey

--
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-cfengine+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/e69e10ea-d2f7-4b46-8e7f-d98e937a9160n%40googlegroups.com.

--

-- 

Founder

Vertical Sysadmin, Inc.

Achieve real learning.

[Nick Anderson]

t.d…@servicemusic.org.uk writes:

Executive summary: Are there any conventions or recommendations for where to stage "on-demand" templates that are imported and then expanded?

Hi David,

In general, CFEngine doesn't try to prescribe very many things. I tend to leverage $(sys.statedir) for caching things. I guess I have a tendency to stage templates next to their final location, but probably sys.statedir would be a better choice since it's not uncommon that some apps would try to pick up and use any file in the same directory.

unpacking and installation is a sequence of two files promises: (1) import to the local machine with secure_cp (or similar) to a staging area; (2) install from that staging area.

I try to avoid this kind of thing in general, but perhaps you have good reasons for not having your templates copied as part of the update policy. Perhaps I mis-understood your original question. When I think about staging a file, I am rendering a config file to a temporary place, then validating that with something like apachectl configtest or visudo -c then promising the final location. Now I am thinking that you are talking about the templates themselves that you are copying locally to use for rendering. I still think sys.statedir is a reasonable place for this kind of thing. Perhaps it would be convenient to do something like $(sys.statedir)/templates/$(this.namespace)/$(this.bundle)/my-template.mustache.

Are there any conventions or recommendations for where, locally, to stage the imported template?

If not statedir (which is sometimes on a ramdisk), then $(sys.workdir)/templates/ also seems reasonable to me, but I don't know that it would be a widely used convention.

– Nick Anderson| Doer of Things | (+1) 785-550-1767 | https://northern.tech

[t.d...@servicemusic.org.uk]

Thanks, Nick.  Historically, which long predates Masterfiles Policy Framework (MPF),  we seem to have relatively few templates implemented in a "part of policy" manner, and many more as "pull on demand".  But in discussion about our proposed transition to MPF, my colleagues seem happy that we consider most (not quite all) to end up as "part of policy" (so under the aegis of "update.cf").  We can let such templates drift to this way of working over time. The important thing for now to establish (a) a clean "part of policy" (i.e. under "update.cf") way of working (b) a residual "on demand" way of working for a diminishing (but never to zero) set of them.  My question is about rationalising the latter (even though it is diminishing).

Your "sys.statedir" suggestion looks interesting.  I had always previously regarded that as CFEngine-internal only; your suggestion implies that it is perfectly acceptable also for site-local usage.

But thanks for confirming, along with Aleksey, that there seems to be no established convention (or centrally-appproved suggested or similar).

-- David Lee

.

[Aleksey Tsalolikhin]

>  [Nick Anderson's] "sys.statedir" suggestion looks interesting.  I had always previously regarded that as CFEngine-internal only; your suggestion implies that it is perfectly acceptable also for site-local usage. 

https://docs.cfengine.com/docs/3.15/reference-special-variables-sys.html#sys-statedir says:

sys.statedir

The name of the state directory where CFEngine looks for its embedded database files.

    # statedir = /var/cfengine/state

History: Introduced in CFEngine 3.7

So yes, it's intended for internal usage, but there is no reason you can't throw your site's files there too, as long as there is no name collision with CFEngine's database files.  I wouldn't put them at top level, just so sys.statedir doesn't get cluttered up -- like Nick suggested, use a templates/ directory, or make a site/ directory.   :)    /var/cfengine/state/acme or whatever.  ;)  In case you ever want to transfer something other than templates, maybe pull down a secret from the hub temporarily or something.

Best,

Aleksey

-- 

Founder

Vertical Sysadmin, Inc.

Achieve real learning.

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/b1973853-590c-47db-b238-a82c1a6f26ddn%40googlegroups.com.