Hi, I have found when working with user accounts it is very beneficial to create a defined type that allows you to wrap alot of functionality into one definition, thus reducing manual work and being more explicit with your requirements for user data and account configuration when they are defined as being present or absent.
The Puppet documentation about defined types can be found here: http://docs.puppetlabs.com/learning/definedtypes.html , and it has a couple of examples that should get you going. In my environment I have a type similar to the below: class tg_accounts { tg_accounts::setup_user_account { 'sweetk' : user => 'sweetk', uid => 12345, gid => 12345, ssh_key_type => 'ssh-dss', actual_name => 'Keiran S', shell => '/bin/bash', ssh_key => 'THE-LONG-SSH-PUBLIC-KEY-GOES-HERE', } } Within this type the following things are done based on the above input: * Create a group and user with the uid/gid/actual_name/shell/ values passed to the type and ensure the user is a member of the group. * Setup a home directory for the user and enforce the permissions on it to be as per the sites standard * Setup a .ssh directory in the users home directory and enforce its required permissions for security with SSH keys * Populate the users authorized_keys file with the key defined in ssh_key of the type defined in ssh_key_type so they can login with key based auth from their workstations * Copy the /etc/skel/ files such as .bash_profile & .bashrc into the home directory if they are found to be absent as the User type doesnt currently support the skeleton framework at this stage. * There is also an optional md5_password_hash option you can pass to the type that will set a users password hash to a particular string if you feel this is required for some accounts Once you have your logic in place, the user configuration will then be validated to be correct every puppet run which for me has been a godsend. One thing worth noting however with user accounts is that when you start managing large numbers of users in this fashion your puppet runs are likely to slow down , and that a central user repository would then be more ideal (ie LDAP). Cheers, K On Monday, December 17, 2012 4:12:05 PM UTC, j wrote: > > I have a home directory being created and not removed as a user is > added/removed. That is desired behavior. However, there are certain > files/dirs in that home directory that I want to always remove if the user > gets marked absent. Unfortunately, the dependencies lead back to the home > directory, which leads to the user, and since the user is removed first, > the removal of files/dirs in the homedir always gets skipped because of > failed dependencies. The files are always referred to as > ${homedir}/${username}/<file_to_be_removed>. Does anyone have an elegant > solution to this problem? > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/atu52IsRFs8J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
