← Back to all projects

LEARN RHEL FOR CERTIFICATION

Learn Red Hat Linux: A Project-Based Path to RHCSA and RHCE

Goal: To gain the deep, hands-on skills required to pass the Red Hat Certified System Administrator (RHCSA) and Red Hat Certified Engineer (RHCE) exams. This guide provides a series of practical lab projects that mirror the real-world tasks you will face, moving from single-system administration to fleet-wide automation with Ansible.


The Certification Path: Administrator to Engineer

The RHCSA and RHCE are two of the most respected certifications in the Linux world because they are 100% hands-on. You don’t answer multiple-choice questions; you are given a live system and a set of tasks to complete. This learning path is designed to directly prepare you for that experience.

  1. RHCSA (Red Hat Certified System Administrator - EX200): This is the foundation. It proves you have the core skills to manage a single Red Hat Enterprise Linux (RHEL) server. Our first set of projects focuses on these competencies.
  2. RHCE (Red Hat Certified Engineer - EX294): This certification proves you can automate the RHCSA tasks at scale using Ansible. After mastering the “how” with the RHCSA labs, you will re-do those same tasks, but this time, you’ll automate them.

Lab Setup: Your Personal Data Center

To complete these projects, you need a small lab environment. You do not need physical servers.

  • Software: Use virtualization software like VirtualBox (free), KVM, or VMware Workstation.
  • Operating System: You don’t need a paid RHEL subscription. Use a bug-for-bug compatible, free alternative like Rocky Linux or AlmaLinux. Download the latest version (e.g., 9.x).
  • Your Lab: Create three minimal virtual machines:
    • control-node: This will be your main machine and, later, your Ansible control node.
    • managed-node-1: A target server.
    • managed-node-2: A second target server.

Part 1: The RHCSA Journey - Mastering the Single Server

These projects focus on the core skills of managing one machine. Perform these labs on managed-node-1.


Project 1: The Core Toolkit & Filesystem Management

  • Certification Objectives Covered:
    • Create and edit text files.
    • Locate, read, and use system documentation.
    • Manage file permissions and ownership.
    • Locate and interpret log files.
    • Archive and compress files.
  • Key Commands: ls, find, grep, journalctl, vim, nano, chown, chmod, tar, gzip.

Scenario: As a junior admin on managed-node-1, you’ve been asked to clean up a user’s home directory, secure some files, and archive old logs.

Success Criteria:

  1. A file named ~/project_docs/confidential.txt exists and is only readable and writable by the root user.
  2. All files in ~/user_logs ending in .log have been compressed into a single tarball named /opt/log_archive.tar.gz.
  3. The original log files in ~/user_logs have been deleted.
  4. You can successfully search the system journal for all logs related to the sshd service from the last 24 hours.

Implementation Hints:

  • Use touch and echo to create dummy files and directories.
  • chmod 600 <file> sets permissions to read/write for the owner only.
  • The find command can be combined with -exec to perform actions on found files. For example, find . -name "*.log" -exec rm {} \;.
  • The tar command’s flags are key: c (create), z (gzip), v (verbose), f (file).
  • Use journalctl -u sshd --since "1 day ago" to query systemd’s journal.

Learning Milestones: You will be comfortable navigating the filesystem, manipulating files, and performing basic log analysis from the command line. This is the bedrock of all Linux administration.


Project 2: Deploying a Web Server with a Secure SELinux Context

  • Certification Objectives Covered:
    • Install and manage software with dnf.
    • Manage and view services with systemd.
    • Configure basic firewall rules with firewall-cmd.
    • Manage SELinux security, including restoring default file contexts.
  • Key Commands: dnf install, systemctl status, systemctl enable --now, firewall-cmd --add-service, firewall-cmd --runtime-to-permanent, ls -Z, chcon, semanage fcontext, restorecon.

Scenario: You must deploy an Apache web server (httpd) on managed-node-1. For security reasons, the website’s files must be served from /srv/www/html, not the default /var/www/html. You must make this work and ensure it survives a reboot.

Why this project is critical: This is a classic RHCSA task that tests multiple domains at once. It intentionally makes you fight SELinux, the security system that trips up most new admins.

Success Criteria:

  1. The httpd package is installed.
  2. The httpd service is running and enabled to start on boot.
  3. The firewall allows incoming HTTP traffic.
  4. You have created an index.html file in /srv/www/html.
  5. When you run curl http://localhost from inside the VM, you see the content of your index.html.
  6. The SELinux context of /srv/www/html and its contents is httpd_sys_content_t and this setting is permanent.

Implementation Hints:

  1. After installing httpd and changing its configuration to point to /srv/www/html, it will fail. curl http://localhost will give a “Permission Denied” error.
  2. Check for SELinux denials with ausearch -m avc -ts recent or by looking in /var/log/audit/audit.log. The logs will tell you that httpd was denied access to a file with the wrong context.
  3. Use ls -Z /srv/www/html to see the default context is likely var_t or unlabeled_t. The httpd process is not allowed to read this.
  4. The “quick fix” is chcon -t httpd_sys_content_t /srv/www/html, but this is not persistent!
  5. The correct, persistent fix is to use semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" to add a new rule, then run restorecon -Rv /srv/www to apply it.

Learning Milestones: You will understand the fundamental troubleshooting workflow for SELinux, turning it from a mysterious obstacle into a predictable security tool.


Project 3: Flexible Storage with Logical Volume Management (LVM)

  • Certification Objectives Covered:
    • Create and manage partitions.
    • Create and manage LVM logical volumes.
    • Create and mount filesystems (xfs, ext4).
    • Configure systems to mount filesystems at boot.
    • Extend existing logical volumes.
  • Key Commands: lsblk, fdisk, pvcreate, vgcreate, lvcreate, mkfs.xfs, mount, lvextend, xfs_growfs.

Scenario: Your web server from Project 2 is running out of space. You have been given two new, unformatted 1GB virtual disks. You must combine them into a single, flexible storage volume using LVM, format it, mount it at /srv/www, and move your website data there. Later, a third disk is added, and you must extend the volume without losing any data.

Success Criteria:

  1. A volume group named web_vg exists, containing two physical disks.
  2. A logical volume named web_lv exists within web_vg.
  3. web_lv is formatted with the XFS filesystem and mounted persistently on /srv/www via /etc/fstab.
  4. (After extending) The logical volume is now larger, and the filesystem has been resized to use the new space. df -h shows the new, larger size.

Implementation Hints:

  1. Use lsblk to identify your new disks (e.g., /dev/sdb, /dev/sdc).
  2. Use fdisk to create a new partition on each disk of type Linux LVM.
  3. The LVM workflow is: pvcreate on the partitions, vgcreate to create a volume group from the physical volumes, lvcreate to carve a logical volume from the volume group.
  4. Use mkfs.xfs to format the logical volume (e.g., /dev/web_vg/web_lv).
  5. To extend, you’ll add the third disk to the VG (vgextend), extend the LV (lvextend), and then resize the filesystem online (xfs_growfs).

Learning Milestones: You will master LVM, the standard for flexible storage management in enterprise Linux. You will understand how to abstract physical disks into a single, resizable pool of storage.


Part 2: The RHCE Journey - Automating the Fleet with Ansible

Now, you will take the skills you just learned and automate them. These labs will be run from your control-node and will target managed-node-1 and managed-node-2.


Project 4: Your First Playbook - Automating the Web Server

  • Certification Objectives Covered:
    • Understand core Ansible components (inventory, modules, playbooks).
    • Write and execute a simple playbook.
    • Use common Ansible modules for software, services, and firewalls.
  • Key Ansible Modules: ansible.builtin.dnf, ansible.builtin.systemd, ansible.posix.firewalld.

Scenario: On your control-node, create an Ansible inventory file listing your two managed nodes. Write a single Ansible playbook that automates Project 2: it installs httpd, enables the service, and opens the firewall port on both managed nodes.

Success Criteria:

  1. Your Ansible inventory file is configured correctly and ansible all -m ping succeeds.
  2. After running your playbook (ansible-playbook -i inventory playbook.yml), httpd is installed and running on both managed-node-1 and managed-node-2.
  3. The firewall on both nodes has the http service enabled.
  4. Running the playbook a second time results in ok for all tasks, not changed.

Implementation Hints:

  • An Ansible playbook is a YAML file.
  • Each task in the playbook maps directly to a command-line action. The dnf module replaces dnf install, the systemd module replaces systemctl, etc.
  • The key to idempotency is using the state parameter in modules: state: present for a package, state: started and enabled: yes for a service.

Learning Milestones: You will grasp the fundamental concept of Infrastructure as Code. You’ll replace manual, imperative commands with a declarative playbook that defines a desired state, and let Ansible figure out how to get there.


Project 5: The Reusable Role - A Scalable Web Server Deployment

  • Certification Objectives Covered:
    • Create and work with Ansible roles.
    • Use Jinja2 templates to create custom files.
    • Use variables, handlers, and Ansible facts.
    • Manage secrets using Ansible Vault.
  • Key Ansible Modules: ansible.builtin.template, ansible.builtin.file, ansible.builtin.user.

Scenario: This project combines and professionalizes everything done so far. Convert your web server playbook into a proper Ansible role. This role should be configurable. It should use a template to deploy a custom index.html file that displays information about the server it’s on (e.g., its hostname and IP address). Finally, create a password for a webadmin user and store it securely using Ansible Vault.

Success Criteria:

  1. A directory structure for a role named apache exists.
  2. Your main playbook is now very simple, just calling the apache role.
  3. When you run the playbook, a custom index.html is deployed to each managed node. curl http://managed-node-1 shows “Hello from managed-node-1”, and curl http://managed-node-2 shows “Hello from managed-node-2”.
  4. A webadmin user is created on both nodes. Its password is encrypted in a vault file, not visible in plain text.

Implementation Hints:

  • Use ansible-galaxy init roles/apache to create the skeleton directory structure.
  • Move your tasks into roles/apache/tasks/main.yml.
  • Create a template file roles/apache/templates/index.html.j2. Inside it, you can use Jinja2 variables like {{ ansible_hostname }}.
  • Use ansible-vault create secrets.yml to create an encrypted file for your password. Load it in your playbook with vars_files.
  • A handler for restarting httpd should be placed in roles/apache/handlers/main.yml. The template task should notify this handler.

Learning Milestones: You will be thinking like an automation engineer. You are no longer writing simple scripts; you are building modular, reusable, and secure automation components, which is the core competency of the RHCE exam.


Summary

Project Certification Focus Key Technologies Difficulty
1. Core Toolkit & Filesystem RHCSA find, grep, tar, chmod Beginner
2. Deploying a Web Server RHCSA dnf, systemd, firewall-cmd, SELinux Intermediate
3. Flexible Storage (LVM) RHCSA fdisk, pvcreate, vgcreate, lvextend Intermediate
4. Your First Playbook RHCE Ansible, Playbooks, Idempotency Intermediate
5. The Reusable Role RHCE Ansible Roles, Templates, Vault Advanced