Seven servers, one lesson: infrastructure is a dependency graph

The assignment sounds like a checklist: deploy seven servers on one Ubuntu host — DHCP, DNS, Apache virtual hosting, Postfix, NFS, SSH, Samba with Active Directory — and serve client VMs over a VMware internal network. Checklists lie. What the project actually teaches is that enterprise infrastructure is a dependency graph, and the graph is unforgiving.

Build in dependency order or debug in circles

Everything assumes naming and addressing. Mail delivery fails silently when DNS records are wrong. Domain joins fail when name resolution and time drift disagree. A web server that works by IP and fails by hostname isn't a web problem at all. Once I started building strictly in dependency order — DHCP and DNS first, identity next, applications last — half the mysterious failures never happened.

The client is the only judge

My definition of done changed during this build. A service isn't finished when it starts cleanly; it's finished when a client machine that knows nothing about your configuration can consume it — get the lease, resolve the name, load the site, send the mail, mount the share. Validating from the client's side of the network caught problems that looked invisible from the server's own shell.

Seven services, one host, zero isolation

Running everything on a single host adds a distinctly educational cruelty: every fix risks disturbing a neighbor. Restart networking for the DNS change and DHCP leases wobble. It forces you to understand what each service actually touches — which is precisely the understanding that slides and diagrams never give you.

When DNS, DHCP, and identity agree, everything above them becomes simple.

That sentence is the whole project. The applications people see — the website, the mail, the shared drives — are the easy layer. The invisible layer underneath, where names resolve and identities authenticate, is where reliability is actually engineered.