Thanks Ygor. I've played around with create_resources a bit since you
posted this and things are looking promising. I think this is the way to go.
Regards,
Guy
On Friday, 6 December 2013 18:22:10 UTC-8, Ygor wrote:
>
> 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<javascript:>>
> 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/5cb298d6-5abb-4633-9bcb-d7a71704cdec%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
