OK. Now that I have had a chance to look at the torrancew/account module, I
can make some (I hope) helpful suggestions:
My own user-account class implementation (class users) is very similar with the
following exceptions:
I have a base-user-account defined type that creates users.
I use it two ways: one way for basic users, and a second way for sysadmin users
(adding group “wheel”)
Each of these are called up like this:
$admin_accounts = hiera_hash ('sysadmin', false)
if $admin_accounts {
create_resources ( users::useraccount, $admin_accounts )
}
$developer_accounts = hiera_hash (‘developers', false)
if $admin_accounts {
create_resources ( users::useraccount, $developer_accounts )
}
Part of the “magic” of my design is one of the default values for the defined
type:
define users::useraccount (
$username = $name,
...
$ensure = absent,
)
Now for the hiera :
Here’s my /etc/puppet/hiera.yaml (simplified a bit):
---
:hierarchy:
- %{fqdn}/%{module_name}
- %{module_name}
- %{fqdn}
- common
:backends:
- yaml
:yaml:
:datadir: '/etc/puppet/hieradata'
:merge_behavior: deeper
# vim: ft=yaml:sts=2:sw=2:et
So it works like this:
In /etc/puppet/hieradata/users.yaml, I define all the users for the entire
network
——-
#
# set “ensure: present” for sysadmins because they need a login on all systems
#
sysadmin:
smithj:
uid : 5001
comment : Smith, Joe, x1234
groups :
- wheel
ensure : present
jonesf:
uid : 5002
comment : Jones, Fred, x2345
groups :
- wheel
ensure : present
#
# All we need here is name, uid, and comment-info
#
developers:
smitht:
uid : 6001
comment : Smith, Tom, x2234
jonesc:
uid : 6002
comment : Jones, Cynthia, x9345
Now for the “deep” magic: /etc/puppet/hieradata/host1.example.com/users.yaml, I
specify the non-admin users who need a login:
——-
developers:
smitht:
ensure : present
groups :
- webdev
The neat thing is that you can add host-specifics to the user account - like
extra groups
Does that help ?
This is about a quarter of the tricks I came up with in my users module.
Other junk includes :
role accounts and restricted ssh logins (“from” and “command” options in the
${role_account_home}/.ssh/authorized_keys file)
A way to keep the ssh keys out of the hiera-data to keep the files human
readable
This is my response to the "Unpleasant puppetlabs experience” Thread. I am
happy to share what I have tinkered together.
On Dec 6, 2013, at 5:23 PM, Guy Knights <g...@eastsidegamestudio.com> wrote:
> We're working on implementing hiera with our puppet 3 setup, and I'm curious
> if the following is achievable. Currently, we manage each user account within
> a class that realises a defined resource that creates the user, groups, etc
> (for the record, we use the torrancew/account module). We then have classes
> called groups::<group name> where we pull in all the user classes we want in
> a specific manifest.
>
> What I would like to do is move all the user info into hiera, and thus move
> from 'groups' as we currently define them, to user accounts created according
> to their position in the hierarchy. Unfortunately, I'm having trouble working
> out how to do this. I could set up a hash within hiera and then use the
> account module to create users from this hash, but I don't think it's
> possible to create a batch of resources with differing attributes (primarily
> the ssh key, but possibly others) using one resource.
>
> I don't really want to have to pull all the resource setup out of the account
> module since it makes things simpler for us, is there any other way to get
> the result I'm after?
>
> Thanks,
> Guy
--
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/5121DC45-940E-475A-98CC-4E36B948BD48%40comcast.net.
For more options, visit https://groups.google.com/groups/opt_out.
