You could always add that information through a local fact.d script ( http://www.ansibleworks.com/docs/playbooks_variables.html#local-facts-facts-d). Enumerating every installed user's information in facts could be a ton of information, especially if your system is authenticating through a directory service, so that's not something most users would want to be on by default.
On Sun, Dec 8, 2013 at 6:33 AM, Jürgen Haas <[email protected]> wrote: > Let's assume we have any array of users that should be present on any host > with some defined permissions. To do that with ansible, the modules 'user' > and 'authorized_key' are perfect tools. > > What I would like to achieve in addition is to make sure that no other > user accounts are available on my hosts. My thinking is to go through the > following steps: > > 1. Get a list of all user accounts on the host. > 2. For all users in that list that are not in my list of allowed > users, take some action: > 1. Lock the user: usermod -L USERNAME > 2. Clean the authorized_keys file in $HOMEDIR/.ssh > > This should make sure that neither login through passwords nor with > certificates should be possible for those accounts but we do not delete > them, as there are many system accounts that you never really want to > delete. > > I'm sure this could be done with shell scripts but wouldn't it be nicer if > the Ansible modules could offer that as well? > > Also, using the module authorized_key is always adding new public keys to > a given user account. What's missing seems to be a reset option, so that > all previous public keys get removed and only the ones being added will be > valid from then on. A rest isn't that difficult and can be done by deleting > the existing $HOMEDIR/.ssh/authorized_keys file, but that required the > knowledge of the home dir which isn't available through Ansible either. > > Maybe extending the facts might help? If we knew all users, their state > and their homedir, that would allow us to do much more already with > existing modules. > > Just looking for ideas and how others are approaching this. > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- James Cammarata <[email protected]> Sr. Software Engineer, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
