0:00–0:30
Written
0:30–1:45
Practical
1:45–2:00
Review + Preview W6
Before 0:00Instructor setup
- Written assessment sheets face-down on desks.
- S1 prepared with a broken Nginx configuration — introduce the faults listed in the practical section below before class. Students must diagnose and repair without knowing in advance what was broken.
- On board: Written — 30 min, pen and paper. Practical — 75 min, S1 only, nginx man pages and log files available, no internet, no notes.
0:00 – 0:30Written · 30 min · 30% of Mini-Assessment 4
Written — DNS views, Nginx configuration, SSL/TLS concepts
Pen and paper. No computer. 30 minutes.
Section A — DNS Views (12 marks)
- Q1 (3 marks): Explain what split-horizon DNS is and why it is used. Give a concrete example involving a web server with both an internal and external IP address.
- Q2 (3 marks): A named.conf.local file has two view blocks. The external view (match-clients { any; }) appears first, and the internal view (match-clients { 192.168.50.0/24; }) appears second.
a) Which view is used when an internal client (192.168.50.2) makes a query? Explain why.
b) How would you fix this without deleting either view block?
- Q3 (2 marks): What does
recursion no; in a view block do? Why is it applied to the external view but not the internal view?
- Q4 (2 marks): Write the named.conf.options entry that defines an ACL called "lab-nets" containing 192.168.50.0/24, 192.168.51.0/24, and the loopback address.
- Q5 (2 marks): Once views are in use, what happens if a zone declaration exists outside all view blocks in named.conf.local? How do you fix it?
Section B — Nginx and SSL/TLS (18 marks)
- Q6 (4 marks): Explain the purpose of each directive in a server block:
a) server_name yourname.net www.yourname.net;
b) try_files $uri $uri/ =404;
c) return 301 https://$server_name$request_uri;
d) include snippets/ssl-params.conf;
- Q7 (3 marks): What is the sites-available / sites-enabled pattern? Why is a symlink used rather than copying the file? What command creates the symlink?
- Q8 (2 marks): What does
sudo nginx -t do, and when should it be run? Give an example of an error it would catch that a simple text editor review might miss.
- Q9 (3 marks): Write the complete
openssl req command used to generate a self-signed certificate. Identify what each flag does: -x509, -nodes, -days 365, -newkey rsa:2048.
- Q10 (3 marks): An access.log entry reads:
192.168.50.2 - - [18/Nov/2024:14:05:22 +0000] "GET /about.html HTTP/1.1" 404 162 "-" "curl/7.81.0"
a) What is the client IP? b) What was requested? c) What does the 404 status indicate? d) What tool made the request? e) How many bytes were in the response body?
- Q11 (3 marks): Describe the difference between access.log and error.log. For each of the following scenarios, state which log you would check first and what you would expect to see:
a) A user reports the website shows "403 Forbidden"
b) An SSL certificate path was entered incorrectly in the config
c) A specific page returns 404 but others load fine
0:30 – 1:45Practical · 75 min · 70% of Mini-Assessment 4
Diagnose and repair a broken Nginx configuration using only logs and nginx -t
S1's Nginx configuration has been deliberately broken. The HTTPS site is not loading correctly. Using nginx -t, access.log, error.log, and man pages — diagnose all faults, repair the configuration, and demonstrate a working HTTPS connection to the instructor. No notes, no internet. 75 minutes.
Faults introduced before the assessment (instructor reference)
- Fault A: Document root changed to a non-existent path (
/var/www/yourname.net/broken/). Nginx starts, site loads but returns 404.
- Fault B: SSL certificate path in self-signed.conf changed to an incorrect filename. nginx -t fails — service cannot reload until fixed.
- Fault C: Port 80 server block modified — the return 301 redirect removed and replaced with a root/location block pointing to a different directory. HTTP no longer redirects to HTTPS.
Practical tasks (students graded on these)
- Task 1 (20 marks): Identify all faults. For each: state the symptom observed, the log or command that revealed it, the root cause, and the fix applied. Demonstrate each fix by showing the corrected config line to the instructor.
- Task 2 (25 marks): All three faults repaired. Demonstrate to the instructor:
· nginx -t returns "test is successful"
· http://yourname.net returns a 301 redirect to HTTPS (shown in access.log)
· https://yourname.net loads the correct index.html content
· Certificate warning appears (expected for self-signed) but page loads
- Task 3 (25 marks): Add a per-site log file entry that wasn't there before (if removed as part of the faults). Watch the access.log in real time while the instructor makes a test request. Show that the log entry appears for each request.
Marking criteria
| Task | Marks | Verified by |
| Fault A identified and explained — wrong document root | 7 | Student describes: accessed error.log, saw file not found error, identified incorrect root path |
| Fault B identified and explained — wrong cert path | 7 | Student ran nginx -t, read the SSL error, found the incorrect path in self-signed.conf |
| Fault C identified and explained — broken redirect | 6 | Student browsed to http:// and observed the wrong behaviour, checked port 80 server block |
| nginx -t passes after all repairs | 10 | Student runs nginx -t and shows instructor "test is successful" |
| 301 redirect working — http → https | 5 | access.log shows 301 for HTTP request, then 200 for HTTPS |
| https://yourname.net loads correct content | 10 | Instructor browses and sees correct index.html |
| Per-site log files active — entry appears during live test | 25 | Student tails log file during instructor's browser request |
1:45 – 2:00Review + Week 5 Preview · 15 min
- Walk through the three faults. The SSL certificate path fault (Fault B) is the most important to highlight — it's the one nginx -t catches before deployment, preventing a full service outage. Students who tried to reload nginx without running nginx -t first got stuck in a failed state.
- The log-first methodology: the pattern introduced today applies to every service with logs. The question is always: "What did the log show?" before "What config did you change?" This sequence — observe symptom, read log, identify root cause, fix, verify — is how professional sysadmins work.
- Preview Week 5: VPN. "The SSL certificate you generated this week was self-signed. Next week we build VPNs. The certificate-based VPN configuration in Week 5 uses a similar PKI model — a CA certificate, server certificates, and private keys. The concepts are the same; the application is different. By the end of Week 5, you'll have set up an IPSec VPN with PSK, then migrated it to certificate-based auth, and then built a WireGuard tunnel as a modern comparison."
Mini-Assessment 4 — marking summary
| Component | Format | Weight | Key topics |
| Written — Section A (DNS views) | Short answer | 12 marks (30%) | Split-horizon, view ordering, recursion no, ACL syntax, zones-in-views requirement |
| Written — Section B (Nginx/SSL) | Short answer + log analysis | 18 marks (30%) | Server block directives, sites pattern, nginx -t, openssl flags, access.log format, access vs error log |
| Practical — Fault identification | Written diagnosis + explanation | 20 marks (70%) | Root cause identification from logs and nginx -t |
| Practical — Working HTTPS site | Live demonstration | 25 marks (70%) | nginx -t passes, 301 redirect works, HTTPS loads correct content |
| Practical — Live log evidence | Live demonstration | 25 marks (70%) | Per-site log active, entry visible during real-time request |