0:00–0:20
Command Reference
0:20–1:00
Scenario A — DHCP & DNS
1:00–1:40
Scenario B — Nginx & SSL
1:40–2:00
Open Lab / Q&A
0:00 – 0:20Command Reference · 20 min
Quick-fire command reference — Weeks 3 and 4
- Week 3 — DHCP:
sudo systemctl status isc-dhcp-server · cat /var/lib/dhcp/dhcpd.leases
- Week 3 — DNS:
sudo named-checkzone yourname.net /etc/bind/db.yourname.net · dig @[server] host.yourname.net · dig @[server] -x [IP]
- Week 4 — DNS views:
sudo named-checkconf · test resolution from an internal and an external client
- Week 4 — Nginx:
sudo nginx -t · sudo systemctl reload nginx · sudo tail -f /var/log/nginx/error.log
0:20 – 1:00Scenario Walk-through A · 40 min
A DHCP reservation that won't take, and a zone that won't transfer
- Scenario 1 — DHCP: A student adds a host reservation for S2 but S2 keeps getting a different address. Walk through the checklist: correct MAC address in dhcpd.conf, service restarted (not just config saved), any stale lease cleared on the client, and no syntax error swallowed silently — always check
sudo dhcpd -t-equivalent validation or the journal after a restart.
- Scenario 2 — DNS: A secondary server isn't picking up a zone edit made on the primary. Walk through: was the serial number incremented, did the primary send a NOTIFY, does the secondary's zone file (or its transfer log) show a recent transfer, and what
dig query confirms which server actually answered.
- Key habit reinforced: named-checkzone and named-checkconf catch syntax errors before they become live problems — run them before every reload, not after something breaks.
1:00 – 1:40Scenario Walk-through B · 40 min
Diagnosing a broken Nginx site using only the logs
- Scenario: "https://yourname.net won't load, but nginx -t reports the config is fine." Work through the diagnostic sequence live, narrating each step: is Nginx actually running (systemctl status nginx), is it listening on the expected port (ss -tlnp), what does access.log show for the request, what does error.log show, and do the certificate paths in the server block actually exist and match what's referenced.
- DNS views cross-check: Remind students that a "broken site" complaint can also be a DNS views misconfiguration — the client may be resolving to the wrong address for their side of the split. Always confirm which address the client actually reached before assuming it's an Nginx problem.
- Key habit reinforced: A passing nginx -t only proves the syntax is valid — it says nothing about whether the service is running, listening, or serving the content you expect. Verification is a separate step from syntax checking.
1:40 – 2:00Open Lab / Q&A · 20 min
Students catch up on any outstanding Week 3–4 lab work
Circulate and help with anything from Lab 6 (DHCP), Lab 7a (DNS), Lab 7b (DNS views), or Lab 8 (Nginx/SSL) that isn't finished. If everyone is caught up, open the floor to questions.
Instructor note: This is historically the densest review day — DHCP, DNS, DNS views, Nginx, and SSL in one sitting. If time is tight, prioritise the DNS and Nginx troubleshooting walk-throughs, since those map most directly onto the practical exam's log-diagnosis expectations.