Blog
Welcome to the Blog.
Mailboxes to Internet 2: Mail Under Real Traffic
2007-02-27
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.
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
Linux Networking 5: iptables in Practice
2006-10-09
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 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. ... continue
Mailboxes to Internet 1: Gateway Years
2006-03-14
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.
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 Networking 4: iproute2 Replaces ifconfig
2004-06-09
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.
The old net-tools model was sufficient for straightforward host config: ... continue
Debian Woody Home Router
2003-03-02
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.
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
Debian Potato on a 486
2001-09-08
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.
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
LAN Services on the Router
2001-08-20
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. ... continue
Linux Networking 3: The ipchains Era
2000-04-11
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.
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
D-Channel Syslog Hack
2000-04-09
Now I have one of my favourite hacks on this router.
The problem was simple: when I am not at home and the line is down, I still want a way to make the box go online. I do not want to call home, let somebody pick up, log in somewhere, and then maybe start the connection. I want a stupid simple trick. If I call the home number, the box should see that and bring the line up.
But I do not want the caller to pay for the call. That was important for me. The whole trick should work before the call is really answered.
With ISDN the D-channel signal comes before the B-channel is really used for the actual call. isdn4linux logs things about incoming calls into syslog. When I noticed that, I got the idea that maybe I do not need some big elegant callback solution. Maybe I can just watch the logs.
This is exactly what I do. ... continue
ISDN Dial-on-Demand
1999-02-14
Now the box is not only booting, it is doing useful work.
I still have the DSL hardware connected, but the modem LED is still blinking and not stable. So this means: the real life is still ISDN. But because of the T-Online/DSL package I can already use ISDN for internet without this old fear of counting every minute too hard. That makes it much more realistic to really use the Linux router every day and not only as some weekend test setup.
The main thing I wanted was dial on demand. I do not want the machine online all the time if nobody uses it. Also I do not want manual dial each time. The right thing is: local machine sends packet, router notices it, line goes up, internet works. Later, when no traffic is there anymore, the line goes down again.
In theory this sounds very logical. In practice it takes me enough evenings.
The important parts for me are isdn4linux and ipppd. isdn4linux does the low-level ISDN side and ipppd does the PPP part. After reading enough HOWTO text and trying enough wrong settings I end up with a setup that is at least understandable. ... continue