First thing I did was created a Technique to manage a user. But, then I added a Directive for managing a ssh-key for the same user, but I get errors on that as if the user doesn't exist (but they do)
The user exists... But, that technique always fails claiming the user doesn't exist, yet it does.
E| compliant Common ncf Initialization Configuration library initialization was correct
E| repaired Common Update Policy or configuration library were updated
E| compliant Common Security parameters The internal environment security is acceptable
E| compliant Common CRON Daemon Cron daemon status was correct
E| compliant Common Log system for reports Reports forwarding to policy server was correct
E| compliant Inventory inventory Next inventory scheduled between 00:00 and 06:00
E| error sshKeyDistribution SSH key Primary Key The user psi-jack does NOT exist on this machine, not adding SSH key
E| error sshKeyDistribution SSH key Primary Key The user psi-jack does NOT exist on this machine, and the SSH key format is wrong
E| compliant userGroupManagement Users psi-jack The user psi-jack ( Eric Renfro ) is already present on the system
E| compliant userGroupManagement Password psi-jack The user psi-jack ( Eric Renfro ) password change is not required
E| n/a userGroupManagement Home directory psi-jack The user psi-jack doesn't need to have its home directory checked
E| error sshKeyDistribution Flush SSH file Primary Key The user psi-jack does not exists on this system, impossible to flush keys
E| error sshKeyDistribution Flush SSH file Primary Key The user psi-jack does not exists on this system
A| non-compliant sshKeyDistribution Flush SSH file Primary Key The user psi-jack does not exists on this system
E| error sshKeyDistribution Flush SSH file Primary Key The user psi-jack does not have a defined home dir
A| non-compliant sshKeyDistribution Flush SSH file Primary Key The user psi-jack does not have a defined home dir
E| n/a Common Monitoring No Rudder monitoring information to share with the server
So it seems to not like the dash (-) in the username. LOL
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. :)
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?