Chapter 16 — 3 Hours Hands Dirty with Linux Administration

Practical consolidation guide | Linux Administration

Purpose: Quickly revise the most important concepts from Chapters 1–15, then spend most of the session doing practical work. Use this as a single-glance lab sheet, not a replacement for the detailed chapters.

Quick-fire revision: concepts to recall

Keep answers short, then demonstrate each idea in the terminal.

Linux administration command reference

Use a permitted Linux terminal, such as your own Ubuntu/WSL2 environment, a virtual machine, or an instructor-approved training terminal. Some commands and options may not be available in restricted web terminals. Commands that require administrative privileges are marked accordingly; do not run them unless explicitly authorised.

Command safety notes

• Commands and options vary by distribution, shell, permissions, and installed tools.
• Read paths carefully before moving or removing anything. For this lab, create and remove only disposable files you made yourself.
• Avoid sudo, chmod, chown, user/group modification, and service changes in restricted shared terminals. Do not attempt to repair a restricted terminal's administrative configuration.
• Use ssh and scp only with hosts and accounts you are authorised to access. Verify host keys; never paste private keys or passwords into shared notes.
• journalctl and systemctl may be unavailable in Webminal or non-systemd environments. Record the limitation and continue with available read-only checks.
• For scheduled jobs, use absolute paths and test commands manually before scheduling them.
• For backup exercises, list archive contents before extracting and restore into a separate directory.

Hands-on Lab A — identity, navigation, files, and text

Goal: Establish your environment, create a safe workspace, and practise the core command set.

whoami
id
groups
pwd
echo "$SHELL"
uname -r
date
uptime

mkdir -p ~/linuxadmin-lab/source
cd ~/linuxadmin-lab
printf 'Linux Administration practice\n' > source/README.txt
printf 'INFO startup\nWARNING retry\nERROR sample failure\n' > source/sample.log
mkdir -p source/config
printf 'mode=practice\n' > source/config/lab.conf

ls -la
find source -type f -print
cat -n source/README.txt
grep -n "ERROR" source/sample.log
head -n 2 source/sample.log
tail -n 2 source/sample.log
wc -l source/sample.log
sort source/sample.log
file source/README.txt

Check yourself

1. Which command showed your effective username?
2. Which commands showed your current path and groups?
3. What is the difference between head and tail?
4. Why is grep useful when inspecting logs?
5. What does find source -type f exclude?

Hands-on Lab B — permissions, storage, and system health

Goal: Read permissions and resource information without changing system settings.

cd ~/linuxadmin-lab
ls -l source
ls -ld source source/config
id
df -h
du -sh ~/linuxadmin-lab
free -h
ps aux | head

Record:

• The owner, group, and permission characters shown for one file.
• The filesystem with the most relevant available-space information for your environment.
• One observation from memory and process output.
• Why permission changes should be deliberate and least-privileged.

Do not run chmod or chown in this exercise.

Hands-on Lab C — networking and remote access concepts

Goal: Inspect local network configuration and understand safe remote access.

ip addr show
ip route show
getent hosts example.com
curl -I https://example.com

If a command is unavailable or network access is restricted, record that fact rather than trying to bypass the restriction.

Answer:

1. Which interface appears to have an address?
2. What does the default route represent?
3. What role does DNS play?
4. What does curl -I request?
5. Before connecting with SSH, what should you verify about the host key and destination?

Do not attempt remote access unless an approved host and account have been provided.

Hands-on Lab D — archive, checksum, and restore

Goal: Create a backup of the practice files, validate it, and restore to a separate location.

cd ~/linuxadmin-lab
tar -czf practice-backup.tar.gz source
tar -tzf practice-backup.tar.gz
sha256sum practice-backup.tar.gz > practice-backup.sha256
sha256sum -c practice-backup.sha256

mkdir -p restore-test
tar -xzf practice-backup.tar.gz -C restore-test
find restore-test -type f -print
cat restore-test/source/README.txt

Record the checksum result and one file-content verification.

Quick-fire: Explain the difference between a backup and synchronization. What do RPO and RTO mean? Why is a restore test necessary?

Hands-on Lab E — process, logs, and incident triage

Goal: Use evidence before recommending action.

Run available read-only checks:

date
uptime
ps aux | head
df -h
free -h

If available in your environment, inspect recent system journal messages:

journalctl -n 30

Scenario: A fictional service user reports that an application is unavailable after a recent update.

Write a short triage note with:

Do not restart services or modify system files unless the instructor provides an approved disposable environment.

Hands-on Lab F — shell scripting and scheduling

Goal: Create a small repeatable report script and inspect scheduling without changing system configuration.

Create a script:

cd ~/linuxadmin-lab
cat > system-report.sh <<'EOF'
#!/usr/bin/env bash
printf 'Linux Administration quick report\n'
printf 'Date: '
date
printf 'User: '
whoami
printf '\nWorking directory: '
pwd
printf '\nDisk summary:\n'
df -h
printf '\nMemory summary:\n'
free -h
EOF
bash -n system-report.sh
bash system-report.sh

Inspect the script and its output:

cat -n system-report.sh

Optional: list existing user cron entries without editing them:

crontab -l

A “no crontab” message or a missing command can be normal in a restricted environment. Do not create a scheduled job unless there is time, an approved environment, and a clear need. Explain why scheduled scripts should use predictable paths and handle failures.

Hands-on Lab G — package, service, and security review

Goal: Connect operational concepts to safe administrative decisions.

Answer in your lab notes; use read-only commands only where available.

1. Why should software be installed from trusted repositories?
2. What evidence would you collect before investigating a failed service?
3. What is the difference between a process and a service?
4. Why should logs avoid passwords, tokens, and unnecessary personal data?
5. What is the purpose of least privilege?
6. Why should backups be stored separately from the source where feasible?
7. What should be checked after a security update?
8. Why should recovery instructions be tested rather than merely documented?

Optional read-only checks in a suitable systemd-based VM:

systemctl is-active ssh
systemctl --no-pager status ssh
journalctl -n 30

The service may have a different name or may not be installed. Do not enable, restart, install, or alter services as part of this review.

Quick-fire practical challenge

Complete these without copying the full command sequence from above:

1. Print your username, groups, and current directory.
2. Create a nested practice directory and three text files.
3. Find all .txt files below the practice directory.
4. Search a sample log for the word ERROR.
5. Display disk and memory summaries.
6. Inspect one file's owner and permission notation.
7. Create an archive of the sample directory and list its contents.
8. Verify the archive checksum.
9. Restore the archive to a new directory and verify one file.
10. Write a short incident note that separates facts from assumptions.

Final quick-fire review

Answer in one or two sentences each.

1. What is the difference between an absolute and a relative path?
2. What is the purpose of pipes (|)?
3. What do df -h and du -sh measure differently?
4. Why should you inspect an archive before extracting it?
5. What does a checksum verify—and what does it not verify?
6. Why are logs and timestamps important during troubleshooting?
7. Why should SSH host keys be verified?
8. What is the difference between RPO and RTO?
9. Why should scripts quote variable expansions such as "$HOME"?
10. Why is “one controlled change, then verify” safer than making many changes at once?

Answer cues

1. Absolute paths start from the root; relative paths are interpreted from the current directory.
2. A pipe passes one command's output to another command as input.
3. df reports filesystem capacity/availability; du estimates space used by selected files/directories.
4. It helps detect unexpected paths and avoid extracting an untrusted archive blindly.
5. It checks that file content matches a recorded checksum; it does not prove completeness, safe storage, or successful recovery.
6. They establish a timeline and help correlate events with symptoms.
7. It helps detect unexpected host identity changes and reduces the risk of connecting to an impostor.
8. RPO concerns acceptable data loss; RTO concerns target recovery time.
9. Quoting generally preserves spaces and prevents unintended word splitting and pathname expansion.
10. It makes cause and effect easier to understand and reduces unintended impact.

Lab completion checklist

• Command reference reviewed and practised
• Identity, navigation, file, and text commands completed
• Permissions and system-resource observations recorded
• Network outputs or environment limitations recorded
• Backup archive created and listed
• Checksum verified and restore tested separately
• Shell script syntax-checked and run
• Incident-triage note completed
• Security, service, package, and recovery questions answered

Key takeaway: Observe first, make changes deliberately, protect data, verify outcomes, and document evidence. A good Linux administrator does not merely run commands—the administrator understands their effects and confirms the result.

Linux Administration · Practical Consolidation Guide