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+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/8e5cfb5e-9146-4c7d-8079-68075f8cbaa1%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
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 <guy@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+unsubscribe@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.
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+unsubscribe@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.