Add locked state for user module, beginnings of integration test

[billwanjohi]

This branch adds implementations for locking user accounts across systems, but returns an error for all but Generic (Linux) systems, since I'm not able to test the others. Guided by #2211.

It also has basic tests for creating and deleting a user.

Lastly, there's a skipped test that would check for a locked password, but I'm unconvinced that that is necessary once you've expired the account.

[mpdehaan]

Thanks for this.

(Since this makes users on the system where the tests are run, this probably needs to be moved to the "destructive" integration test category. Can you update this?)

I'll leave testing for others when we get to this in the queue.

Thanks again!

[billwanjohi]

That makes sense, moved it to destructive.

[quiver]

It looks to me what @billwanjohi implementted here is setting expire date for user accounts($ useradd --expiredate), rather than making it locked.
I think #2211 is to implement $ usermod --lock/--unlocked in ansible, doesn't it?

[billwanjohi]

You are correct about what's implemented here. The problem with --lock is that it only affects the password. Specifically, it prepends an "!" in front of the user's stored password, thus breaking it. Any other type of access is permitted.

I think that that is inadequate and deceptive, and so the account should be expired.

[quiver]

The problem with --lock is that it only affects the password.

That's right. Locked users still can log in with key authentications.

I think that that is inadequate and deceptive, and so the account should be expired

lock and expire are two different thing. lock-ed account may behave counterintuitive but this is lock's specification. If you want to lock an account, you can make the account locked state. If you want to expire an account, you can make the account expired state. Locking an account ends up with expiring it seems odd to me.

FYI, chef's user lock is usermod --lock internally. http://docs.opscode.com/resource_user.html

Anyway, I have no objection to adding expire state to user module.

[billwanjohi]

I am not opposed to the state being named expired.

[mpdehaan]

Sounds like the argument is for adding "expired" in addition to lock, please make this so and I'll see about merging this.

Meanwhile, we should also make very sure the description for each field makes this clear, so users don't think they have locked something completely when key access is still available.

[billwanjohi]

OK, I renamed the state to expired, and added an explanatory sentence to the user state documentation. Tests still pass for me.

I did not implement the locked or unlocked state, because it seems either redundant or insufficient in almost all cases. But I did leave a (when: no) task in the user integration test, if someone wanted to add that later. If that were implemented, I would suggest it be a separate user option altogether, maybe "password_lock" with yes and no choices.

All that said, does this look good to merge?

[mpdehaan]

Hi!

Thanks very much for your interest in Ansible. It sincerely means a lot to us.

On September 26, 2014, due to enormous levels of contribution to the project Ansible decided to reorganize module repos, making it easier
for developers to work on the project and for us to more easily manage new contributions and tickets.

We split modules from the main project off into two repos, http://github.com/ansible/ansible-modules-core and http://github.com/ansible/ansible-modules-extras

If you still would like this pull request merged, we will need your help making this target the new repo. If you do not take any action, this
pull request unfortunately cannot be applied.

We apologize that we are not able to make this transition happen seamlessly, though this is a one-time change and your help is greatly appreciated --
this will greatly improve velocity going forward.

Both sets of modules will ship with Ansible, though they'll receive slightly different ticket handling.

To locate where a module lives between 'core' and 'extras'

• Find the module at http://docs.ansible.com/list_of_all_modules.html
• Open the documentation page for that module
• If the bottom of the docs say "This is an extras module", submit your ticket to https://github.com/ansible/ansible-modules-extras
• Otherwise, submit your pull request to update the existing module to https://github.com/ansible/ansible-modules-core
• Note that python modules in ansible now also end in ".py" and this extension is required for new contributions.
• action_plugins (modules with server side components) still live in the main repo. If your pull request touches both, which should be
  exceedingly rare, submit two new pull requests and make sure to mention the links to each other in the comments.

Otherwise, if this is a new module:

• Submit your pull request to add a module to https://github.com/ansible/ansible-modules-extras

It may be possible to re-patriate your pull requests automatically, one user-submitted approach for advanced git users
has been suggested at https://gist.github.com/willthames/afbaaab0c9681ed45619

Additionally, should you need more help with this, you can ask questions on:

• the development mailing list: https://groups.google.com/forum/#!forum/ansible-devel

Thank you very much!