Bind8 on TurboVision

Debian Potato on a 486 Before the Real Router Swap

Sat, 08 Sep 2001 00:00:00 +0000

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.

But after some time I notice that what I really like is the direct config file side. I want less distribution magic, more plain files, more package control in a way that feels simple and honest. Also many people around me speak good things about Debian, and I like the whole idea that I can install a very small base and then only add what I really need.

So I decide: the router should move to Debian. But I do not touch the production router first. I am maybe stubborn, but not that stupid.

Three floppies and a network

The install is very nice in a nerd way. No CD install. No glossy thing. Just floppies and network.

For Potato I use three 1.44 MB floppies:

rescue
root
driver

I use the compact boot flavor because it already has the common network cards I need. That means I can boot the machine, get network on it, and pull the rest directly from a Debian mirror through the internet.

This is one of these moments where the technology itself already feels good. The install method is small and direct. It matches what I want the router to be.

The target machine for the first Debian install is not the Cyrix router. It is a spare 486 I have lying around. Slow, but enough for testing. I want the whole new system ready somewhere else before I touch the real edge machine.

The 486 boots from floppy, asks the normal questions, then I configure the network and point it to a mirror. The packages come over DSL. This is maybe the first time where I really feel the DSL in a practical admin task: network installation is not painful anymore. It is still not super fast, but it is completely realistic.

First priority: does DSL work on the 486?

Before I care about LAN services, before DNS, before any comfort stuff, I want one proof: can this new Debian box take the DSL cable, boot, and come back with internet?

So after the base install and the PPPoE setup I take the DSL cable and put it into the 486 test machine. Then reboot.

This reboot test is important for me. A lot of things work once when you configured them half by hand in a hurry. I want to know if it survives a cold start and comes back alone.

It does.

The 486 boots, PPPoE comes up, the route is there, internet works. I reboot one more time because I do not trust success if I only saw it once. Same result. At that moment I know the migration is realistic.

The Potato package set I use

I keep it simple. This is a router, not a kitchen sink.

For the local infrastructure I install these important things:

bind8 (BIND 8.2.3)
dhcpd from ISC DHCP 2.0
Squid 2.2
the PPPoE package/tools
normal network admin tools

For the firewall I stay with ipchains because Potato is still kernel 2.2 land for me. iptables is not the topic here yet.

This is okay. The line is DSL now, but the firewall story is still 2.2 generation. I do not mind. First I want a stable router. The newer firewall framework can wait.

The detailed LAN-service part became its own small project already, so I write that separately: DHCP, bind8, Squid, Adzapper, and the annoying testing while the old router is still alive on the same LAN. That part is not hard in one big dramatic way. It is hard in fifteen little annoying ways.

So for this note I keep the focus on the migration shape itself:

Debian install by floppy and network
DSL check on the 486
package set ready
disk prepared for the real box

Why I am doing the disk swap instead of just swapping machines

The final plan is simple: when all is done on the 486, I take that disk and put it into the real router box, the Cyrix Cx133.

The reason is practical. The Cyrix box is the better final hardware. More RAM. Better fit for Squid and general comfort. The 486 is only the preparation table.

So the 486 is not the new router. It is the place where the new router disk is born.

I like this method because it keeps the dangerous experimentation away from the live edge machine. The production router can keep running until the new disk is ready. Only then do I touch the real box.

I think this is maybe the first time I do a migration in a way that feels half-professional.

The part which still decides everything is whether the LAN services are really boring enough. DSL on the 486 is only the first proof. The second proof is whether clients get addresses, names resolve, and the proxy does not behave stupidly. If that part is still shaky, then the disk stays in the 486 for more testing.

Next step is then the real swap. If all goes well, Debian boots in the Cyrix box and nobody in the LAN notices more than one short outage.

Getting the LAN Services Right: dhcpd, bind8, Squid and Adzapper

Mon, 20 Aug 2001 00:00:00 +0000

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:

clients must get addresses
clients must resolve names
web must go through a proxy if I want the same traffic saving as before
and all this must survive reboot

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

I noticed already some time ago that good router work is mostly boring work.

The exciting things are:

first successful dial
first firewall rules
the syslog hack
the DynDNS update

But the part which decides if people trust the router is boring:

DHCP must just work
DNS must just work
Squid must just work

If these things fail, then nobody cares how clever the rest is.

So my goal with the 486 is not elegance. The goal is: one by one make the LAN services boring.

dhcpd: the service which becomes annoying because the old router is still alive

I install dhcpd from the Potato package set, which means ISC DHCP 2.0 generation. The config itself is not very exotic. One subnet, one range, one gateway, one resolver.

Something small like this:

default-lease-time 600;
max-lease-time 7200;

subnet 192.168.42.0 netmask 255.255.255.0 {
  range 192.168.42.100 192.168.42.140;
  option routers 192.168.42.254;
  option domain-name-servers 192.168.42.254;
  option domain-name "home.lan";
}

Nothing special. The problem is not the syntax. The problem is that there is already another dhcpd on the network: the one on the current production router.

So now I have the classic transition-phase nonsense:

the new router should answer
the old router must keep serving the LAN
but if both answer, testing becomes stupid

At first I try to be clever. I think maybe I can just test with one client and time it right. That is not nice. Sometimes the old one answers first, sometimes the new one, and then the result is unclear and I get angry at the wrong machine.

After that I stop pretending and just do it properly. For a test window I disable dhcpd on the old router, then I bring up dhcpd on the 486 and check one client cleanly. That is much better. The client gets:

address
gateway
resolver

and then I know at least that the DHCP part itself is correct.

This was a little more hassle than I expected, but it also showed me again that migration work is very often not about software difficulty. It is about two valid systems existing at the same time.

bind8: keep it boring and forwarding

For DNS I use bind8, which in Potato is BIND 8.2.3. I do not want to make anything fancy from it.

No authoritative zones.
No big internal DNS kingdom.
No strange split-horizon ideas.

I only want:

clients ask the router
the router forwards to upstream resolvers
answers get cached

That is enough.

The config is small and I like that. A router which serves the LAN should do small things very reliably before it does big things very impressively.

The practical effect is immediately visible. When I move a test client to the 486 as resolver and start doing repeated lookups, the difference is small but nice. The first lookup goes out, the later ones are local and faster. More important than the speed is the centralization: now the router is the one place where I can see DNS behavior.

And debugging becomes simpler when one machine owns one concern.

That is maybe the general theme of this whole router story now. I keep moving functions into the router not because I want one giant monster box, but because I want one place where the edge behavior is visible and manageable.

Squid comes back, but cleaner

Squid was already a good idea in the ISDN phase. On ISDN it was almost impossible to dislike the idea of caching. If one image or one stupid page element comes a second time through the line, then I want it local.

On DSL the pressure is smaller, but I still want the proxy. Partly for cache, partly for control, partly because I just like the idea that the router can shape traffic a little bit instead of only forwarding it.

Potato gives me Squid 2.2 and that is fine.

The basic proxy setup is not the hard part. The hard part is always the tiny things:

browser config on test clients
access rules
cache directory init
making sure the daemon really starts on boot and not only when I am standing next to it

After some tries it works. Pages load through the proxy and repeated fetches feel good. Then the funny extra comes back.

Adzapper is still one of my favourite things

I know Adzapper is not some deep engineering masterpiece, but I still like it a lot.

It does exactly the kind of practical thing I enjoy:

one small tool
put in the right place
removes a lot of stupid traffic and ugly banners

When it works, the browser gets the page, but where there used to be a banner or other useless graphic, there is now a placeholder image saying “This ad zapped”.

Perfect.

This is useful in three ways at the same time:

less traffic
cleaner pages
a visible sign that the proxy is really doing something

And honestly the third point is maybe the one I enjoy most. A cache is invisible most of the time. Adzapper is visible. It says: yes, the router is not only passing traffic, it is protecting me from some nonsense too.

I install it and immediately like the result again. On ISDN it directly saved connection time and almost directly money. On DSL it still saves bandwidth and makes browsing less ugly.

The web is not getting better by itself, so I do not feel guilty doing this at all.

Testing order matters

At some point I write a checklist because without one I start jumping between services and then I lose the clear state.

My testing order becomes:

DSL up after reboot
local interface up
dhcpd lease works
DNS forward/cache works
Squid proxy works
Adzapper visibly works
second reboot
test again

The second reboot is important. Too many things work once because the admin is standing there. I want it to work when nobody is standing there.

That is maybe the difference between “nice evening success” and “router success”.

The 486 as preparation table

By now I am completely convinced that the 486 is the right preparation machine for this migration.

If I had tried to do all this directly on the production router, I would already hate myself by now.

Because then every DHCP mistake means:

no client gets a lease
DNS becomes unclear
web breaks
and the whole flat knows about my learning curve

On the 486 it is different. The mistakes are still annoying, but they are private mistakes first. That is much better.

Also, it gives me the nice psychological effect that the new router already exists before the swap. The disk already has a personality. The services already exist. The machine already behaves like the new router. The final swap is then more hardware logistics than system creation.

What is still missing before the swap

Even now I do not want to rush it.

Before I move the disk to the Cyrix box, I still want:

one more cold boot test
one clean DHCP test with the old router quiet
one browser test with Squid and Adzapper on more than one client
one simple long-running check that nothing stupid dies after two hours

Only then I will trust it enough.

The migration itself is actually the smaller dramatic action. The bigger question is whether all these little LAN services are really boring enough.

And I think that is where the real router quality lives.

The syslog hack was more exciting.
The first ISDN dial was more exciting.
The first stable DSL sync was more exciting.

But this part is maybe more important.

Because when the disk finally goes from the 486 into the Cyrix box, I do not want a nice Debian install. I want a real replacement for the old router.

That is now very close.