Field notesAUWENSearch
Explore Systems
← tools

Red Hat Enterprise Linux operations

RPM packages, systemd services, SELinux, and controlled maintenance.

3 lessons published · Updated 2026-09-14

Before you begin

Complete the Linux foundations. Use a disposable RHEL VM with console access and repositories configured for its installed major version. Package listings need no root; some logs and security inspection require authorized elevation.

Working toward: Maintain a documented RHEL service with a tested update and recovery procedure.

Read each explanation, run the example in your own lab, and attempt the exercise before opening its answer. Published lessons are ready to study; unfinished roadmap topics remain planned.

Validation: Based on upstream documentation. Platform-specific labs require the learner’s matching environment and are not execution-tested here.

1. Know what is installed

RPM tracks installed packages; DNF resolves packages and dependencies through repositories. The running kernel can differ from the newest installed kernel until a reboot. Inventory before planning maintenance.

cat /etc/redhat-release
uname -r
rpm -q kernel openssh-server
dnf repolist

What to expect

Distribution version, running kernel, installed package versions and configured repositories. A missing package is reported explicitly.

Your turn

Why might rpm report a newer kernel than uname?

Show answer and reasoning
A newer kernel may be installed but not booted. Confirm boot configuration and schedule a tested reboot; installing a package does not prove it is active.

Watch for: Do not mix repositories from incompatible major releases.

Link to this lesson

2. Read service evidence

A unit may be enabled for startup but currently failed. journalctl can limit evidence to this boot and this service. The SSH daemon is commonly named sshd on RHEL.

systemctl status sshd --no-pager
systemctl is-enabled sshd
journalctl -u sshd -b --no-pager -n 30

What to expect

Current SSH unit status, enablement state, and recent accessible logs. A VM without SSH installed will report no unit.

Your turn

A service is enabled and failed. Which fact answers whether it is serving now?

Show answer and reasoning
The active state and application reachability answer current operation. Enablement describes startup configuration. Inspect logs before restarting.

Watch for: Restarting can disrupt access and erase transient evidence; retain console access.

Link to this lesson

3. Inspect security controls

SELinux labels and policy add mandatory access checks beyond Unix mode bits. firewalld zones group network policy. An application failure can involve either control, neither, or both. Gather specific evidence.

getenforce
ls -Zd /var/log
# On a lab host with firewalld, with permission:
sudo firewall-cmd --get-active-zones

What to expect

SELinux mode, a directory context, and active firewall zones if the daemon is running.

Your turn

Why is disabling SELinux an inadequate permanent fix for a denied web file?

Show answer and reasoning
It removes a security boundary without correcting labels or the access design. Check the audit denial, expected context and documented policy, then make a narrow tested correction.

Watch for: Do not run chmod 777, flush all rules, or disable enforcement to conceal the cause.

Link to this lesson

Path to advanced

In-progress stages identify the lessons already published. All other listed topics remain planned. Each addition needs teaching, a reproducible lab, failure cases, and a checkpoint before the capstone.

  1. Manage the host

    Users, sudo, repositories, storage, NetworkManager and SSH.

    PLANNED

  2. Constrain services

    SELinux contexts and booleans, firewalld zones, audit evidence and service accounts.

    PLANNED

  3. Maintain reliably

    Patch rehearsal, dependency checks, reboot planning, monitoring and recovery drills.

    PLANNED

References

Original AUWEN lessons, with upstream documentation for further study and version checks.

All learning paths and update notes →