I apparently use a different sudo module than you do (saz/sudo), but have
the same concerns. We have a general sudoers setup that gets applied to all
nodes and additional config for certain roles. We manage this in the base
profile class using iteration (note: I don't think I guard against
`$sudo_confs` actually being undef, which may cause catalog compilation
failures if it occurred):
class profile::base::linux (
$sudo_confs = undef,
) {
...
# Sudo setup
include ::sudo
$sudo_confs.each |$group, $config| {
sudo::conf{ $group:
* => $config,
}
}
}
In hiera/global.yaml:
---
lookup_options:
profile::base::linux::sudo_confs:
merge: deep
profile::base::linux::sudo_confs:
sysadmin:
priority: 10
content: '%sysadmin ALL=(ALL) ALL'
The `lookup_options` ensures that the content is found and merged across
hiera tiers rather than overwriting at each level. Then we can do things
like this in hiera/puppet_role/build.yaml, for a 'build' role:
---
profile::base::linux::sudo_confs:
infrastructure:
priority: 15
content: '%infrastructure ALL=(ALL) ALL'
On almost every node, profile::base::linux::sudo_confs has a single key
'sysadmin'. On nodes with the `puppet_role` fact set to `build`, there's a
second key, `infrastructure`, and thus a second sudo configuration is
applied on those nodes. You can also look at the `knockout_prefix` key for
`lookup_options` if you decide you need to eliminate some keys on certain
nodes.
On Friday, January 27, 2017 at 3:47:58 AM UTC-5, Robert wrote:
>
> Hi List,
>
> I'm on the verge of refactoring all our modules to the roles&profile
> workflow with r10k etc. and the stuff is taking shape - thanks for all the
> help so far! - and the only thing I'm still not very convenient with is the
> naming/grouping of data put into Hiera and using that data in the profiles.
> Let me explain.
> Somehow I always wanted to do something like this:
>
> ---
> profile::tomcat::sudoers:
> tomcatadmingroup:
> - systemctl start tomcat.service
> - systemctl stop tomcat.service
> profile::apache::sudoers
> apacheadmingroup:
> - systemctl start httpd.service
> - systemctl stop httpd.service
>
> since if I classify a node with the Tomcat module, I'd like the tomcat
> admins to be able to start and stop the service. I think this resource
> belongs to the profile::tomcat. This way, I'd use:
> profiles::tomcat {
> ...
> class { "sudoers":
> sudoers => $::profiles::tomcat::sudoers
> }
> }
>
> profiles::apache {
> ...
> class { "sudoers":
> sudoers =>$::profiles::apache::sudoers
> }
> }
>
> This is (imho) way nicer than trying to remember to extend all these
> resources every time I need something new, like "Tomcat needs a port, a
> user, a certificate so let's extend profile::firewall with the port,
> profile::certs with the cert. Ah crap I forgot the java version in
> profiles::java at the bottom of the yaml file!".
>
> But this solution obviously doesn't work if a node has both the tomcat and
> apache modules because of the multiple resource-like class declarations of
> the same class.
>
> Another example would be that if the tomcat module is assigned to a node,
> then the tomcat-admins should be able to login via ssh. And the same goes
> for other admin groups. Assuming this:
>
> profiles::tomcat::pamd:
> - 'tomcatadmins'
> profiles::oracle::pamd:
> - 'oracleadmins'
>
> the final variable used in the pamd class should be ["tomcatadmins",
> "oracleadmins"] but I can't really get this array in the pamd profile with
> hiera (or can I?).
>
> Maybe some merging would be possible but I can't simply look up
> "profile::*::pamd" and merge the results.
> Afaik hiera_array is only possible with data on different Hiera levels.
> I could use subclasses like ::sudoers::tomcat, ::sudoers::apache...
> ::pamd::oracle ::pamd::tomcat etc. but that'd be complex and time-consuming.
>
> How could I (meaningfully) use "include ::classname" everywhere without
> doing something weird?
> How do you group your data?
>
> Best
> Rp
>
>
>
--
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/8a068b3a-22aa-493f-8ec7-1c5396bfea95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
