Capstone: Setting Up the Same Service on Three Different Distributions

Comparative Linux Distributions

Chapter 12 · Capstone: Setting Up the Same Service on Three Different Distributions

One real service — a small static website served by Nginx — deployed identically in intent across Debian/Ubuntu, Fedora, and Arch. The goal isn't the website itself; it's documenting precisely where eleven chapters' worth of differences actually show up in practice, and — just as tellingly — where they don't.

Step 1 — Installing Nginx (Where the Package Manager Chapter Pays Off)

# Debian / Ubuntu sudo apt install nginx # Fedora sudo dnf install nginx # Arch sudo pacman -S nginx

This is the single most visible divergence across the whole capstone — three genuinely different commands, exactly as Chapter 6 catalogued, for the identical underlying action.

Step 2 — Enabling & Starting the Service (Where It's Genuinely Identical)

# Identical on all three — Chapter 8's own convergence point sudo systemctl enable --now nginx
The one step this capstone didn't need to write three times
Debian/Ubuntu, Fedora, and Arch all converged on systemd, per Chapter 8 — this is the genuine payoff of that convergence. Managing the service itself requires zero distribution-specific knowledge at all, in sharp contrast to Step 1.

Step 3 — Firewall Configuration (A New, Real Divergence)

Fedora runs firewalld active by default, requiring an explicit rule to permit HTTP traffic (sudo firewall-cmd --add-service=http --permanent && sudo firewall-cmd --reload). Debian/Ubuntu commonly use ufw, if installed and enabled at all (sudo ufw allow 'Nginx HTTP'). Arch, consistent with Chapter 4's own "you configure everything yourself" philosophy, has no firewall active by default at all — nothing to configure here unless one was deliberately set up beforehand.

Step 4 — SELinux, Fedora Only (Chapter 3's Own Payoff)

Serving files from Nginx's own default document root works immediately on Fedora. Serving files from a custom, non-standard directory instead requires setting the correct SELinux context first — exactly the extra, genuinely necessary step Chapter 3 warned about:

# Fedora only — required when serving from a non-default directory sudo semanage fcontext -a -t httpd_sys_content_t "/srv/mysite(/.*)?" sudo restorecon -Rv /srv/mysite

Neither Debian/Ubuntu nor Arch require this step at all, since neither runs SELinux by default — a direct, concrete instance of Chapter 3's own warning finally showing up in a real deployment.

Step 5 — Verifying the Service (Identical Again)

# Identical on all three curl localhost
Chapter-Attribution Table
  • Chapter 2, 3, 4 — the three package managers themselves (Step 1)
  • Chapter 6 — the direct package-manager-syntax comparison, paid off in Step 1
  • Chapter 8 — systemd's convergence across three families, paid off in Step 2
  • Chapter 4 — Arch's own "no default assumed" philosophy, showing up again in Step 3's firewall material
  • Chapter 3 — SELinux enabled by default on Fedora, paid off concretely in Step 4
Honest scope note
This capstone deliberately covers only three of the five families this course discussed — Alpine (Chapter 5) and Raspberry Pi OS (Chapter 10) both already received their own dedicated, hardware/footprint-specific treatment and don't need a fourth or fifth repetition of the same basic install-a-service exercise. This also stops short of a full production hardening pass — TLS/certificates belong to the site's own HTTPS/TLS Fundamentals course — and doesn't automate any of this via Ansible, even though Chapter 6 covered its own package-module abstraction; doing so by hand here was deliberately chosen to make each distribution's own real differences visible rather than hidden behind another layer of tooling.

Hands-On Exercises

Exercise 1

Explain why Step 2 (enabling and starting the service) required no distribution-specific research at all, while Step 1 required three genuinely different commands.

📄 View solution
Exercise 2

A colleague follows this capstone's own steps to serve a site from a custom directory on Ubuntu and is confused why the SELinux commands in Step 4 don't apply or do anything useful there. Explain why.

📄 View solution
Exercise 3

Explain why this capstone's own honest scope note says Alpine and Raspberry Pi OS didn't need to be included here, rather than treating their absence as an oversight.

📄 View solution

Chapter 12 Quick Reference

  • Diverges: package manager (Step 1), firewall tooling (Step 3), SELinux (Step 4, Fedora only)
  • Identical: systemd service management (Step 2) and basic verification (Step 5) — the real payoff of Chapter 8's own convergence
  • Real differences between distributions show up unevenly — some steps genuinely diverge, others don't at all
  • This closes the full Comparative Linux Distributions course — twelve chapters spanning four families, package managers, release models, init systems, governance, Raspberry Pi OS, and this final worked capstone