Adding user with user module fails on RHEL7

[jwfuller]

ISSUE TYPE

• Bug Report

COMPONENT NAME

user

ANSIBLE VERSION

ansible 2.2.1.0
  config file =
  configured module search path = Default w/o overrides

CONFIGURATION

Default

OS / ENVIRONMENT

I think N/A but OSX 10.11.6

SUMMARY

Cannot create a user on RHEL 7. See also ansible/ansible-modules-core#4238

STEPS TO REPRODUCE

When running the following on a RHEL7 target

- name: Create osr-ansible user
  user:
      name: osr-ansible
      group: vansible

EXPECTED RESULTS

User should have been created

ACTUAL RESULTS

TASK [server_base : Create osr-ansible user] ***********************************
task path: /Users/jafu6031/vms/w3_local/ansible/roles/server_base/tasks/main.yml:32
Using module file /usr/local/lib/python2.7/site-packages/ansible/modules/core/system/user.py
<192.168.33.30> ESTABLISH SSH CONNECTION FOR USER: vagrant
<192.168.33.30> SSH: EXEC ssh -vvv -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/jafu6031/vms/w3_local/.vagrant/machines/ansible.w3/virtualbox/private_key -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=30 -o ControlPath=/Users/jafu6031/.ansible/cp/ansible-ssh-%h-%p-%r 192.168.33.30 '/bin/sh -c '"'"'( umask 77 && mkdir -p "` echo ~/.ansible/tmp/ansible-tmp-1489427844.2-145726609962474 `" && echo ansible-tmp-1489427844.2-145726609962474="` echo ~/.ansible/tmp/ansible-tmp-1489427844.2-145726609962474 `" ) && sleep 0'"'"''
<192.168.33.30> PUT /var/folders/xx/ztpwyq2j5397xnp2k3ggl58jqqz_vl/T/tmpfU4IA5 TO /home/vagrant/.ansible/tmp/ansible-tmp-1489427844.2-145726609962474/user.py
<192.168.33.30> SSH: EXEC sftp -b - -vvv -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/jafu6031/vms/w3_local/.vagrant/machines/ansible.w3/virtualbox/private_key -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=30 -o ControlPath=/Users/jafu6031/.ansible/cp/ansible-ssh-%h-%p-%r '[192.168.33.30]'
<192.168.33.30> ESTABLISH SSH CONNECTION FOR USER: vagrant
<192.168.33.30> SSH: EXEC ssh -vvv -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/jafu6031/vms/w3_local/.vagrant/machines/ansible.w3/virtualbox/private_key -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=30 -o ControlPath=/Users/jafu6031/.ansible/cp/ansible-ssh-%h-%p-%r 192.168.33.30 '/bin/sh -c '"'"'chmod u+x /home/vagrant/.ansible/tmp/ansible-tmp-1489427844.2-145726609962474/ /home/vagrant/.ansible/tmp/ansible-tmp-1489427844.2-145726609962474/user.py && sleep 0'"'"''
<192.168.33.30> ESTABLISH SSH CONNECTION FOR USER: vagrant
<192.168.33.30> SSH: EXEC ssh -vvv -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/jafu6031/vms/w3_local/.vagrant/machines/ansible.w3/virtualbox/private_key -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=vagrant -o ConnectTimeout=30 -o ControlPath=/Users/jafu6031/.ansible/cp/ansible-ssh-%h-%p-%r -tt 192.168.33.30 '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-szhjvuytwxlslkgjljnbhzldrrleczol; /usr/bin/python /home/vagrant/.ansible/tmp/ansible-tmp-1489427844.2-145726609962474/user.py; rm -rf "/home/vagrant/.ansible/tmp/ansible-tmp-1489427844.2-145726609962474/" > /dev/null 2>&1'"'"'"'"'"'"'"'"' && sleep 0'"'"''
fatal: [ansible.w3]: FAILED! => {
    "changed": false,
    "failed": true,
    "invocation": {
        "module_args": {
            "append": false,
            "comment": null,
            "createhome": true,
            "expires": null,
            "force": false,
            "generate_ssh_key": null,
            "group": "osr-ansible",
            "groups": null,
            "home": null,
            "login_class": null,
            "move_home": false,
            "name": "osr-ansible",
            "non_unique": false,
            "password": null,
            "remove": false,
            "seuser": null,
            "shell": null,
            "skeleton": null,
            "ssh_key_bits": 0,
            "ssh_key_comment": "ansible-generated on ansible.w3",
            "ssh_key_file": null,
            "ssh_key_passphrase": null,
            "ssh_key_type": "rsa",
            "state": "present",
            "system": false,
            "uid": null,
            "update_password": "always"
        },
        "module_name": "user"
    },
    "msg": "usermod: user 'osr-ansible' does not exist in /etc/passwd\n",
    "name": "osr-ansible",
    "rc": 6
}

[snowsky]

why is it osr-ansible instead of ansible user to be created?

[jwfuller]

Sorry, changed the name in play snippet for simplicities sake, adjusting back

[jwfuller]

I ran 2 plays and got the desired result. Seems like the bug is in trying to set the group when creating a user.

- name: Create osr-ansible user
  user:
      name: osr-ansible
#       group: osr-ansible

- name: Update user osr-ansible groups
  user:
      name: osr-ansible
      groups: osr-ansible,adm,wheel
      append: yes

[oleyka]

@jwfuller You do not need "osr-ansible" in the "groups" list in the second task — it is the user's primary group already.

[jwfuller]

Thanks @oleyka. I think I have this sorted. If I switch from group to groups in the first task, it runs successfully.

RHEL creates private groups by default, so I was being redundant in my config.

I am going to close this since I don't think it is a real bug.

[TopherGopher]

I actually think it is a real bug. I can get the desired results when I run ansible==2.0.2.0 but not with ansible==2.3.0.0. I know we're lagging behind in our version, but I can tell you something was introduced that makes this:

- name: Create the user account
  user:
    name: "user"
    shell: /bin/bash
    group: admin
    groups: adm
    append: yes
    state: present
  register: user_account

go from a successful run in RHEL 7 to a failed run.

17:45:39 TASK [Create the user account] *************************************************
17:45:40 fatal: [10.0.1.240]: FAILED! => {"changed": false, "failed": true, "msg": "usermod: user 'user' does not exist in /etc/passwd\n", "name": "user", "rc": 6}

[safonas]

Having the same issue with RHEL 7 and Ansible 2.2.0 and 2.2.1, error message as above

- name: Create oracle user
  user:
    name: oracle
    state: present
    group: oinstall
    groups: dba
    append: no

[ipolishchuk]

The same issue on ansible 2.2.1.0, target host is on Red Hat Enterprise Linux Server release 6.7 (Santiago)

• user:
  name: prometheus
  uid: 800
  group: prometheus
  shell: /bin/bash
  system: yes
  home: /home/prometheus
  createhome: no

[ipolishchuk]

In my case, the problem is that the user is under IPA management, not local user. If I remove "home: /home/prometheus," it seems working ok.

[savishy]

Updating for a target machine of CentOS 6.5 x64 bit and Ansible 2.3.1.0:
Workaround provided by @ipolishchuk also worked for me, i.e

    user: name={{ app_user }} shell=/bin/bash groups={{ app_group }} append=yes state=present home={{ app_user_home }}

became

    user: name={{ app_user }} shell=/bin/bash groups={{ app_group }} append=yes state=present

[infrascripting]

I encountered this as well. While it may not be technically a bug, it is certainly counter-intuitive.

[abukharov]

From what I learned Ansible calls useradd and usermod in random order, so if your user has any other extra attributes e.g. comment or home, it is likely to fail.

[larsks]

People experiencing this problem are probably running the sssd service. The behavior described here is caused by sssd caching information about users. You can reproduce this from the command line very simply:

# useradd testuser
# id testuser
uid=21940(testuser) gid=21946(testuser) groups=21946(testuser)
# userdel -r testuser
userdel: group testuser is the primary group of another user and is not removed.
# grep testuser /etc/passwd
# id testuser
uid=21940(testuser) gid=21946(testuser) groups=21946(testuser)

In the above example, you can see both that (a) userdel fails to complete (it deletes the user, but not the group), and (b) id is still able to return information about the user even though the user no longer exists in /etc/passwd.

You can avoid this problem by explicitly flushing the sssd cache:

# sss_cache -E

[dglinder]

My situation has this same problem but for a slightly different reason. We don't permit password changes/updates from the end machine - we have an identity management system that pushes the changes into LDAP.

I can run the user module with all the options (name, uid, group, comment, home, shell, state) and it doesn't complain. BUT when I set the password field ti dies, even when it's using the current password that is set in LDAP. When we run the normal passwd command we get this generic message:

$ passwd
Changing password for user {{ name }}.
Current Password: {{ password }}
passwd: Authentication token manipulation error
$

Along with this error is this message from pam_sss in /var/log/secure:

passwd: pam_sss(passwd:chauthtok): Authentication failed for user {{ name }}: 4 (System error)

We have both LDAP and stand-alone systems this playbook could be run against, so dropping the password password from the playbook isn't an option. In my case I'm going to do all the other steps, then in the next task we'll just set the password and watch (or ignore) the errors.

If anyone has a better idea on handling both cases I'm all ears.