added provisioning of file-based keystores via hiera

[dalisch]

Added mechanism to automate provisioning of password and public keys for file-based keystorage in rundeck::config::global::file_keystore, with key data provided via hiera.

Example of key data hash:

 {
   $key1 => {
      $value        => 'secret',
      $path         => 'myproject/passwords',
      $data_type    => 'password',
      $content_type => 'application/x-rundeck-data-password', },
   $key2 => {
      $value        => 'ssh-rsa Th1sIsn0tRe@alLyAnRSAk3y',
      $path         => 'myproject/pubkeys',
      $data_type    => 'public-key',
      $content_type => 'application/pgp-keys', },
}

[dalisch]

@liamjbennett @jyaworski , any concerns over not merging this into master?

[jyaworski]

Hello.

What's the advantage of this over the other open PR for this?

I'm traveling right now, so I can't properly review this.

On Feb 10, 2016, at 6:02 PM, dalisch notifications@github.com wrote:

@liamjbennett @jyaworski , any concerns over not merging this into master?

—
Reply to this email directly or view it on GitHub.

[dalisch]

Hi @jyaworski - if you're referring to #167, that PR seems to allow you to specify the kind of backend keystore used by Rundeck, either file or DB. This PR specifically refers to file-based keystores only, however it allows you actually provide and configure the keys themselves via hiera. From what I can see, they address different problems and don't add any overlapping functionality.

[jyaworski]

@dalisch so I didn't look at this 100% closely. I had to make some changes to #167 to account for strict variables. Also, is setting the defaults to be a command causing this to run repeatedly? Why not something like fqdn_rand with a seed?

[dalisch]

Hi @jyaworski

When you say "setting the default to be a command", if you're referring to:

  $content_creation_time = chomp(generate('/bin/date', '+%Y-%m-%dT%H:%M:%SZ')),
  $content_modify_time = chomp(generate('/bin/date', '+%Y-%m-%dT%H:%M:%SZ')),

...then the answer is no, it won't run repeatedly (ie: the affected resources are idempotent), because the files are managed with 'replace => false', such as:

  file { "${meta_fqpath}/${name}.${data_type}":
    content => $value,
    require => Exec["create ${path}_${name} meta path"],
    replace => false,
  }

'replace => false' was put there specifically for the reason you stated (ie: idempotency). This also means that you can't change the configuration via hieradata once the key is initialized, but the primary value of the workflow is spinning up a new rundeck server from scratch without having to manually add the keys.

[jyaworski]

I didn't see the replace. All right, all is well.