Linux Administration on RHEL 9 and 10: Course Roadmap and Skills Baseline

Anil Jalela · Published Sep 3, 2026 · 9 min read

A useful Linux administrator does more than remember commands. The job is to establish the expected state, gather evidence without destroying it, identify the responsible layer, make the smallest controlled change, and prove the result. This course uses RHEL 10 as the primary lab platform and calls out RHEL 9 differences where they affect an operator. The private question bank supplied for this course is treated as a list of concepts, not an authority: every retained question has been rewritten, and every procedure must stand on current documentation and observable system state.

Know what this course does and does not promise

The lessons cover local administration of supported RHEL 9 and 10 systems: shell use, identity, processes, systemd, packages, storage, networking, firewalling, SELinux, logs, performance, SSH, file services and DNS. Commands are examples, not permission to alter an unidentified production host. Every lab begins with an inventory and ends with evidence.

Generic Linux behavior is explained without pretending every distribution is identical. Package names, default services, boot tooling, security policy and network ownership are verified on the target release. Material about mail transport is placed in the separate Linux MTA Operations track because SMTP queues, relay policy and sender identity need deeper treatment than a general administration lesson can provide.

Use one diagnostic loop on every system

Prepare a course lab before changing anything

1. Choose a disposable target. Use a VM or approved lab subscription, not the only copy of a business service.
2. Record identity. Capture hostname, release, kernel, boot mode, addresses, storage and virtualization context.
3. Protect access. Keep console access and a second privileged session before changing SSH, networking, PAM, sudo or firewall policy.
4. Define evidence paths. Create a root-owned lab directory for command output, configuration copies and timestamps without storing credentials.
5. Set failure boundaries. State when to stop, what must remain reachable and which command restores the reviewed state.
6. Test both outcomes. A service is not accepted merely because one local request succeeded; test the intended client path and an intended denial.

Capture a read-only host baseline

date -u --iso-8601=seconds
hostnamectl
cat /etc/redhat-release
uname -r
systemd-detect-virt
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
ip -brief address
ip route show
ss -lntup
systemctl --failed
journalctl -p warning..alert -b --no-pager

• hostnamectl identifies the operating-system and virtualization context reported by systemd. Treat inventory data as evidence, not as proof that every package is current.
• ss -lntup shows listening TCP and UDP sockets with process ownership when permissions allow. A listening socket does not prove a firewall or upstream path permits access.
• systemctl --failed is a starting point. A service can be active while its application is unhealthy, and an inactive optional unit is not automatically an incident.
• Preserve UTC timestamps with every capture so journal, monitoring and change records can be correlated.

Evidence and acceptance criteria

Worked scenario: “the server is slow” is not a diagnosis

A user reports that a server became slow after lunch. The administrator does not clear caches, reboot or kill the largest process. They record the report time and affected transaction, compare load and pressure with the normal baseline, inspect CPU run queue, memory pressure, storage latency, network retransmission and application logs, then identify one backup job saturating the same storage used by the application. Pausing that approved job is a bounded mitigation; rescheduling it and adding I/O evidence is the correction.

The important result is not that response time improved. It is that the team can explain the causal resource, show the before-and-after evidence, and detect the same contention before users report it.

Practical how-to cases

umask 077
lab="$PWD/rhel-lab"
mkdir -p "$lab"
date -u --iso-8601=seconds | tee "$lab/time.txt"
hostnamectl | tee "$lab/identity.txt"
stat -c '%A %U:%G %n' "$lab"

systemctl status chronyd --no-pager
systemctl cat chronyd
systemctl show chronyd -p MainPID -p FragmentPath -p DropInPaths
chronyc tracking
journalctl -u chronyd -b --no-pager | tail -30

ss -lntup
ip -brief address
ip route
firewall-cmd --get-active-zones
curl --fail --silent --show-error http://127.0.0.1:8080/

date -u --iso-8601=seconds
systemctl --failed
journalctl -b -p warning..alert --no-pager
findmnt --verify
nmcli connection show --active

Independent practice tasks

1. Inventory an unfamiliar lab VM and identify five facts that must be confirmed before any change.
2. Diagnose a stopped lab service without starting it until you can explain the failed layer.
3. Write acceptance and rollback criteria for a firewall change that must preserve SSH.
4. Create a 20-minute timed baseline exercise using only locally installed documentation.

For this lesson on RHEL Linux Administration Course Roadmap, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: rebooting or killing processes because a host is “slow” destroys transient evidence and can extend an outage. Capture resource and application state first.
• Unsafe: copying commands from a different RHEL major release without checking package, path and service ownership can replace a working control plane.
• Unsafe: collecting secrets, private keys, full environment dumps or customer data in a course evidence folder expands the incident and privacy boundary.

Rewritten knowledge checks

Lab: establish an evidence-first administration baseline

1. Create a RHEL 9 or 10 VM snapshot and document how the console is reached if networking fails.
2. Run the baseline commands and annotate which output identifies identity, resources, ownership, policy and symptoms.
3. Choose one harmless service such as chronyd. Record its unit state, process, sockets if any, recent journal and configuration source.
4. Create one intentional lab-only failure, such as an invalid copy of a configuration checked with a syntax tool. Do not activate it.
5. Write the expected state, observed failure, responsible layer, safe correction and acceptance test.
6. Restore the VM snapshot only after preserving the evidence needed to explain what happened.

Primary references

• RHEL 10 configuring basic system settings
• RHEL 10 documentation
• RHEL 9 documentation