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/790fcc0c-2a75-75ca-b8cb-302cc6caf5f6%40bardicgrove.org.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
