Learn › Linux Foundations › Capstone: Operate server1
Final test: Chapter 23, the capstone of Linux Foundations. Twenty-five objectives across the whole track on a real Debian 12 server in three tiers (1 to 5 foundation, 6 to 15 working, 16 to 25 independent): evidence of what runs, what changed and what failed saved in files, the original kept, bounded changes to a file, permissions and an archive, verification, delivery over SSH and a handover note. Ninety minutes, graded from the state of the machine.
This chapter covers the following topics:
This is the last chapter of the track. It puts the commands of Chapters 1 to 22 in the order a working operator uses them, on one directory built for the purpose. A lab-only helper, capstone-reset, lets you undo practice changes. It ends in the capstone lab, which tests 25 resulting outcomes on a real server.
What you already know: the general Linux commands in this chapter were taught in Chapters 1 to 22, from ls (Section 2.4) and the redirect > (Section 11.2) to diff (Section 13.19), script (Section 17.8) and tar (Chapter 19). Each exercise names the section it comes from.
Objectives
After this chapter you can:
The terminal exercises in this chapter use the real shared practice machine. Start it in the workspace and wait until it is ready, then enter the requested commands there. Those commands can change this disposable machine; capstone-reset restores the prepared capstone directories when needed. A guided step records the requested command after the shell reports completion. It does not pass an assessment objective. The assessment at the end starts a separate Debian 12 server and grades 25 objectives from its state. Follow startup status and current session time in the workspace.
Five questions before the material. A wrong answer costs nothing: the explanation states the fact and names the section that teaches it.
>>> Reading changes nothing and tells you what is there: ls -l shows the mode, owner and size, cat shows the content, date -r shows when it last changed. A change made before that has nothing to be compared with. Section 23.2.
>>> Output on the screen is gone when the terminal closes. A file named for what it proves stays, and the next command, or the next person, can read it, count it or compare it. Section 23.3.
>>> cp writes a second file with the same bytes and leaves the original where it is. mv would take the file away from the name the site reads, and touch creates an empty file. Section 23.4.
>>> diff shows which lines differ between the two files you named. Check that its report contains the intended line change and no other differences between these two files. It does not prove that a service used the new setting. ls -l and wc -l can agree while the content differs. Section 23.5.
>>> script -c runs one command, shows its output and writes the same output to FILE, framed by a start line and an end line that carries the exit code. Section 23.6.
A job task is the work a role exists to do, stated as outcomes. For a junior operator in the first week on a Linux server it has four parts, in this order:
1. Collect evidence, output saved in files, of what is running, what changed and what failed. 2. Make small bounded changes: a change to one named thing with a known state before and after, such as one line of a file, one permission or one archive. 3. Verify each change. 4. Hand over a record of what was done.
Chapters 1 to 22 taught the commands. This chapter puts them in that order on ~/capstone, a directory built for it that holds release 1.3.0 of the Northwind Bakery site as it is staged on server1. Every path in this chapter is written from ~, so each command works from any directory. A long session moves around, and a path that starts at ~ still means the same file.
You are in your home directory. Print the file that describes the directory, ~/capstone/README.txt:
prompt: admin@server1:~$ answer: cat ~/capstone/README.txt ||| cat capstone/README.txt ||| cat /home/admin/capstone/README.txt output: capstone: the Chapter 23 lab directory on server1 ================================================= Release 1.3.0 of the Northwind Bakery site as staged on server1, with its configuration, its logs and the backup of release 1.2.0.
site/ release 1.3.0: the pages, assets/ and VERSION config/ site.conf (in use), site.conf.bak (the copy from before the last change), db.env and cache.conf logs/ app.log and access.log for 2026-01-15 backups/ site-1.2.0.tar.gz, the backup of release 1.2.0 shared/ the upload directory of the webteam group bin/ healthcheck, which summarizes logs/app.log
Evidence you collect goes in evidence/ and what you hand over goes in handover/. Neither exists until you create it.
capstone-reset rebuilds site/, config/, logs/, backups/, shared/ and bin/ as they were when the machine booted, and removes anything else inside them. It never touches evidence/ or handover/.
capstone-reset config rebuild one directory capstone-reset all rebuild every prepared directory hint: Section 5.1. The printing command, then the path ~/capstone/README.txt.
Six prepared directories. site/ is what the web server would publish, config/ how it is set up and logs/ what happened on 2026-01-15. backups/ holds the release before this one, shared/ is where the webteam group from Chapter 20 puts uploads, and bin/ holds a program. Two directories do not exist yet: evidence/ and handover/ are yours to create. capstone-reset is a program installed for this chapter, and Section 23.7 uses it.
tree from Section 2.7 draws a directory and everything under it. You are in your home directory. Draw ~/capstone:
prompt: admin@server1:~$ answer: tree ~/capstone ||| tree /home/admin/capstone ||| tree capstone output: /home/admin/capstone ├── README.txt ├── backups │ └── site-1.2.0.tar.gz ├── bin │ └── healthcheck ├── config │ ├── cache.conf │ ├── db.env │ ├── site.conf │ └── site.conf.bak ├── logs │ ├── access.log │ └── app.log ├── shared │ └── README.txt └── site ├── VERSION ├── about.html ├── assets │ ├── site.css │ └── site.css.bak ├── index.html ├── index.html.bak ├── menu.html └── menu.html.bak
8 directories, 18 files hint: Section 2.7. The tree command, then the path ~/capstone.
Eight directories, counting capstone itself, and eighteen files. Three names in site/ end in .bak: copies an editor leaves behind when a file is saved, which a release should not ship. A tree is a read: it changed nothing, and it is the quickest way to see the shape of work before you start.
Reading before changing means looking at a thing with commands that change nothing before you run one that does. The reads give you the state a change will be compared with, and they find problems nobody listed. Three reads cover most things. ls -l shows the mode, owner, size and time (Section 2.4), cat shows the content (Section 5.1), and date -r shows when the content last changed (Section 16.5).
You are in your home directory. List ~/capstone/config in long form:
prompt: admin@server1:~$ answer: ls -l ~/capstone/config ||| ls -l capstone/config ||| ls -l /home/admin/capstone/config output: total 16 -rw-r--r-- 1 admin admin 106 Jan 15 2026 cache.conf -rw-r--r-- 1 admin admin 129 Jan 15 2026 db.env -rw-r--r-- 1 admin admin 166 Jan 15 2026 site.conf -rw-r--r-- 1 admin admin 165 Jan 15 2026 site.conf.bak hint: Section 2.4. The long listing option -l, then the path ~/capstone/config.
Four files, each with the mode rw-r--r--: the owner reads and writes, and the group and everyone else read. For three of them that is ordinary. db.env holds the database settings, a password among them, and the last r of its mode lets every account on server1 read it. The read found that, and changed nothing. Section 20.3 taught the mode that closes it.
The change this chapter makes is to ~/capstone/config/cache.conf, the page cache settings, which no lab objective grades. You are in your home directory. Print it:
prompt: admin@server1:~$ answer: cat ~/capstone/config/cache.conf ||| cat capstone/config/cache.conf ||| cat /home/admin/capstone/config/cache.conf output:
cache_enabled = yes cache_ttl = 300 cache_max_mb = 64 hint: Section 5.1. The printing command, then the path ~/capstone/config/cache.conf.
A comment and three settings. cache_ttl, the number of seconds a cached page is kept, is on line 3 with the value 300. The line number matters in Section 23.5, where diff reports a change by the lines it touched.
Section 16.5 read the modification time of a file with date -r, and Section 1.8 chose the format %F, the date written year first as YYYY-MM-DD. The two options combine: -r picks the moment and +%F picks how it is written. You are in your home directory. Print the date ~/capstone/logs/app.log last changed:
prompt: admin@server1:~$ answer: date -r ~/capstone/logs/app.log +%F ||| date +%F -r ~/capstone/logs/app.log ||| date -r capstone/logs/app.log +%F output: 2026-01-15 hint: Section 16.5. The option -r with the path ~/capstone/logs/app.log, then the format +%F from Section 1.8.
The log last changed on 2026-01-15, the day it covers. The modification date helps place the file in a timeline, but it does not establish what caused a problem. Compare it with the incident time and inspect the file and service evidence before drawing a conclusion. That date is one fact worth saving, which is the next section.
Evidence is output that proves a fact, saved in a file named for the fact. The screen is not evidence: it scrolls, and it is gone when the terminal closes. A file stays, and the next command or the next person can read it, count it or compare it.
One directory for all of it keeps the evidence together and apart from the files it describes. You are in your home directory. Create ~/capstone/evidence:
prompt: admin@server1:~$ answer: mkdir ~/capstone/evidence ||| mkdir capstone/evidence ||| mkdir /home/admin/capstone/evidence output: hint: Section 6.2. The directory-making command, then the path ~/capstone/evidence.
Silent, as mkdir is when it succeeds. The capstone lab uses the same directory, and a second one, ~/capstone/handover, for what you hand over.
Section 11.2 taught the redirect: > sends the output of a command into a file, creating it or replacing what was in it. ~/capstone/logs/app.log is the application log for 2026-01-15, and each line names a level, INFO, WARN or ERROR, then the part of the site that wrote it. A WARN line reports a problem that did not stop the work.
You are in your home directory. Save every WARN line of the log to ~/capstone/evidence/warnings.txt:
prompt: admin@server1:~$ answer: grep WARN ~/capstone/logs/app.log > ~/capstone/evidence/warnings.txt ||| grep WARN capstone/logs/app.log > capstone/evidence/warnings.txt output: hint: Section 13.3. grep with the pattern WARN on ~/capstone/logs/app.log, then > and the file ~/capstone/evidence/warnings.txt.
Nothing on the screen: the lines went into the file. That is the purpose of the redirect and also its risk, because > replaces a file that already exists. Name each evidence file after what it proves, and use >> from Section 11.4 when you mean to add.
You are in your home directory. Print the evidence file ~/capstone/evidence/warnings.txt:
prompt: admin@server1:~$ answer: cat ~/capstone/evidence/warnings.txt ||| cat capstone/evidence/warnings.txt ||| cat /home/admin/capstone/evidence/warnings.txt output: 2026-01-15 05:15:03 WARN cache miss rate above 50 percent 2026-01-15 06:03:09 WARN db query on orders took 4200 ms 2026-01-15 06:26:02 WARN cache miss rate above 50 percent 2026-01-15 07:02:31 WARN web upload rejected: larger than 25 MB 2026-01-15 07:26:05 WARN cache miss rate above 50 percent hint: Section 5.1. The printing command, then the path ~/capstone/evidence/warnings.txt.
Five WARN lines, three of them from the cache. The file now says so to anyone who opens it, and nobody has to run grep again to know. The same filter on ERROR finds what failed, which is what the capstone lab asks for.
Keeping the original means copying a file before you change it. The copy is the state before the change, so a later comparison shows exactly what changed, and it is the undo: copying it back restores the file. The usual name is the same name with .orig added. cp from Section 6.7 writes a second file with the same bytes and leaves the first in place.
You are in your home directory. Copy ~/capstone/config/cache.conf to ~/capstone/config/cache.conf.orig:
prompt: admin@server1:~$ answer: cp ~/capstone/config/cache.conf ~/capstone/config/cache.conf.orig ||| cp capstone/config/cache.conf capstone/config/cache.conf.orig output: hint: Section 6.7. The copying command, the source ~/capstone/config/cache.conf, then the new name ~/capstone/config/cache.conf.orig.
Silent. Two files now hold the same four lines, and only one of them is about to change.
A copy that failed without a message is no undo, so prove it. cmp from Section 19.5 compares two files byte for byte: it prints nothing and succeeds when they are identical, and names the first difference otherwise. && from Section 10.5 runs the next command only when the one before it succeeded, so a line can be printed only when cmp found the files identical.
You are in your home directory. Compare ~/capstone/config/cache.conf with ~/capstone/config/cache.conf.orig, and print copy verified if they match:
prompt: admin@server1:~$ answer: cmp ~/capstone/config/cache.conf ~/capstone/config/cache.conf.orig && echo copy verified ||| cmp capstone/config/cache.conf capstone/config/cache.conf.orig && echo copy verified output: copy verified hint: Section 10.5. cmp with the two paths ~/capstone/config/cache.conf and ~/capstone/config/cache.conf.orig, then && in front of echo copy verified.
copy verified came from echo, and echo ran only because cmp succeeded. The words are a record that is true by construction: a chain that prints them only on success cannot print them for a bad copy. The capstone lab asks for a note built the same way.
sed -i from Section 13.22 edits a file in place: the substitution s/old/new/ is applied to every line and the result is written back to the same file. It changes one line without opening an editor; nano from Section 19.1 does the same job by hand.
You are in your home directory. Change cache_ttl = 300 to cache_ttl = 600 in ~/capstone/config/cache.conf:
prompt: admin@server1:~$ answer: sed -i 's/cache_ttl = 300/cache_ttl = 600/' ~/capstone/config/cache.conf ||| sed -i 's/cache_ttl = 300/cache_ttl = 600/' capstone/config/cache.conf output: hint: Section 13.22. sed -i with the substitution s/cache_ttl = 300/cache_ttl = 600/ in single quotes, then the path ~/capstone/config/cache.conf.
Silent. This command targets one named line of one named file, with the original bytes kept in cache.conf.orig. The next comparison checks whether that intended text change took effect.
Verification checks the intended result and relevant properties that must stay intact. For this text edit, diff from Section 13.19 compares the original and changed files. It reports their changed lines, or prints nothing when they are identical. It does not show whether the site loaded this configuration.
You are in your home directory. Compare ~/capstone/config/cache.conf.orig with ~/capstone/config/cache.conf:
prompt: admin@server1:~$ answer: diff ~/capstone/config/cache.conf.orig ~/capstone/config/cache.conf ||| diff capstone/config/cache.conf.orig capstone/config/cache.conf output: 3c3 < cache_ttl = 300 --- > cache_ttl = 600 hint: Section 13.19. diff with the original first, ~/capstone/config/cache.conf.orig, then ~/capstone/config/cache.conf.
3c3 reads: line 3 of the first file is changed into line 3 of the second. The < line is the original and the > line the new one. One changed line, and it is the one intended. A second change in this report would be a change you did not mean to make.
diff also answers with its exit status (Section 10.3), the number a command returns when it ends. It is 0 when the files are identical, 1 when they differ and 2 when diff could not compare them. Sending the report to /dev/null (Section 11.9) keeps only that answer, which $? (Section 10.4) prints
Practice Chapter 23. Capstone: Operate server1 in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.