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.
I realize the videos were geared toward entry-level exams. I cannot comment further on what you will or will not have access to on the exam other than what has been provided above.
You cannot get more detailed information. The video shows that the system accessing the exam screen is a graphical workstation which shows exam objectives and also mentions you have SSH to all other systems as well as direct console access.
Again, if you are looking for graphical access on any of the systems you can always install any packages you want. As for whether the repositories are configured ... that again is "too" much information. While it isn't a direct exam objective, Red Hat exams can build on previous knowledge RHCSA => RHCE.
If you are taking the RH294 course, the last chapter before the comprehensive review covers how to install files using the YUM/DNF module as well as the YUM.Repository modules.
All contents and instructions are made available from the exam documentation and objectives page along with the additional information page. So any repositories used and available to you will be listed there. If they aren't configured on a specific system and you need to install something from one of those repositories, it is up to you to configure it.
Keep in mind, that the classroom environment sets up a lot of things for you and we have the lab start/finish scripts that also perform some of the tasks for you to expedite focusing on the Ansible materials and other tasks. There are no lab start/finish/grade scripts on any of our exams, so you will also need to know how to check your work.
This is the "best" you will be able to get in terms of an answer as anything more would violate the NDA.
@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.
@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.
And the official answer is that they can't discuss anything related to the exam architecture.
I love RHEL and it's a joy to use, but every aspect of RH certification exams so far for me has been a horror story. I can only honestly recommend to people to stay far away from RH certs unless it's absolutely neccessary for them to acquire them.
Hi
policies do not allow to comment the exam content. Stay away from discussing this topic here.
Thank you
Ok, but this is not about exam content, this is about exam environment. I need to know what tools are available to me on the remote exam. I remember that RH used to have a page where it described RHCSA exam environment in detail, but I couldn't find it now, nor did I find one for RHCE exam.
As @PetrCihlar mentioned specific content discussion is a violation of the NDA, but you are correct in asking some general questions about the exam environment. To be clear, the RHCSA exam and objectives are quite different from the RHCE or any other exam. So you could expect some things to work differently.
As with all exams and even Red Hat training courses, you can expect to be given access to the version of RHEL repositories that go with the installed version of RHEL for a course. You are also generally given accounts on a system with passwords to those accounts and provided a lot of information in the exam instructions and additional instructions such as Usernames/Passwords, Network configuration and topology, and even where documentation and provided installation repositories are located.
So in terms of software, you can and should be able to install anything you want that comes and is shipped with RHEL. Copy and Paste is always a mixed bag at times, but general exam taking skills I have often suggested copy/paste from the exam web screen into the terminal session when possible.
There are several videos by Ben Oliver on Youtube regarding the exam experience and how remote exams work.
https://www.redhat.com/en/about/videos/how-take-red-hat-remote-exam
https://www.youtube.com/watch?v=Me6Y12-sux8 (shows SSH or using the console)
There are several other videos out there, but these were the links I had handy.
Hi,
I hope that I do not breach the NDA.
During the exams, I have always been able to copy and paste from the browser window to the terminal windows and between terminal windows, with basic mouse right-clicks.
Regards,
Tshimanga
Tshimanga
Thank you Travis, but I'll need some more concrete details. Those videos you linked are about RHCSA exam that I'm done with, I need info about RHCE. Let's try to clarify things.
Is there a ready graphic environment on Ansible controller host? If not, can it at least be installed from the repos, even though that wastes precious time? Are the repos already configured?
In the RH294 course I'm using to prepare, workstation host has Gnome and it would make sense that it would be the same in the exam environment.
I realize the videos were geared toward entry-level exams. I cannot comment further on what you will or will not have access to on the exam other than what has been provided above.
You cannot get more detailed information. The video shows that the system accessing the exam screen is a graphical workstation which shows exam objectives and also mentions you have SSH to all other systems as well as direct console access.
Again, if you are looking for graphical access on any of the systems you can always install any packages you want. As for whether the repositories are configured ... that again is "too" much information. While it isn't a direct exam objective, Red Hat exams can build on previous knowledge RHCSA => RHCE.
If you are taking the RH294 course, the last chapter before the comprehensive review covers how to install files using the YUM/DNF module as well as the YUM.Repository modules.
All contents and instructions are made available from the exam documentation and objectives page along with the additional information page. So any repositories used and available to you will be listed there. If they aren't configured on a specific system and you need to install something from one of those repositories, it is up to you to configure it.
Keep in mind, that the classroom environment sets up a lot of things for you and we have the lab start/finish scripts that also perform some of the tasks for you to expedite focusing on the Ansible materials and other tasks. There are no lab start/finish/grade scripts on any of our exams, so you will also need to know how to check your work.
This is the "best" you will be able to get in terms of an answer as anything more would violate the NDA.
you really mentioned very important point which is the preconfiguration made by the lab start command this is extremelly important to be defined by the exercise we don't know which configurations were done by the command and we could get stuck in any question in the exam if we're solving from scratch as we already don't know complete stepd that need to be done.
let me illustrate with EX294 v9 course, for me i don't really understand become configuration in ansible.cfg, in the student guide it is mentioned by default we connect as root so why in any case would i need privilege escalation (become=true) except for connecting as another user other than the root? why would i enable it when configuring time sync. using roles? or any other role?
I'm wondering if i would need that unless for the case i mentioned above?
Thanks in advance
I'm wondering if it is needed anyytime
@khokha -
Very good question, but I think you are approaching the questions a little bit from the wrong or incorrect perspective. So a few things about our lab environments ...
Not sure which section you are reading that we connect by root on default. Page 31 talks about the Ansible configuration files ansible.cfg and mentions the Ansible User. If we follow the "least privilege" model, you should always use a regular user. Additionally, the "BECOME" should be false. It is fine to define become user and other items, but following security "best practices" you would typically have BECOME = FALSE in the Ansible Configuration ansible.cfg and control privilege escallation at the Play / Task / Block levels. It is best to do at task/block levels. You can also define this at the ROLE levels.
So in answering your question on the timesync role ... what does it do??
Well, this role can configure the NTP services on a system. It will change configuration files for either chronyd or ntpd depending on the OS and what is there, and then ensure your system is set for network time synchronization. This is an administrative task and involves changing configuration files in /etc so you either need the playbook, the role, or ansible.cfg to be set to BECOME so you are the root user.
Again, we can't discuss particular exam questions, but remember Red Hat exams are performanced-based and hands-on. As long as you meet the objective, you should get the points for whatever question you are answering.
So bottom line, read each question carefully and see what you need to do. How would you do it by hand if you weren't using Ansible? What is needed to do by hand? SSHing to the other system?? Performing SUDO to implent the solution? That will help you with the items to place in the ansible.cfg file.
I've been updating some of my demos for RHEL 9 on the RH294 as I will be teaching the newer version for my second time next week. I have lots of older demos there too from the RHEL8 and RHEL7 versions of the course as well as some more complex examples.
https://github.com/tmichett/RH294
Feel free to look at some of the examples in this repository. I also have plenty of other repos with Ansible playbooks for reference too.
I will say sometimes in the DEMOS I use when I teach I use root as the Ansible User because I know I have the root key on all systems and root is allowed via SSH login. But when I use that I always tell my students to "Do as I say, not as I do". Bottom line, for things like the exams and the lab environment for the RH294 course, you can configure things generally how you want. Unless you are told to do things specifically, it is up to you how you choose to implement the solution.
If you have the RHLS subscription, I would encourage you to launch the RH294 lab environment and play with the playbooks. Look at the EoC labs which have the grade and do them without the solutions. Also, attempt doing some things on the labs a different way than what is in the solutios. I think that will truly help you see how things work. Feel free to try without the Lab Start commands (several of the labs you can do that with - except if they provide you starter files or resources you are copying).
Hoep that helps,
Travis
Thanks for your reply,
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."
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?
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>?
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?
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?
Thanks in advance
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.