Add custom hiera backend for trocla#15
Add custom hiera backend for trocla#15duritong merged 1 commit intoduritong:masterfrom michaelweiser:qr1
Conversation
Only reacts to key namespace trocla::password::<trocla_key>. Looks up
additional parameters via hiera itself as
trocla::options::<trocla_key>::format (string) and
trocla::options::<trocla_key>::options (hash). Looks for <trocla_key> in
trocla as hiera/<source>/<trocla> with <source> iterating over the
configured hiera hierarchy. If not found, creates and returns a new
password with trocla key <trocla_key>.
example entry in hiera.yaml:
backends:
- ...
- trocla
trocla:
- configfile: /etc/puppet/troclarc.yaml
- format: plain
- options:
length: 16
example usage in hiera yaml file:
kerberos::kdc_database_password: "%{hiera('trocla::password::kdc_database_password')}"
trocla::options::kdc_database_password::format: 'plain'
trocla::options::kdc_database_password::options:
length: '71'
|
Hi in general I like your Idea, although I haven't yet looked into it in detail. Nevertheless, I really appreciate this PR! Thanks a lot! |
|
I like it, I guess I will do a few optimizations, but in general I'm fine. Thanks a lot! |
Add custom hiera backend for trocla
|
Could you have a look at cbd411b and tell me whether it still works and what you think off. The only thing left is whether we should hash-merge the options on the |
|
Well, it certainly looks a lot more elegant now and seems to work just fine after applying #16. As for hash merge vs. priority first lookups: I'm a total sucker for hash merges because I like the flexibity and conciseness (non-redundancy) in spite of the potential for occasional confusion due to unexpected interactions or precedence. An adminttedly constructed but IMO quite conceivable real world example: I need a password with length 16 chars on standard systems (so I have a slight chance of remembering them) but 32 chars for those in the DMZ (because some policy says so). I also need it to be shellsafe on Debian boxes because their funky default of /bin/sh being dash instead of bash lets all hell break loose otherwise:
|
|
I'm also fine with the hash_merge behavior and use it a lot. Experience just tell me, that a lot of people struggle with grasping the concept behind it. let's leave it like that for now. |
I wrote a custom hiera backend for trocla. Would you be interested in it?
I made some design decisions open for discussion:
This means that password creation has to be triggered via explicit hiera function interpolation lookups such as:
kerberos::kdc_database_password: "%{hiera('trocla::password::kdc_database_password')}"I looked into just adding a
"%{trocla('<key>')}"function but there's no API for that and the existing functionshieraandscopeare pretty hard-coded in the hiera source. Getting trocla-support in there without adding a whole extension function API is unlikely.hiera/<source>/<trocla_key>. This way, the same trocla key could yield different passwords for different groups of machines. I'm not sure, how much use this would actually be in practice. Also, that key would need to be initialised externally, e.g by callingtrocla('hiera/osfamily/Debian/jessie/root'in site.pp. Alternatively we could use hiera's concept of datafiles to look into different trocla password stores. But this would need somehow providing different troclarcs as well.Only reacts to key namespace trocla::password::<trocla_key>. Looks up
additional parameters via hiera itself as
trocla::options::<trocla_key>::format(string) andtrocla::options::<trocla_key>::options(hash). Looks for<trocla_key>introcla as
hiera/<source>/<trocla>with<source>iterating over theconfigured hiera hierarchy. If not found, creates and returns a new
password with trocla key
<trocla_key>.example entry in hiera.yaml:
example usage in hiera yaml file: