cancel
Showing results for 
Search instead for 
Did you mean: 
morbius
Flight Engineer
Flight Engineer
  • 8,968 Views

EX294 (RHCE) exam environment

Jump to solution

Hi, I need some information on what I have available to me during the EX294 exam. Does Ansible controller host have on it graphical environment with an available text editor, such as gedit? Can I copy/paste text between browser with the questions and host where I'm writing playbooks?

 

Gedit is an excellent text editor able to detect and properly mark Ansible sintax, it would be a great help not having to edit playbooks in nano, or god forbid vi. My RHCSA exam was a horrible experience, copy/paste didn't work. Terminal I had available couldn't connect to servers, so I had to do everything from VM terminals, typing manually. Add to that that DNS didn't work, I can't believe how I managed to pass. I can't aford to lose time fighting with the exam environment again, I need to know what I can use and how.

Labels (2)
26 Replies
SubuRama
Flight Engineer
Flight Engineer
  • 2,898 Views

I've RHLS and as in ch02s07 in EX294v9

First:

the section of <remote users and privilege escalation> it is mentioned

" By default, if you use ansible-navigator run to run a playbook, then Ansible connects to the managed host as the current user inside the automation execution environment, root."

Subu: See below. You are "root" in the EE that ansible-navigator uses

SubuRama_0-1694953034344.png

 

and in the review #1

we added users without configuring privilege escalation at all or remote_user, so i'm really confused how this works? 

Subu: Are you referring the Lab: Deploying Ansible in the comprehensive review Chapter 10?

SubuRama_1-1694953263925.png

If you just run this using "ansible-playbook" you will get permission errors.

useradd permission denied etc.

SubuRama_2-1694953602398.png

 

See below for running the same playbook with ansible-navigator using the EE. I have been playing around and have messed up servera below

SubuRama_3-1694953774154.png

 

But the gist of the matter is we are connecting to the inventory hosts as "root" from the EE. And the inventory hosts let root in without passwords etc. and so useradd etc. succeeds.

So the task is successful on serverb. (changed = 1)

SubuRama_4-1694953880676.png

You can see the details by using ansible-navigator replay <artifact_file>

SubuRama_5-1694953998521.png

 

 

Second:

if i configured sudo for a user without password shouldn't the word sudo be mentioned or in the playbook it is different the command just runs as long as sudo is configured it is run as sudo <command>?

Subu: I don't quite understand your question. The playbook uses the
"remote_user" and "become_user" settings. These two variables are different.

remote_user is the account that logs in the machine. In the EE (even without any setting this is root since everything is done as root from the EE)

If you are not using the EE, you need to set become: to true and become_user: to root or some other privileged user that can do the operations.

https://docs.ansible.com/ansible/latest/inventory_guide/connection_details.html

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_privilege_escalation.html

 

Third:

In point 1 you mentioned <no need to become "root" if you are using the "root" user in the ansible.cfg file. > can you explain more please?

Subu: ansible.cfg just sets the default remote_user, become_user etc. so you don't have to specify things at the play/task levels. I would not suggest setting any of these in ansible.cfg and IMO, it's better to use the needed escalation as necessary in the playbook itself.

one more question if i run a playbook that contains a tasks that requires privilege escalation would it give error saying like: permission denied or requires privileges?

Subu: Absolutely :-). See example above that I showed for running users.yml

khokha
Flight Engineer
Flight Engineer
  • 2,852 Views

@SubuRama 

Thanks for your reply.

In the third image using ansible-navigator why did you get permission denied although you're using ansible-navigator when running users.yml?!!

as you mentioned "If you are not using the EE, you need to set become: to true and become_user: to root or some other privileged user that can do the operations.

I'm supposed to be able to run everything that requires privilege escalation using ansible-navigator without any additional configuration.

Thanks in advance

SubuRama
Flight Engineer
Flight Engineer
  • 2,841 Views

You are welcome. As I mentioned, that "permission denied" error was only for servera. I think I was playing around with the keys, setting up other users (not student) etc.

Anyway, as you can see serverb didn't have any issues.

Subu

0 Kudos
Travis
Moderator
Moderator
  • 7,092 Views

@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
Travis
Moderator
Moderator
  • 2,882 Views

@Trevor -

Thought you might also find this thread interesting.

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
Trevor
Starfighter Starfighter
Starfighter
  • 2,872 Views

Dang!  Dang!  Dang!

Travis, to say that I might find that thread interesting, is more than a little bit of
an understatement!!!

Dang!  Dang!  Dang!

Wow!  Wow!  Wow!

Trevor "Red Hat Evangelist" Chandler
khokha
Flight Engineer
Flight Engineer
  • 2,852 Views

@Travis 

Thanks alot i created the environment from scratch and i got multiple errors which made me know how in overall ansible needs to be configured.

i just want to make sure again of one point as you said inside the container the user is the root user, it is the default behavior with or without ansible.cfg so i don't need to configure become true when using ansible-navigator unless for the case you mentioned of the database.

Again thanks for your help

Travis
Moderator
Moderator
  • 7,044 Views

@khokha -

You are still missing the critical point ... it seems like you don't want to configure the ansible.cfg but you should always define the user you are  using to connect with as well as have those credentials or SSH keys handy.

It doesn't matter that root is the user that runs default processes in the container (as that is defined by whomever built the container image). However, your bigger concern is "what happens if the playbook doesn't run and fails??"

Most systems prevent root from logging on using SSH. If systems do by some miracle violate traditional security standards and allow root to login, almost certainly it is never with an SSH password. Hackers would love that as they could brute force all day long. Instead, generally, root is forbidden to login via SSH (password or SSH-key). The fact it works in the lab environment is because you are lucky. We setup the machines with SSH keys and our default images have those keys distributed from the student user to all the machines. This helps the lab start/grade/finish scripts work. This is 100% not standard and 100% not normal. So it is critical to understand this point.

By learning early and often to specify in the ansible.cfg and the ansible-navigator.yml files, you are controlling your environment and you know the users things connect with and you know the credentials and keys you will need to provide. By just hoping that everything just works because you know the container runs things as root could be very dangerous as this would not work outside our classroom environment.

Likewise, as mentioned earlier, we have two users setup on the system that can SSH and SUDO. The student user can sudo but requires the password, the devops user can sudo without a password. Again, something you can easily try and verify.

Also in terms of the exam environment, you must be aware and read the directions for everything and how things are setup and configured. You cannot assume that anything will be done for you in this environment and you cannot assume it will be like the classroom environment where things get setup where you take them for granted.

I'm currently teaching the RH294 this week to a customer and we just finished covering things in Chapter 2 with regards to inventory and the configuration files and spent a lot of time with question and answers on how things worked and why. Initially here, in the first 2 GEs of Chapter 2 you must create your own inventory file and configuration file - because that is the purpose of the content from the lecture and also the purpose in the guided exercise.

As you progress through the book, we've already taught you how to create the configuration files and inventory files, so the lab scripts will generally set things up and default that for you. This is because we don't want to continue re-teaching and having you spend time on the same thing over and over, but instead focus on the new concepts you are learning.

Hopefully this makes sense and you can ponder what is here and then test it in your lab environment.

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
khokha
Flight Engineer
Flight Engineer
  • 2,812 Views

@Travis 

Thanks for your reply, sorry for asking too many questions but i'm trying to understand the configuration. Away from the lab environment as i read chapter 2 for ansible configuration, what i should configure is:

1- ansible.cfg: remote_user, become, become_{method, user, ask_pass}

2- /etc/sudoers.d/ to enable privilege escalation for unprivileged remote_user

3- ssh for remote_user

4- inventory and ansible-navigtar

As you mentioned by default root login isn't allowed using ssh, so previously when i configured it on my personal vm everything worked fine but  after disabling it i get this error although  the playbook runs.

so, is this normal?

error1.png

Thanks for your help, i really appreciate it.

Travis
Moderator
Moderator
  • 2,785 Views

@khokha -

At this point I'm a little lost based on your question, where you are or even how you are testing things. 

What I can say above is that you appear to be on a System (serverk) that doesn't have everything 100% setup and configured for all users to properly leverage containers and that there are possibly inconsistencies with CGroups.

I can also determine that ServerK is trying to do something on ServerC, but not sure where ServerC and ServerK is if they are yours or in the RHLS environment. 

What I can say is it does appear that your playbook runs, but keep in mind, it isn't doing anything. It is checking a server (serverc) and showing that it can gather facts and that it has HTTPD installed.

Not sure how it is connection, what is configured, if keys are used or anything else. Again, to truly understand things and see how you are connecting and what I stronly suggest using the DEBUG module to print out things and tell you who you are. 

I also suggest doing things using either the ansible command locally with ad-hoc commands as well as the ansible-playbook command to run a playbook without the virtual environment.

You are getting way to focused on weeds (which you can dig into later), but instead you should focus on some best-practices and understanding some of the fundamental concepts.

Run playbooks, see how they connect. Check log files ... we know connections are made through SSH.

Check the SystemD Journal to see how Ansible made changes ...

 

Quick way to search logs/SystemD Journal for Ansible Changes
sudo journalctl -t platform-python

Using Ansible 
ansible -m command -a 'journalctl -t platform-python' all

 

Sep 19 22:15:18 serverc.lab.example.com sshd[19417]: pam_unix(sshd:session): session opened for user student(uid=1000) by (uid=0)
Sep 19 22:15:19 serverc.lab.example.com sudo[19538]:  student : a password is required ; TTY=pts/0 ; PWD=/home/student ; USER=root ; COMMAND=/bin/sh -c echo BECOME-SUCCESS-khgvjzxjqbrryuphhj>
Sep 19 22:15:30 serverc.lab.example.com sudo[19657]:  student : a password is required ; TTY=pts/0 ; PWD=/home/student ; USER=root ; COMMAND=/bin/sh -c echo BECOME-SUCCESS-yfovmvkldkngaqjhle>
Sep 19 22:15:41 serverc.lab.example.com sudo[19776]:  student : TTY=pts/0 ; PWD=/home/student ; USER=root ; COMMAND=/bin/sh -c echo BECOME-SUCCESS-kygomwibcrwhgftqhwjmdpgldivubjtl ; /usr/bin>
Sep 19 22:15:41 serverc.lab.example.com sudo[19776]: pam_unix(sudo:session): session opened for user root(uid=0) by student(uid=1000)
Sep 19 22:15:41 serverc.lab.example.com python3[19780]: ansible-user Invoked with name=travis uid=1040 comment=Travis Michette group=wheel state=present non_unique=False force=False remove=F>
Sep 19 22:15:41 serverc.lab.example.com useradd[19781]: new user: name=travis, UID=1040, GID=10, home=/home/travis, shell=/bin/bash, from=/dev/pts/0
Sep 19 22:15:41 serverc.lab.example.com sudo[19776]: pam_unix(sudo:session): session closed for user root
Sep 19 22:15:48 serverc.lab.example.com sshd[19802]: Accepted publickey for root from 172.25.250.9 port 40188 ssh2: RSA SHA256:M8ikhcEDm2tQ95Z0o7ZvufqEixCFCt+wowZLNzNlBT0
Sep 19 22:15:48 serverc.lab.example.com systemd[1]: Created slice User Slice of UID 0.
[student@workstation Chapter2]$ ansible -m user -a 'name=travis uid=1040 comment="Travis Michette" group=wheel' production
serverd.lab.example.com | FAILED! => {
    "msg": "Missing sudo password"
}
serverc.lab.example.com | FAILED! => {
    "msg": "Missing sudo password"
}

[student@workstation Chapter2]$
[student@workstation Chapter2]$ ansible -m user -a 'name=travis uid=1040 comment="Travis Michette" group=wheel' production -k
SSH password:
serverc.lab.example.com | FAILED! => {
    "msg": "Missing sudo password"
}
serverd.lab.example.com | FAILED! => {
    "msg": "Missing sudo password"
}
[student@workstation Chapter2]$ ansible -m user -a 'name=travis uid=1040 comment="Travis Michette" group=wheel' production -k -K
SSH password:
BECOME password[defaults to SSH password]:
serverd.lab.example.com | CHANGED => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"

So the above Ad-Hoc command on searching SystemD Journal doesn't appear to work the same on RHEL9, but this is a way to search audit logs and trace some events on RHEL8. However, I showed portions of the SystemD Journal above and the corresponding things that were typed on the CLI with Ansible ad-hoc command and you can see how things were executed and how/when.

 

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
Join the discussion
You must log in to join this conversation.