the variable does indeed need canonification
when writing the technique, we (actually I) had the weird assumption that - were not allowed in login
And that's slated for next point release? Very nice. :)
Just waking up. :)
I'm coming from having knowledge with cfengine1/2, puppet, saltstack, chef, ansible, and now, looking at rudder to replace my current saltstack implementation.
And, my first task, to begin making this possible, is to create techniques/directives to setup a usable CFSSL Certificate Authority that will be used to generate and maintain an internal CA for things like Consul & Vault LOL
Which saltstack's x509 module has been completely broken of this for going on 2 years now. :/
We really only use CFEngine as an agent platform for the configuration we generate, and Rudder has very different workflows and configuration modelization so the CFEngine layer should be pretty transparent for the users. For the next major release (7.0) we're working on our own DSL that will make this even more visible: we'll have a high-level configuration language that will be compiled/transpiled for different configuration backends (for now, CFEngine and Windows DSC). This way we'll continue to benefit from CFEngine strengths (lightweight and portable) while providing a flexible and consistent interface, with improved static checks for reliability.
Hmmmm.. What I'm trying to figure out now is how to simply... create a file, like at the moment, a static systemd service unit file, then after that a configuration file that's templated. And I notice in Techniques, File from template with type, needs a source file on the target node?!?
Yeah, Alexis. It's pretty ingenious really, Utilize what's viable and available, while making your own interfacing to make a standard construct, mostly similar and sane.
I hated cfengine, but it has/had its place in the world as pretty much the first config management system in Unix & Linux.
Methods are low-level building blocks, and templating indeed takes a local source file that you have to deploy somehow. There is one built-in way for files belonging to a technique: technique resources. Any file added as a resource is deployed on all nodes where it is applied to, and the resource has a special variable containing its local path, that you can use in the technique.
I’m creating a Technique to install, configure, and deploy cfssl, service unit to run the multirootca service, and create and check the root CA and Intermediate CA for use in cfssl automation.
Which will be used to have the Consul certificates on every server maintained and updated appropriately.
If I can get all that to work, AND get at least Consul similarly installed and working with templated automated configurations, then I will be pretty well sold on Rudder. :)
So templated Files would either be deployed by one of the methods?
- Static file direct to node, then processed as template.
- shared-files (all servers get) and processed as template.
Something like that?
Template files can be:
- A technique resource that is automatically deployed everywhere the technique is applied. You can directly use the templating method with the
${resources_dir}/RESOURCE_NAMEas source - A file in the global shared-files, in this case you nee to use a File from Rudder server method to download it to a tmp location in the technique before appplying the templating method with the tmp path as source
- If it's very short and simple, you could even use the File content method that allows specifying the file content directly in the Web interface, in the method form. Then you can use the templating method over the target file of the File content method
Of course, the next viable question is. How does one... Actually develop and maintain this not just via the webUI, but versioned in one's own git repo, or at least... backed up in some way.
Yeah, in the /var/rudder/configuration-repository. Very nice!
So, yeah, I can easily automate the process of backing this up too, to my borgbackup repostory on a regular basis.
(and can you actually use ${resources_dir} in the source in the technique?
it's
/var/rudder/cfengine-community/inputs/TECHNIQUE_ID/resources on the nodes
2020-10-30T16:12:59+00:00 error: The promised column edit '#+\s*config\s*=.*' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised column edit 'config\s*=.*' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised line insertion 'config=/var/lib/cfssl/certs/config.json' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised column edit '#+\s*config\s*=.*' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised column edit 'config\s*=.*' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised line insertion 'config=/var/lib/cfssl/certs/config.json' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised column edit '#+\s*config\s*=.*' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised column edit 'config\s*=.*' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
2020-10-30T16:12:59+00:00 error: The promised line insertion 'config=/var/lib/cfssl/certs/config.json' could not select an edit region in '/var/lib/cfssl/server/multiroot-profile.ini'
E| compliant CFSSL File key-value in INI se| /var/lib/cfssl/se| Set line key=value in section default into /var/lib/cfssl/server/multiroot-profile.ini was correct