Uh oh, looks like there's different behavior on different OSes here.

Michael merged in my change here, because on FreeBSD the previous user code was not indempotent: #3001

Putting in your proposed fix, I'm back to no longer being indempotent.

Out of curiousity, what's the result you get for list(pwd.getpwnam(username))? On my system, I get back this:

['server', '*', 1010, 1010, 'Server', '/usr/home/server', '/bin/tcsh']

Adding on here... the "and not" change didn't keep indempotency for me, but changing to "or" does. Which then makes me wonder, what's even the point of the second part of that clause? Isn't checking if the user name appears in the group membership list sufficient enough?

Can you please clarify this some more? Idempotency is a silly word and I'd like to talk about actual behavior you are seeing. Idempotency is about running commands when commands should not be run. This sounds like it's something more than that.

(A) I start in this condition with user belong to ____ groups. I am managing ___ OS.

(B) I run this task: ________

(C) I expect to have groups set to ______ but instead the result is they are set to _______

OR

It works for me and it is just reporting the wrong changed state about whether it changed anything.

etc

mpdehaan:

OS: Debian 7

I start out with user 'foo' having a primary group 'foo' and nothing else.
Then I execute the task:
action: user name=foo groups=admin append=yes

Ansible adds user foo to the admin group and says:

TASK: [make sure foo is an admin] ***************************************** 
 changed: [10.0.0.161]

When I run the play again, foo is now a member of admin and it's primairy group foo.

TASK: [make sure foo is an admin] ***************************************** 
 changed: [10.0.0.161]

It also still execute the command ['/usr/sbin/usermod', '-a', '-G', 'admin', 'foo'], however the tools is smart enough not to add it twice to /etc/group.

Thanks that helps clarify things, appreciate it.

Out of curiousity, what's the result you get for list(pwd.getpwnam(username))? On my system, I get back this:

['server', '*', 1010, 1010, 'Server', '/usr/home/server', '/bin/tcsh']

['foo', 'x', 1000, 1000, 'foo,,,', '/home/foo', '/bin/bash']

That looks pretty similar to me :)

I see that in your example you use 'groups' instead of 'group'.

  tasks:
    - name: Create server group
      group: name=server gid=1010
    - name: Create server user
      user: name=server uid=1010 comment="Server" home=/usr/home/server groups=server shell=/bin/tcsh

This does not work for me at all since useradd on debian will try to create a new group 'server' which has already been created in the previous step. Changing groups=server to group=server yield the desired outcome.

Could this be a problem in your playbook ?

As I see it your task is trying to add the primary group of the user to the additional groups. (At least this is how it works on Linux)

This should be prevented, currently Linux usermod utilities is ignore the command but it will still try on the next run.

I see two options here:

1. We will raise an error when the users primary group is one of the items in the groups parameter. (My personal favorite)

2. We will automatically filter out the users primary group out of the groups parameter. (This has some drawbacks as we now have 3 states to deal with: groups=[1,2,3], groups= and groups= because the only value was the users primary group)

See pull request #3072

The patch is rather large, sorry about that.

I was not convinced by the method name get_groups_set but could not think of something else at the moment.

Oh, I see. Originally I had a list of groups and in the spirit of shrinking it down to the simplest test case, wound up writing the bug with only a single item for the groups argument. That said, the documentation and the code aren't well documented in that regard. get_group_membership() apparently is supposed to return all of the groups a user belongs to...except for the primary group. IMO it should mention that in a docstring or comment.

Anyhow, sorry for screwing things up originally!