Further adventures in Firewall upgrades

[Jonathan Hutchins]

Discouraged by all the various services and reconfiguration I would have to
add to the Mandrake SNF system, I yanked it out, swapped the new 56x CD into
the old firewall system, downloaded, burned, and upgraded RedHat 7.2.

Now I remember why I hadn't just upgraded before.

The initial. upgrade took about four hours.  This included some unattended
time at an error prompt, some time spent figuring out how to get out of the
error loop, and correcting the error.  Much of the time can be attributed to
the time it takes for a 133MHz processor with 32M of RAM to deal with the
RPM Database.  That sucker needs serious work, but will probably be shuffled
under given advances in processor speed and RAM size.

Nonetheless, the RPM Database isn't the only victim here - we have serious
code bloat happening in Linux.  It could be argued that at this point, the
bloat between the various versions ~6 and the current ~7 - ~8 versions is
even worse than the bloat between Windows 95 and Windows XP.  People are
including the kitchen sink, linking to everything under the sun, and adding
features without thought.

Clearly, a lot of the development on Linux has moved from the "spare"
obsolete machines of impoverished students to the hot-rod hobbyist machines
of professional coders with cushy jobs or backing.  Programs that should be
runnable on a minimal, text-based system are being developed on
multiprocessor RAM hogs with dual-head graphic displays.  A program that can
and does fit in under 100Kb links to the entire X11 system, even though it's
command line based.

The initial install error in the RH 6.2 - 7.2 upgrade was that the
auto-selected packages for upgrade exceeded available space by 42Mb.  I
carefully weeded out useless things like JPG processors from the list, then
discovered that some 400+Mb was accounted for by the Kernel Source.  Well, I
had hoped to compile a custom kernel, but maybe now's not the time to try.

Having gotten past that hurdle, the next one was when the machine rebooted
after the upgrade.  Which brings up another point - isn't one of the big
complaints about Microsoft that you have to reboot to upgrade?  This upgrade
required two reboots, one to launch the upgrade, and one to implement it.
That, and several to recover from it.

Once the system was back up, I checked for the essential functions,
connectivity to the Internet, NAT forwarding of internal traffic, DNS.
First strike: DNS did not recover.  Although a script is provided with the
(8.2?) version of BIND that's supposed to translate your old config files to
the new style, it ignored a simple sequence error ("type" must be the first
entry in a zone definition, some other parameter was there), and no DNS.
That fixed, DNS came back up, but with about six sessions instead of the
configured single session for my very small network.  That remains to be
corrected.

Next, the pass-through.  No deal.  netstat -M reports "no support for IP
masquerading on this system".  Although the IP MASQ HOWTO says that the new
kernel 2.4.x IPTABLEs system is reverse-compatible with the old IPCHAINS
commands, the fact remains that the system isn't running it.  A little
digging reveals that iptables, as such, isn't installed.  Even once that's
been corrected, we still get no forwarding.

Work was suspended until Sunday evening due to other major commitments.  A
bit of further reading in the IP MASQ HOWTO, following it as if setting up
for the first time, and using the recommended script structure, and we have
IP MASQ working.

ESR's fetchmail program, which we had been unable to upgrade due to linking
to new libraries that required an upgrade almost this complete, is finally
accomplished.  I look forward to implementing his spam filters at long last,
and hope to cut down on some spurious logging errors.

A brief test seemed to indicate that I would be able to connect to the
system using SSH from work, and the project was put to bed as a partial
success.  Further frustrations to follow.