Execute first role (tasks) as root, then proceed with regular admin user

I’ve been struggling with this some time now. Our production servers authenticate users against an LDAP. Therefore, in the playbook to setup a production server, I’d like to first execute the role that configures SSH to authenticate against the LDAP, disable root login and then proceed with the next role, web server setup or something like that, as my own user, ‘verhage’.

Basically, the structure of the playbook is:

playbook.yml:

Why is this not supported? Just try the right syntax:

roles:
  - { role: ldap, remote_user: root, someVariable: foo}

See https://docs.ansible.com/ansible/playbooks_variables.html#id33
(parametrized roles)

Johannes

Maybe you have to change something else. If there is not gather_facts:
no, before the tasks ansible will try to connect and gather facts
about the system. If this fails as user verhage, you might have to do
it the other way round:

hosts: foobar
remote_user: root
...
roles:
  - {role: ldap}
  - {role: whatever, remote_user: verhage}

Or maybe use a playbook with two different plays in it, i.e two
sections, each starting with "hosts: ..." and containing a roles-block.

Johannes

You’re right, I didn’t get the syntax right. However, with the right syntax, I can’t get it to work. The solution with two different plays in the same playbook is the best solution for me, as I don’t want the handlers scheduled by the ldap role to be executed after all other roles in the playbook.

I changed my playbook to contain two separate plays:

What I think is happening here is that at first Ansible logs in with root and the supplied password. On the second play Ansible tries to login with user verhage, but I think it tries to do so with the root password…

After ansible-playbook terminates logging in with “ssh verhage test” using SSH keys works with no problem.

After ansible-playbook terminates logging in with “ssh verhage test” using SSH keys works with no problem.

Typo: “ssh verhage test” should of course be “ssh verhage@test”

This indeed seems to be the problem, according to /var/log/secure on my test machine:

`

Apr 7 11:15:11 localhost sshd[3488]: pam_unix(sshd:session): session opened for user root by (uid=0)
Apr 7 11:15:11 localhost sshd[1083]: Received signal 15; terminating.
Apr 7 11:15:12 localhost sshd[3523]: Server listening on 0.0.0.0 port 22.
Apr 7 11:15:12 localhost sshd[3523]: Server listening on :: port 22.
Apr 7 11:15:12 localhost sshd[3488]: pam_unix(sshd:session): session closed for user root
Apr 7 11:15:14 localhost unix_chkpwd[3528]: password check failed for user (verhage)
Apr 7 11:15:14 localhost sshd[3526]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.57.1 user=verhage
Apr 7 11:15:15 localhost sshd[3526]: pam_ldap(sshd:auth): Authentication failure; user=verhage
Apr 7 11:15:18 localhost sshd[3526]: Failed password for verhage from 192.168.57.1 port 57056 ssh2
Apr 7 11:15:18 localhost sshd[3526]: Connection closed by 192.168.57.1 [preauth]

`

For the second play, it tries to connect with the password I supplied on the command line using -k, which is the password for root…