Closed michaelweiser closed 8 years ago
Hi
in general I like your Idea, although I haven't yet looked into it in detail. But I was already thinking a couple of times how this could be achieved and I like your idea, but I'd like to reflect a bit more on it.
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!
Could you have a look at cbd411b919cf7e75966ad13ffc5e654b51c8d207 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 trocla.password()
, as this might not be expected and I'm not sure if we actually need that and hence should just stick with the normal hiera lookup behavior.
Well, it certainly looks a lot more elegant now and seems to work just fine after applying https://github.com/duritong/puppet-trocla/pull/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:
hiera.yaml
:
:hierarchy:
- "osfamily/%{::osfamily}"
- dmz
- common
common.yaml
:
service_pwd: "%{hiera('trocla::password::service_pwd')}"
trocla::options::service_pwd::format: 'plain'
trocla::options::service_pwd::options:
length: '16'
dmz.yaml
:
trocla::options::service_pwd::options:
length: '32'
osfamily/Debian.yaml
:
trocla::options::service_pwd::options:
charset: 'shellsafe'
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 functionshiera
andscope
are 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::. Looks up
additional parameters via hiera itself as
trocla::options::<trocla_key>::format
(string) andtrocla::options::<trocla_key>::options
(hash). Looks for<trocla_key>
in trocla ashiera/<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:
example usage in hiera yaml file: