@khokha -
For your FIRST question:
So again ... I think you are reading too much into the text. The book mentions that by default the EEI (Execution Environment Image) is set to use the root user as the default user in the container image, so when the execution environment launches (runs a container), it will be running as root.
One way you can see this (knowing it is a container)
podman run --rm -it utility.lab.example.com/ee-supported-rhel8:latest whoami
If you aren't making an ansible.cfg that the Execution Environment consumes and reads in for settings or if you are creating a config file and not specifying any users, it will go with the user running the command inside the container (ansible-playbook) which is the root user as we confirmed with the podman command above. I created a demo here for you:
https://github.com/tmichett/RH294/tree/master/AAP2_Demo
The easier way to see things is when you are using the ansible-playbook command and not relying on the container or execution environments. Ansible runs the plays as the configured user (if specified) otherwise it runs it as the current user. The current user would be the shell user. However, when you run something inside a container, the shell user could be anything. In the EEs that we are using, the container user is root. So unless you have a user defined in the ansible.cfg it will attempt to run as root.
Why do things work in the lab environment, root is setup with the student keys loaded on all systems, so ssh'ing from the student user with ssh root@servera will connect without a password.
Additionally, we have the student user setup and configured in the SUDO file to require a password and the DevOps user doesn't require a password.
Second Question:
You don't need to use the word SUDO at all in any of the playbooks. The become in the playbook or the ansible.cfg file will instruct the play, the task, or playbook to be run with elevated privileges as defined in the ansible.cfg. Again, if using execution environments and going with defaults, it will attempt to use the root user. I have provided some demo playbooks with the debug command in the repository that lets you see that.
with ansible.cfg
[student@workstation with_config]$ whoami
student
[student@workstation with_config]$ ansible-navigator run playbook_demo.yml -K
[WARNING]: Ansible is being run in a world writable directory (/home/student/Github/RH294/AAP2_Demo/with_config), ignoring it as an ansible.cfg source. For more information see
https://docs.ansible.com/ansible/devel/reference_appendices/config.html#cfg-in-world-writable-dir
BECOME password:
PLAY [Create Sudoers File] ****************************************************************************************************************************************************************************************
TASK [Gathering Facts] ********************************************************************************************************************************************************************************************
ok: [servera.lab.example.com]
TASK [Show user for the task with Become=True] ********************************************************************************************************************************************************************
changed: [servera.lab.example.com]
TASK [Display User with play Become=True] *************************************************************************************************************************************************************************
ok: [servera.lab.example.com] => {
"msg": "My user for Become=True is root"
}
TASK [Show user for the task with Become=True] ********************************************************************************************************************************************************************
changed: [servera.lab.example.com]
TASK [Display User with play Become=false] ************************************************************************************************************************************************************************
ok: [servera.lab.example.com] => {
"msg": "My user for Become=false is root"
}
PLAY RECAP ********************************************************************************************************************************************************************************************************
servera.lab.example.com : ok=5 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
without ansible.cfg
[student@workstation no_config]$ whoami
student
[student@workstation no_config]$ ansible-navigator run playbook_demo.yml -m stdout -i inventory
PLAY [Create Sudoers File] *****************************************************
TASK [Gathering Facts] *********************************************************
ok: [servera.lab.example.com]
TASK [Show user for the task with Become=True] *********************************
changed: [servera.lab.example.com]
TASK [Display User with play Become=True] **************************************
ok: [servera.lab.example.com] => {
"msg": "My user for Become=True is root"
}
TASK [Show user for the task with Become=True] *********************************
changed: [servera.lab.example.com]
TASK [Display User with play Become=false] *************************************
ok: [servera.lab.example.com] => {
"msg": "My user for Become=false is root"
}
PLAY RECAP *********************************************************************
servera.lab.example.com : ok=5 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
The difference between the two demos is that one of them actually had an ansible.cfg file defined so you can see that ansible-navigtator when running the EE took the defined user as student. When an ansible-user wasn't specified it used the user inside the container.
Third Question:
The root user is the root user. It can use BECOME if you are the root user, but there really isn't a need to do that. Is it right/wrong ... doesn't really matter. Once you are the "ROOT" user, you can do anything, so no need to elevate privileges.
You can most certainly sudo to root as the root user, so it doesn't break anything, but if you are already using the "root" user as the Ansible user, there is no need for a "become" section.
The only scenario where you might need to define the "BECOME" section with a "BECOME_USER" would be in the instance of managing a database or something else where you need to be the admin user of the application and not the "ROOT" user.
You should look over the Github demo here and play with it in your environment. You should be able to clone the playbooks down or copy/paste them into your RH294 lab environment. Then you can play around with the different users and scenarios.
I also strongly encourage you to "re-read" the Managing Ansible Configuration Files section of Chapter 2 as it gives a lot more details on the configuration.
Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
