Chapter 22: Review and practice
From requirements to evidence
You can operate a system when you can connect each requirement to evidence, not merely repeat commands from one lesson. This chapter ties the course together with one small service, a status portal, and three habits: write the contract first, build in a sensible order, and prove each requirement in a way a colleague would accept.
- Turn a service description into requirements with a named proof for each.
- Build in an order that keeps each step testable.
- Tell apart configuration, live state, a client operation and a lifecycle test.
The service contract
The portal is an internal web page, "Portal status: OK", on servera. Before touching anything, write down what "done" means:
| Requirement | Course chapters | Proof |
|---|---|---|
Content owned by portaladm, group portal; web server may read it | accounts, permissions, ACLs | id, ls -l, getfacl |
httpd installed from the approved repositories | software | rpm -q httpd |
| Running now and at boot | services | systemctl is-active, is-enabled |
| SELinux enforcing; content and port labelled | SELinux | getenforce, ls -Z, semanage ... -l |
| Only the partner serverb may reach port 8090 | firewall, network | firewall-cmd --list-all, requests from two hosts |
| Persistent journal, daily backup, tested restore | logs, backups, timers | ls -d /var/log/journal, systemctl list-timers, a restore |
Each row is a layer you already know. Select one:
One requirement, one layer: Select a requirement of the portal.
Four kinds of proof
- Configuration shows saved intent: a unit file, a stored context mapping, a permanent firewall rule, an fstab line.
- Live inspection shows the current state: a process, a listener, an effective policy.
- A client operation shows useful behaviour: the HTTP body, the file actually read, the permitted login.
- A lifecycle test shows retention: the same operation after reload, logout, restart or reboot.
Each has limits. An active daemon does not prove the content is right. A request from servera itself does not prove the firewall lets the partner in. A restored file does not prove the web server can read it. The strongest evidence combines all four.
Build in order
A good build order: Step through delivering the portal.
Test after every step. A failure found right after a change has one suspect; a failure found at the end has all of them.
Collect evidence
This is what a finished portal looks like to the checker, and to you:
Check your understanding
- An active httpd service proves that...
- Which proof shows that a rule survives a reboot?
- Why test from the partner and from a stranger?
- Which comes first when building a service?
- The web server cannot read the content, though the owner and group are right. Which two layers do you check?
- A backup exists. What else must you do before calling the recovery ready?