Recently I wrote an Ansible playbook to extract data from an Informatica PowerCenter repository. The data was then compressed and uploaded into Nexus Repository Manager. I used the command line utility, pmrep, to execute the commands needed to connect to the Informatica repository and to extract the data. A specific Informatica user had been given the necessary privileges to execute the pmrep commands.

NOTE: To become the Informatica user, the following command was used:

sudo su – informatica-user

Ansible Become Directives

I was able to leverage Ansible’s privilege escalation functionality, Become, to execute the commands from my Ansible playbook. The Become directives allow you to execute tasks within a playbook using a different user than the user logged into the machine. There are a few locations the become directives can be set ranging from the playbook down to the task level. Not every task in my playbook needed privilege escalation, but the tasks that did had the following directives defined:

remote_user: remote-user
become: yes
become_user: informatica-user
become_method: su

The remote user directive defines the user that will be logging into the Informatica PowerCenter server.


When set to yes the become directive activates privilege escalation for the task.


The become user directive defines who the user will ‘become’ when executing the task. I set this directive to the Informatica user that had been given the necessary privileges to execute pmrep commands.


The become method directive defines which privilege escalation tool (sudo, su, pbrun, pfexec, doas, dzdo, ksu, runas, machinectl) to use when becoming the new user. I chose ‘su’ since the command to switch users on the Informatica server was

sudo su – informatica-user

Fingers Crossed

I ran my playbook expecting perfection but was met with the following error when my first task using privilege escalation was executed:

{“failed”: true, “msg”: “ERROR! Timeout (12s) waiting for privilege escalation prompt: “}

Naturally I went to my most trusted resource, the internet, where I found several suggestions to increase the timeout. I increased the timeout, but unfortunately it just increased the time it took me to see the following:

{“failed”: true, “msg”: “ERROR! Timeout (40s) waiting for privilege escalation prompt: “}

I quickly tried changing the become_method directive to use ‘sudo’, with no success. It did not take long before I was consulting with my most trusted resource again.


After some research I came across something that looked promising. A suggestion to set the following environment variable:


This directive defines which executable to use for privilege escalation. I reset the become_method directive to ‘su’, added the environment variable to my Ansible playbook command, hit enter, and… The perfection I had been waiting for! The tasks using privilege escalation executed successfully, logging into the Informatica server and switching to the Informatica user.

The executable to use for privilege escalation can also be set in Ansible’s configuration file, ansible.cfg by entering the following:

become_exe=’sudo su -‘

While I did not lose all day trying to figure this out, it did take some time and head scratching.

2 thoughts to “Ansible privilege escalation using ‘sudo su -‘

  • some thinking

    hi, Bos, I’m facing a same issue like you, after taken your idea, I found there still have some problems, follow you setting, machineA don’t need to input password when exec “sudo su -“, so it workd on A, but others machines need input password again when sudo su-, so playwork doesn’t work well,
    I guess all your servers can directly sudo , but regarding my sitution, do you have any ideas ?

  • Ethan A

    Add the following to the task and it should work:
    – name: task to do something awesome
    shell: do something
    become_method: su
    become_exe: “sudo su -”

    Thank you for the article! Definitely helped.


Leave a comment

Your email address will not be published. Required fields are marked *