RHCSA (036): Season 2 - Scenario 11: Secure Documentation Access

Episode 036 Executive Summary

In this Secure Documentation Access RHCSA lab scenario, I start performing the lab after a 6-minute introduction by the podcast hosts. You'll get the most out of this lab if you listen to the entire show and then try to practice the lab several times, either along with me or by yourself. This exercise reflects common operational requests where administrators must navigate system manuals and delegate tasks securely.

This scenario traps candidates who rely solely on internet searches and memory rather than native system documentation. By enforcing strict user separation, you must first switch into a designated administrative account before leveraging your elevated privileges. The operational goal is to retrieve necessary configuration directives directly from the local system manuals and then to apply those changes to the network perimeter.

The core challenge requires configuring local documentation for a web service, identifying the default configuration directory using man pages, and finally using sudo to adjust the firewall. You'll rely on tools like su, man, and firewall-cmd to complete these objectives securely. Verification involves testing the elevated commands and confirming that the documentation was accessed and applied correctly.

Keywords: GNU/Linux, Linux, RHCSA, Documentation, Sudo, Firewalld, Switch Users

EPISODE 036: Secure Documentation Access

• Season: 2 | Difficulty: High
• Objectives: Primary 1.11, 1.5; Secondary 9.4, 8.4
• Lab Focus: Linux, RHCSA, Documentation, Sudo, Firewalld, Switch Users
• URL: https://djere.com/rhcsa-036-season-2-scenario-11-secure-documentation-access.html

1. SCENARIO BRIEF (THE PROBLEM)

You're tasked with preparing a system to host a web server, but you must do so as the designated user 'web-admin'. You must switch to this user, install the necessary documentation, consult the native system manual pages to verify the configuration path, and then use your delegated sudo access to open the appropriate firewall port to allow web traffic.

2. TASK ANALYSIS (THE "WHY")

• 1.11 (Documentation): Administrators must be able to find syntax and configuration paths natively when offline during the exam.
• 1.5 (Switch Users): Proper auditing requires executing commands as a named user rather than logging directly in as root.
• 9.4 (Sudo): Delegated privileges prevent full root access while allowing necessary system modifications.
• 8.4 (Firewall-cmd): Securing the network perimeter is required after installing new listening services.

3. SOLUTION STEPS

Step 1: Environment Setup (Root Only)

# We check if the user 'web-admin' exists, and if not, we create it and add it to the 'wheel' group for sudo access. We also set a complex but memorable password using chpasswd to teach good security habits and to pass PAM checks on modern RHEL systems.
if ! id web-admin >/dev/null 2>&1; then useradd -G wheel web-admin; echo "web-admin:Rhcsa-L@b-2026" | chpasswd; fi

# We ensure that the firewalld service is installed and running, as our secondary objective requires modifying it.
if ! rpm -q firewalld >/dev/null 2>&1; then dnf install -y firewalld; systemctl enable --now firewalld; fi

Step 2: Core Implementation (Execute as [User])

# We use 'su' with the hyphen flag to switch to the 'web-admin' user and to simulate a full login environment, loading their specific bash profile.
su - web-admin

# We use sudo with dnf to install the httpd and httpd-manual packages. The -y flag automatically answers yes to the installation prompts.
sudo dnf install -y httpd httpd-manual

# We use the 'man' command to read the httpd manual page, and pipe it to grep to search for the specific directory path.
man httpd | grep "/etc/httpd" > ~/doc-proof.txt

# We use sudo with firewall-cmd to permanently add the http service to our active zone. The --permanent flag ensures that the rule survives a reboot.
sudo firewall-cmd --permanent --add-service=http

# We reload the firewall configuration to apply the permanent changes that we just made to the runtime environment.
sudo firewall-cmd --reload

# Technical Breakdown: The hyphen in 'su -' is critical for loading the correct PATH variables. Without it, the environment remains that of the previous user, which often leads to command-not-found errors for administrative binaries.
# Pro-Tip: Exam candidates frequently forget to run '--reload' after using '--permanent' with firewall-cmd. Always reload, or your rule won't be active during the testing phase.

Step 3: Verification (The "Proof of Work")

# We verify the user switch and documentation extraction by reading the file that we created.
cat ~/doc-proof.txt
* EXPECTED: Set the initial value for the ServerRoot directive to serverroot. This can be overridden by the ServerRoot directive in the configuration file. The default is /etc/httpd.

# We verify that the firewall rule is active in the current runtime environment.
sudo firewall-cmd --list-services
* EXPECTED: dhcpv6-client http ssh

4. COMPREHENSIVE CLEANUP (ZERO-TRACE)

# We exit the 'web-admin' shell to return to the root user.
exit

# We remove the firewall rule, reload the firewall, remove the installed packages, and delete the user and their home directory.
firewall-cmd --permanent --remove-service=http
firewall-cmd --reload
dnf remove -y httpd httpd-manual
userdel -r web-admin