The software pieces for building the server of a small office network are all there already, free, and stable for at least a year. Samba serves files and printers to Windows clients; sendmail or Postfix route the mail; OpenLDAP 2.0, out this August, holds a central user directory over LDAPv3; ipchains filters packets on the 2.2 kernel; Squid acts as an HTTP proxy and cache; Apache publishes an intranet. For a small business that wants a working local network, these programs are taken for granted. The real work starts afterwards: getting them to sit together on a single machine, configured coherently, manageable by someone who does not read man pages for a living.
Context
A network of ten or twenty Windows workstations needs a precise set of services: file and printer sharing, an internal mailbox, a shared internet connection with some filtering, user authentication held in one place, a backup that runs on its own at night. The commercial answers of the moment — Windows NT Server with its BackOffice suite, or dedicated appliances — cover that set with per-server and per-client licensing (the Client Access Licences) that grows with the number of seats.
On the free side, every function has a tried project behind it. Samba 2.0, out in January 1999, speaks the SMB protocol well enough to replace an NT file server for most office uses. sendmail has run since the 1980s; Postfix, written by Wietse Venema and released in December 1998, offers an alternative with a more legible configuration. Which program to pick for each service is the part already settled. What stays open is who keeps the ten resulting configuration files aligned, and what happens when one has to be rewritten by hand after an upgrade.
Architecture
The honest way to describe such a machine is this: a Linux 2.2 kernel and a handful of daemons no one designed to talk to each other, held together by configuration.
The network layer starts with filtering. On the 2.2 kernel the packet filter is ipchains, stateless: every rule looks at the single packet and knows nothing of the connection it belongs to. Sharing a single external line goes through masquerading — rewriting source addresses, what we now call source NAT. Squid sits in front of HTTP traffic as a proxy and cache: it cuts the bandwidth a small network consumes by a measurable margin, and gives a single place to apply access rules.
Authentication is where consistency is really decided. Without a central directory, each service keeps its own list of users: system accounts in /etc/passwd, Samba users in a separate file, mailboxes somewhere else again. With OpenLDAP 2.0 and LDAPv3 support the directory lives in one place and the other services query it. The gain is real, but it comes at a price: each daemon has to be taught to query the directory, and in 2000 the mechanisms for doing so are still immature and differ from one service to the next.
Mail is the longest chain. A transport agent (sendmail or Postfix) receives and routes; a POP3/IMAP server delivers mailboxes to clients; a virus-filtering layer has to be slotted between the two, and the practised way is to pass every message through an external scanner with a script such as AMaViS. Each link is a separate program, with its own configuration format and its own log.
The critical point
A sum of correct components does not make a correct system. Four concrete problems surface as soon as you try to put these daemons together.
The first is shared authentication. Making Samba, mail, and the proxy authenticate against the same LDAP directory means configuring each daemon differently, and in 2000 support is uneven: some read LDAP on their own, some have to be bridged through PAM, others still demand their own file. A disabled user has to vanish from every service at once, or I have only disabled them for show.
The second is configuration consistency. Ten services mean ten files in ten different syntaxes, each with its own format and constraints. Changing a network address or a domain name touches nearly all of them. Without a layer that generates those files from one description, every change is a manual round-trip that invites error — and a mistake in ipchains or in masquerading leaves the network silently exposed.
The third is upgrading. Updating a single package can change its configuration format and overwrite hand-edited files. On a machine carrying ten services, every update is a potential regression for all the others. This is why such systems, once they run, are never touched again — which is the worst possible way to keep security standing.
The fourth is diagnosis. When external mail fails to arrive, the cause may sit in an ipchains rule, in masquerading, in a virus filter blocking without a word, in the transport configuration, or in an LDAP directory that does not answer. Each link has its own log, in a different place, in a different format. Without a single point to observe from, diagnosis turns into correlation by hand.
Implications
For a small business, the value of such a machine lies entirely in the integration layer, not in the collection of packages, which are public and documented: the single directory as the source of truth for accounts, a generator that produces the configuration files from one coherent description, one place to read the logs and the state. That is the layer none of the upstream projects provides, because each solves its own problem well and stops at its own boundary.
This changes the nature of the work. The network software is already written, tested, and maintained by communities more capable than any single integrator. What is left to do is to build and maintain the consistency layer on top of components that evolve to their own calendars. It is systems work, and should be judged as such: by how correct it stays after the third upgrade, not by how elegant it is on installation day. A machine that packages exactly this layer into a single appliance is the B.O.S.S. (Business Open Source Server) described in the noze insight: https://www.noze.it/en/insights/boss-server/.
Limits
On the 2.2 kernel the ipchains filter stays stateless: the per-connection evaluation that would simplify firewall rules arrives with netfilter and the 2.4 series, still in development at the end of 2000. Cleartext POP3 delivery exposes credentials on the local network; for now the practical remedy is to confine it to the LAN, behind the filter. And the integration layer above carries a recurring cost that does not go away: a machine like this is a standing maintenance commitment, not a box to install and forget. Anyone proposing it to a small business should say so plainly.
https://www.openldap.org/software/roadmap.html https://www.samba.org/samba/history/samba-2.0.0.html https://www.postfix.org/ https://www.kernel.org/pub/linux/kernel/v2.2/ https://en.wikipedia.org/wiki/Ipchains https://www.squid-cache.org/
Cover image: Google’s first production server from 1999: bare commodity motherboards mounted with exposed cabling, on display at the Computer… — photo by Carlo Nardone, CC BY-SA 2.0 — https://commons.wikimedia.org/wiki/File:Google’s_First_Production_Server_(1999)_-_Computer_History_Museum_(2007-11-10_23.05.32_by_Carlo_Nardone).jpg