RHCSA Labs

Hands-on labs aligned with the Red Hat Certified System Administrator (EX200) exam. SELinux enforcement, systemd service management, and firewall configuration with firewalld.

These Labs Cover All Major Linux Certifications

LPI Linux Essentials CompTIA Linux+ (XK0-006) LPIC-1 (101 & 102) LPIC-2 (201 & 202) LPIC-3 (300 / 303 / 305 / 306)
RHCSA (EX200) RHCE (EX294) RHCA LFCS LFCE LFCA CKA CKAD CKS

RHCSA Labs - Module 6

SELinux policy enforcement, systemd service management, and host-based firewall configuration — core RHCSA (EX200) skills.

Lab 16: SELinux Management
Intermediate / Terminal + GUI
Scenario: Resolve a Web Server SELinux Denial
A web server is failing to serve content from a non-standard directory. You must check SELinux status, identify the current mode, view denials in the audit log, apply the correct file context label, and restore contexts. Finally, verify that the boolean for httpd home directories is enabled. These tasks are tested heavily on the RHCSA exam.

Learning Objectives:

RHCSA EX200 — SELinux
  • Status: Check SELinux mode and policy type
  • Audit: Read SELinux denial messages from audit.log
  • Contexts: Apply and restore file security contexts
  • Booleans: Enable SELinux booleans for httpd

📋 Step-by-Step Instructions

  1. Step 1: Check SELinux Status and Mode
    🎯 Goal: Confirm SELinux is enforcing and identify policy type

    💻 Show full status:
    sestatus

    💻 Show current mode:
    getenforce
    💡 Tip: RHCSA requires that SELinux is Enforcing at exam end. Never leave it in Permissive/Disabled.
  2. Step 2: View SELinux Denials in audit.log
    🎯 Goal: Identify the denial preventing httpd from accessing content

    💻 Search audit log:
    sudo ausearch -m avc -ts recent

    💻 Quick grep alternative:
    sudo grep denied /var/log/audit/audit.log | tail -5
    💡 Tip: ausearch is more reliable for structured queries. The grep approach is a quick check.
  3. Step 3: Inspect Current File Context on the Web Directory
    🎯 Goal: See the incorrect context on /web/content

    💻 Show security context:
    ls -ldZ /web/content
    💡 Tip: The -Z flag shows SELinux context. Default new dirs get default_t, not httpd_sys_content_t.
  4. Step 4: Apply the Correct File Context Policy
    🎯 Goal: Add a persistent rule and relabel

    💻 Set context rule:
    sudo semanage fcontext -a -t httpd_sys_content_t "/web/content(/.*)?"

    💻 Restore contexts recursively:
    sudo restorecon -Rv /web/content
    ⚠️ Warning: chcon changes are temporary. Always use semanage fcontext + restorecon for persistent labels.
  5. Step 5: Verify the Updated Context
    🎯 Goal: Confirm the directory now has httpd_sys_content_t

    💻 Check again:
    ls -ldZ /web/content
    💡 Tip: After relabeling you should see httpd_sys_content_t instead of default_t.
  6. Step 6: Enable the httpd_enable_homedirs Boolean
    🎯 Goal: Allow httpd to access home directories and verify

    💻 Set boolean persistently:
    sudo setsebool -P httpd_enable_homedirs on

    💻 Verify boolean state:
    getsebool httpd_enable_homedirs
    🎓 Checkpoint: You resolved an SELinux denial, applied persistent labels, and set a boolean — key RHCSA skills.

Linux Terminal

Terminal
SELinux Dashboard
Audit Viewer
Activity Log
root@rhcsahost:~#
SELinux Status
ModeUnknown
PolicyUnknown
/web/content ContextNot checked
httpd_enable_homedirsoff
Context Policy Rules (fcontext)
No custom rules added yet.
Recent AVC Denials
No audit data viewed yet. Run ausearch to populate.
Recent Activity
[--:--:--]Lab session started. Ready for commands.
Progress: 0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps:

1. Click "Validate Configuration" to check what is done vs pending.
2. Use SELinux Dashboard and Audit Viewer to verify status visually.
Tip: On the real RHCSA exam, leaving SELinux disabled means an automatic fail.
Lab 17: Systemd Service Management
Intermediate / Terminal + GUI
Scenario: Deploy and Manage a Custom Application Service
A new internal application needs to run as a systemd service. You must create a unit file, reload the daemon, enable the service, start it, verify its status, and check its journal logs. This is a common RHCSA task that tests your understanding of the systemd service lifecycle.

Learning Objectives:

RHCSA EX200 — Systemd
  • Unit Files: Create and install a custom systemd service file
  • Daemon Reload: Reload systemd manager configuration
  • Lifecycle: Enable, start, stop, and check service status
  • Logs: Review service logs with journalctl

📋 Step-by-Step Instructions

  1. Step 1: Deploy the Unit File
    🎯 Goal: Copy a prepared unit file into /etc/systemd/system

    💻 Deploy unit file:
    sudo cp /opt/labs/myapp/myapp.service /etc/systemd/system/myapp.service

    💻 Inspect the file:
    cat /etc/systemd/system/myapp.service
    💡 Tip: Unit files live in /etc/systemd/system/ for admin-managed services or /usr/lib/systemd/system/ for packages.
  2. Step 2: Reload the Systemd Daemon
    🎯 Goal: Tell systemd to pick up the new unit file

    💻 Reload daemon:
    sudo systemctl daemon-reload
    ⚠️ Exam Note: You must always run daemon-reload after creating or editing unit files, otherwise systemd won't see the changes.
  3. Step 3: Enable and Start the Service
    🎯 Goal: Enable the service at boot and start it now

    💻 Enable at boot:
    sudo systemctl enable myapp.service

    💻 Start now:
    sudo systemctl start myapp.service
    💡 Tip: You can combine these with systemctl enable --now, but RHCSA often tests them separately.
  4. Step 4: Verify Service Status
    🎯 Goal: Confirm the service is active (running) and enabled

    💻 Check status:
    sudo systemctl status myapp.service --no-pager

    💻 Confirm enabled:
    sudo systemctl is-enabled myapp.service
    💡 Tip: is-enabled returns "enabled" or "disabled" as a single word, useful in scripts.
  5. Step 5: View Service Logs
    🎯 Goal: Check journal output for the service

    💻 Show recent logs:
    sudo journalctl -u myapp.service -n 20 --no-pager
    💡 Tip: journalctl -u filters by unit. Add -f for live tail (not used in this lab).
  6. Step 6: Stop the Service and Verify
    🎯 Goal: Stop the service gracefully and confirm it is inactive

    💻 Stop service:
    sudo systemctl stop myapp.service

    💻 Verify stopped:
    sudo systemctl is-active myapp.service
    🎓 Checkpoint: You deployed, managed, and inspected a systemd service end-to-end — essential for RHCSA.

Linux Terminal

Terminal
Service Dashboard
Unit File Viewer
Activity Log
root@rhcsahost:~#
Service Status
Unit File DeployedNo
Daemon ReloadedNo
Enabled at BootNo
Active Stateinactive
System Services (Excerpt)
ServiceEnabledActiveDescription
/etc/systemd/system/myapp.service
# Unit file not deployed yet
Recent Activity
[--:--:--]Lab session started. Ready for commands.
Progress: 0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps:

1. Validate configuration for status of each task.
2. Use Service Dashboard and Unit File Viewer to inspect state.
Tip: The service lifecycle is: deploy → daemon-reload → enable → start → verify → stop.
Lab 18: Firewall Configuration with firewalld
Intermediate / Terminal + GUI
Scenario: Secure a Multi-Service Host
A server runs SSH, HTTP, and HTTPS. You must verify firewalld is active, check the default zone, add required services, open a custom port for a monitoring agent, make the rules permanent, and verify the final configuration. Firewall management with firewall-cmd is a core RHCSA objective.

Learning Objectives:

RHCSA EX200 — Firewall
  • Service State: Verify firewalld is running and check default zone
  • Service Rules: Add HTTP and HTTPS services to the public zone
  • Port Rules: Open a custom TCP port for monitoring
  • Persistence: Make runtime rules permanent and reload

📋 Step-by-Step Instructions

  1. Step 1: Verify firewalld Status and Default Zone
    🎯 Goal: Confirm firewalld is running and identify the default zone

    💻 Check service:
    sudo systemctl status firewalld --no-pager

    💻 Show default zone:
    sudo firewall-cmd --get-default-zone
    💡 Tip: On RHEL, the default zone is usually public. Always verify before adding rules.
  2. Step 2: List Currently Allowed Services
    🎯 Goal: See what services are already allowed in the public zone

    💻 List services:
    sudo firewall-cmd --zone=public --list-services
    💡 Tip: SSH is usually pre-allowed. HTTP and HTTPS need to be added manually.
  3. Step 3: Add HTTP and HTTPS Services
    🎯 Goal: Allow web traffic through the firewall

    💻 Add HTTP:
    sudo firewall-cmd --zone=public --add-service=http

    💻 Add HTTPS:
    sudo firewall-cmd --zone=public --add-service=https
    💡 Tip: Without --permanent, these are runtime-only rules. We make them permanent in Step 5.
  4. Step 4: Open a Custom Port for Monitoring
    🎯 Goal: Allow TCP 9100 (Prometheus node_exporter) and verify

    💻 Add port:
    sudo firewall-cmd --zone=public --add-port=9100/tcp

    💻 List open ports:
    sudo firewall-cmd --zone=public --list-ports
    💡 Tip: Use --list-ports to verify. Named services and explicit ports are tracked separately.
  5. Step 5: Make Rules Permanent and Reload
    🎯 Goal: Persist runtime rules so they survive a reboot

    💻 Save runtime to permanent:
    sudo firewall-cmd --runtime-to-permanent

    💻 Reload firewall:
    sudo firewall-cmd --reload
    ⚠️ Exam Note: Forgetting --runtime-to-permanent or --permanent means rules are lost on reboot. This is a common RHCSA mistake.
  6. Step 6: Verify Final Firewall Configuration
    🎯 Goal: Confirm all services and ports are listed

    💻 List all info for public zone:
    sudo firewall-cmd --zone=public --list-all
    🎓 Checkpoint: You configured firewalld with services, ports, and persistence — a core RHCSA firewall skill.

Linux Terminal

Terminal
Firewall Dashboard
Zone Viewer
Activity Log
root@rhcsahost:~#
Firewall Status
firewalldUnknown
Default ZoneUnknown
Permanent SavedNo
Allowed Services & Ports
TypeName/PortZone
public Zone Configuration
Run firewall-cmd --list-all to populate this view.
Recent Activity
[--:--:--]Lab session started. Ready for commands.
Progress: 0/6 tasks completed
Score: 0/100
🎉 After Completing All Steps:

1. Validate configuration to check all rules are in place.
2. Use Firewall Dashboard + Zone Viewer for a visual summary.
Tip: Always persist rules for the exam — runtime-only rules vanish on reboot.

Confirm Reset

Are you sure you want to reset this lab? This will:

  • Clear all terminal output
  • Reset all completed tasks
  • Reset SELinux, service, and firewall simulated configurations
  • Reset progress to 0%

This action cannot be undone!