Add Feature to manage entries in csr_attributes.yml

[lbetz]

I'd like to manage entries in csr_attribiets. The file has to be managed before the first openvox run so that feature should be implemented directly after the installation of the packages. But I've no idea for the best way to submit data structures like yaml to a shell script?

Any ideas?

[jpartlow]

Hi @lbetz,

What's the method you currently use to setup csr_attributes.yaml? And on what platforms?

[lbetz]

Moin @jpartlow,I use terraform for deployment. To install the openvox agent still at the time a self written (theforeman/puppet-puppet#938) bolt task. To solve the ordering problem of writing csr_attributes file and the first puppet run, the task doesn't start the daemon. That is done after storing the file via the a bolt plan and setting the daemon into state running. Currently, so I deploy test environments for development and testing of puppet modules for debian, ubuntu, sles and EL for all supported version.

[jpartlow]

I see, makes sense. I think there are two basic ways to handle this.

1. Add parameters to current install task and handle them awkwardly in bash.
2. Write a separate ruby task running /opt/puppetlabs/puppet/bin/ruby to be run after the install task.

I'm leaning towards 2 just to avoid bloating the shell scripts with additional code particularly since we can't rely on the presence of tools like yq and jq and I try to avoid stabbing myself with sed and awk when I can :). Also there are two install tasks, one based on collections and package managers and one that downloads directly from artifacts, although they'd both just be calling functions in files/common.sh, so it wouldn't mater much beyond their needing additional parameters. The tasks can install packages other than openvox-agent though, so additional parameters specific to openvox-agent config are a touch odd.

Actually, there's probably a 3, which would be basically 2, but also include the ruby file with the install tasks, and let them hand off to the ruby task if package=openvox-agent and config options were passed.

Well, let's start with 2. It fits your use case in that you'd just plug in a second task call in your plan, and it's easy enough to come back later and plumb config into the openvox_bootstrap install tasks if desired, or even add separate install_and_configure tasks specific to openvox-agent since the functionality is all in common.sh. Or an install_and_configure plan.

The other question is what to manage:

• Hash of puppet.conf config
• Hash of csr_attributes
• The puppetserver CA cert (if you wanted to close that security loop for initial puppetserver verification)
• puppet service enable state
• puppet service running state

So a params.json for this openvox_bootstrap::configure task might look something like:

{
  "puppet_conf": {
     "main": {
        "server": "puppetserver.foo"
     }
  },
  "csr_attributes": {
     "custom_attributes": {
        "1.2.840.113549.1.9.7": "password"
     },
     "extension_requests": {
        "pp_uuid": "tomato"
     }
  },
  "puppet_service_running": true,
  "puppet_service_enabled": true
}

I'll take a stab at this; I think this part should be pretty straight forward. Let me know what problems you see.

Last note: I don't have sles support yet. It's on the roadmap, but I'm going to finish up the main acceptance suite work for openvoxdb and probably openfact before I come back and expand the core platform support here in bootstrap.

[jpartlow]

Actually, I'm forgetting that the pem linebreaks will break the json. Handling the ca.pem is probably better left to a plan, so I'll worry about that at a later date.