Blog

Some technical memories do not fade because they were elegant. They stay because they felt impossible at the time.

For me, one of those moments happened on a trusty Intel Pentium II at 350 MHz: early VMware beta builds on SuSE Linux, with Windows NT running inside a window. Today this sounds normal enough that younger admins shrug. Back then it felt like seeing tomorrow leak through a crack in the wall.

This is not a benchmark article. This is a field note from the era when virtualization moved from “weird demo trick” to “serious operational tool,” one late-night experiment at a time.

Before virtualization felt practical

In the 90s and very early 2000s, common service strategy for small teams was straightforward:

Hardware was expensive relative to team budgets, and machine diversity created endless compatibility work. If you needed a Windows-specific utility and your core ops stack was Linux, you either kept a separate Windows machine around or you dual-booted and lost rhythm every time. ... continue

By the time mail became stable, the next migration pressure arrived exactly where everyone knew it would: file shares, printers, and user identity.

In theory this is straightforward. In reality, this is where organizations discover the true complexity of their own history. Shared drives are business process. Printer queues are department politics. User accounts are unwritten social contracts. You are not migrating servers. You are migrating habits.

In the 1995-2010 arc, Linux earned trust in this space because it solved practical problems at sane cost. But it only worked when we treated mixed environments as first-class architecture, not temporary embarrassment.

The mixed-network reality we actually had

Our baseline looked familiar to many geeks in 2008:

No greenfield, no clean slate. ... continue

If Part 1 was about building a bridge, Part 2 is about learning to drive trucks across it in bad weather.

Once mail leaves “small local utility” territory and becomes a central service, the conversation changes. You stop asking “can it send and receive?” and start asking:

In our case, that transition happened between 2001 and 2007. By then, Linux mail infrastructure was no longer experimental in geek circles. It was production, with all the consequences.

Why we moved away from “wizard-level config only”

Many older setups depended on one person who understood every macro, alias map, and legacy hack in a mail config. That worked until that person got sick, changed jobs, or simply slept through a pager alert.

Our first explicit migration goal in this phase was organizational, not technical: ... continue

If ipchains was a meaningful step, iptables with netfilter architecture was the real modernization event for Linux firewalling and packet policy.

This stack is now mature enough for serious production and broad enough to scare teams that treat firewalling as an occasional script tweak. It demands better mental models, better runbooks, and better discipline around change management.

This article is an operator-focused introduction written from that maturity moment: enough years of field use to know what works, enough fresh memory of migration pain to teach it honestly.

The architectural shift: from command habits to packet path design

The most important change from older generations was not “different command syntax.” It was architecture:

Once you understand those, iptables becomes predictable. Without them, rules become superstition.

Netfilter hooks in plain language

... continue

By the time people started saying “everything is online now,” many of us had already lived through two different worlds that barely spoke the same language.

The first world was mailbox culture: dial-up nodes, message bases, Crosspoint setups, nightly rituals, packet exchanges, and local sysops who could fix a broken feed with a modem command and a pot of coffee. The second world was internet service culture: DNS, MX records, SMTP relays, POP boxes, always-on links, and users asking why the web was “slow today” as if bandwidth was weather.

This series is about that crossing.

Part 1 is the beginning of the crossing: the gateway years, when we still had one foot in mailbox software and one foot in Linux services, and we built bridges because nothing else existed yet.

The room where migration began

Our first Linux gateway did not arrive as strategy. It arrived as a beige box rescued from an office upgrade pile, with a noisy fan and a disk that sounded like it was counting down to failure. We installed a small distribution, gave it a static IP, and told ourselves this was “temporary.” It stayed in production for three years. ... continue

Linux admins in 2004 usually have muscle memory for:

Those tools build competent operators. They are not “bad.” They are simply limited for the routing complexity we run now.

In 2004, iproute2 is no longer an exotic alternative. It is the modern Linux networking toolkit for serious routing, policy routing, QoS, and clearer operational introspection. Yet many systems and admins still cling to old habits because the old tools still appear to work for simple cases.

This article is about that gap between technical capability and operational habit.

Why iproute2 existed at all

The old net-tools model was sufficient for straightforward host config: ... continue

Now the router is in a phase where I trust it.

This is a good feeling. It is not the first excitement feeling from the early SuSE days, and it is also not the hack-pride feeling from the D-channel/syslog trick. It is something else. The machine is simply there. It routes. It resolves. It gives leases. It proxies web. It zaps ads. It survives reboot. It is part of the flat now like the switch or the shelf.

The disk swap from the 486 into the Cyrix box worked. Debian Potato was first on that disk, but by now I moved the system further to Debian Woody. That means kernel 2.4, and now finally iptables instead of ipchains.

The move from Potato to Woody

This is not a dramatic migration like the first Debian step. This one is more calm.

The big practical reason is netfilter and iptables. I want the 2.4 generation now. I want the more modern firewall and NAT setup, and I also want to stay on a current stable Debian instead of freezing forever on Potato. ... continue

Now the DSL line is finally really there.

The modem LED is not blinking anymore. It is stable. This alone already changes the whole feeling in the room. For years that modem was almost decoration with hope inside. Now it is actually the uplink.

The speed is T-DSL 768/128. For me after ISDN it feels very fast. Web pages are suddenly there. Bigger downloads are no longer some project planning. The line is just there all the time. No dial on demand. No waiting for the first click. No listening if the ISDN side comes up. It is honestly a little bit fantastic.

And exactly because now the line is stable, I make the next big move: I prepare the router migration to Debian.

Why I want Debian on this machine

SuSE was important for me to start. Without SuSE 5.3 maybe I would not have started at that point. YaST helped, the docs were okay, and for the first ISDN phase it was practical. ... continue

The DSL line is there now and the Debian box on the 486 can already boot and go online. That was the first important check. But that alone does not make it a real router replacement.

The real pain is not only getting one machine online. The real pain is making one machine useful for the whole LAN.

This is the part where a lot of nice migration ideas die. One machine can route, yes, but does it really replace the old box? That means:

Only then it is serious.

So this is what I do now on the Debian Potato install on the 486. The disk is still in the 486. The Cyrix Cx133 is still the production router. The old machine is still serving the flat. This is good because it gives me space to break things on the 486 without immediately making everybody angry.

First I want the boring things

... continue

Linux 2.2 is now the practical target in many shops, and firewall operators inherit a double migration:

People often remember this as “new command syntax.” That is the shallow version. The deeper version is policy structure: teams had to stop thinking in old command habits and start thinking in chain logic that was easier to reason about at scale.

ipchains is usable in production. Operators have enough field experience to describe patterns confidently, and many organizations are still cleaning up old habits from earlier tooling.

Why ipchains mattered

ipchains was not just cosmetic. It gave clearer organization of packet filtering logic and made policy sets more maintainable for growing environments.

For many small and medium Linux deployments, the practical gains were: ... continue