-
-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes bug in the latest push from PR #102, that doesn't use the _keysdir path when creating keys #110
Conversation
The build is failing ...but it looks like it was also failing in #102 as well..... |
@hunner: i'm not familiar with RuboCop but i'll try to google to see if I can fix the error. |
Thanks, looking into it. Yeah, don't know why rubocop is failing :( |
@@ -186,7 +186,7 @@ The following parameters are available for the hiera class: | |||
This is useful for configuring backend-specific parameters. | |||
Default: `''` | |||
* `keysdir` | |||
Directory for hiera to manage for eyaml keys. | |||
Directory for hiera to manage for eyaml keys. This is the path where /keys should be managed not the full path to the /keys directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smbambling I was also thinking that the hiera::keysdir
parameter would be the full path to keys/, like keysdir => /etc/puppet/eyaml_keys
or whatever. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be...
where it bites you as you would need to munge that into a new variable to use with
exec { 'createkeys':
user => $owner, user => $owner,
cwd => $confdir, + cwd => $keysdir,
I was also trying to keep with the pattern used for _keysdir in init.pp
Made this more generic so that keysdir is full path. |
Fixes bug in the latest push from PR #102, that doesn't use the _keysdir path when creating keys
PR #102 caused a bug that did not obey the _keysdir parameter when creating keys. It only created them in $confdir/keys...which caused a failure if a different path was used.