Hi
I do not wish for my juniors to need to learn Puppet at all:-) Hint:
They work in support center and mostly on windows.
We think we can expand our hiera hierarchy like this to achieve
separation in a non-complicated way:
:hierarchy:
- "customers/%{::domain}/%{::hostname}"
- "customers/%{::domain}/common"
- "roles/%{::role}" #new line
- "os/%{::osfamily}/common"
- common
Does this seem like a good way to do this?
I have read about Puppet Lookup [1] and see that this also might solve
this for us. When can we expect it to be stable?
Bjørge
[1] https://docs.puppet.com/puppet/latest/reference/lookup_quick_module.html
On 03. nov. 2016 15:49, Andrew Grimberg wrote:
Sounds like you could use a little code-review process (such as Gerrit)
managing the hiera repo. That coupled with something like
hiera-eyaml-gpg (or similar) would allow you to have your junior admins
submit changes for review allowing such hiera configs to be worked on by
multiple parties and still have any sensitive data kept from folks that
shouldn't have it.
As for configurations like you're talking about here, my team doesn't do
any sort of direct class or configuration calls. We rely on having
modules for managing everything. In this case we're using saz/ssh and
our ssh profile, which is included in the base config for all nodes,
just does an 'include ::ssh'. It also then pulls in the hiera
configuration and takes care of opening firewall ports and configuring
monitoring as appropriate.
This way, we set our standard ssh configuration up at our common hiera
base layer and any special system tweaks are just at the node specific
layer in our hiera.
On 11/03/2016 06:59 AM, Bjørge Solli wrote:
Hi Rob, thanks for your reply.
The main defaults is for every host (all customers, datacenters, etc),
but some, like a jump-host or managed-file-transfer-host, will need to
have different values. Doing this in hiera is fine for those who are
allowed to edit hiera, but setting up machines for new customers are
often done by juniors that only set the role in the provisioning system
and will have to contact a senior to get something added to hiera.
Adding defaults to hiera also makes the code less portable.
I could do something like this in the base-sshd (pseudo-code):
if $role = 'foo'; then use foo-specific values, else use default.
But I really think code belonging to the profile for jump-hosts should
be set in the corresponding profile, not as an exception in the base setup.
Lets say this is my current code in base-sshd-profile:
#Using herculesteam/augeasproviders_ssh
sshd_config { 'ConfigVariable':
value => 'no',
} #Code for overwriting this in hiera is omitted
Now I would like to change this same value for some roles, preferably
without doing changes in hiera manually for each host having this role.
Bjørge
On 03. nov. 2016 14:19, Rob Nelson wrote:
You mentioned that a specific role would like a different value, but
is there another logical division between the two configs? Perhaps
per-datacenter, or per-network, or some other differentiator? At a
worst case scenario, per individual node? You could add whatever that
differentiator is to your hiera hierarchy, if it isn't there already,
and keep your more common settings toward the bottom of the hierarchy
(perhaps even in the global/common/default tier) and the exceptions
higher up. If that sounds reasonable, then we could look at your code
and see how to separate the data appropriately.
Rob Nelson
rnels...@gmail.com <mailto:rnels...@gmail.com>
On Thu, Nov 3, 2016 at 9:11 AM, Bjørge Solli <bjorge.so...@gmail.com
<mailto:bjorge.so...@gmail.com>> wrote:
Hi
Setup: Puppet 4, profiles and roles, hiera
Trying to understand what is the best way to solve this problem:
I have a base-profile that includes default setup of sshd. The
sshd-profile sets up sane defaults, reads specific setups from
hiera and uses separate resources to manage each setting in the
sshd_config-file. But now some other profile would like to have a
different default value in one of the sshd-settings, resulting in
a conflict.
I understand using 'defined()' is discouraged and has it's
limitations, and those stating this says there are 'plenty of ways
to get around this', but I could find none.
I am willing to rewrite how I do this entirely if it makes my wish
to keep working defaults in profiles, with no need to overwrite
with hiera unless it is system specific.
Any tips, hints, websites, etc. welcome!
Regards,
Bjørge
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to puppet-users+unsubscr...@googlegroups.com
<mailto:puppet-users%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/3b68e251-eb42-4fab-9409-6c64e607eb25%40gmail.com
<https://groups.google.com/d/msgid/puppet-users/3b68e251-eb42-4fab-9409-6c64e607eb25%40gmail.com>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com
<mailto:puppet-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAC76iT84yb_aoKyXO-FkMKcmHuuf-wNMbW6HjSTSyxZOmbN%2BFA%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-users/CAC76iT84yb_aoKyXO-FkMKcmHuuf-wNMbW6HjSTSyxZOmbN%2BFA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com
<mailto:puppet-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/e8b1b63d-a8c0-3cae-f721-7407d05f4352%40gmail.com
<https://groups.google.com/d/msgid/puppet-users/e8b1b63d-a8c0-3cae-f721-7407d05f4352%40gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/70b522d7-1b71-076c-5e1f-69b31f2eb5d9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
