On Tue, 07 Nov 2006, in the Usenet newsgroup comp.os.linux.networking, in
rticle <(E-Mail Removed)> , Duane Evenson wrote:
>>> iptables on rh6.2? no way :-)
>>
>> A good reason to update to something less geriatrical.
>I just checked my version of 6.1 and it has ipchain, 7.3 (my next version)
>is running iptables. Iptables has much more features than ipchain.
Prior to the 2.2.x kernel (1998), the firewall was controlled by "ipfwadm".
For 2.2.x, Rusty Russell reworked the firewall code in the kernel, and
introduced the IPCHAINS tool to control that. The code was again reworked
for the 2.4.x kernel in 1999, and the new user interface 'iptables' was
introduced. I'm ignoring distribution specific and third party helper
tools that do the same thing.
>You may be able to find a version of iptables packaged for 6.2.
RH 6.2 began life March 27, 2000 with a 2.2.14-5 kernel out of box, and
ended up with a 2.2.24-6.2.3 kernel released March 19, 2003. Thus, it
was IPCHAINS only.
RH 7.0 was released in September 2000 with a 2.2.16-22 kernel, reaching
2.2.24-7.0.3 also on March 19, 2003. It was a very strange release, and
included pieces from a 2.4.0 pre-release candidate. Interestingly, it
came with both
181327 Aug 30 2000 ipchains-1.3.9-17.i386.rpm
74563 Aug 30 2000 iptables-1.1.1-2.i386.rpm
though I think everyone was using IPCHAINS (certainly it defaulted to
that). RH7.1 introduced the 2.4.x kernel (2.4.2-2) in April 2001
and was updated to 2.4.20-30.7.legacy after end-of-life. Like 7.0, it
came with both ipchains-1.3.10-7 and iptables-1.2.1a-1, though the
built-in Red Hat tools (firewall-config-0.95-2) used IPCHAINS. If I
recall correctly, the Red Hat "helper" tools didn't transition to using
iptables until RH 8.0.
>I have a different opinion about upgrading than many. I figure if the
>system is working well and doing everything you want, you shouldn't
>upgrade.
Are they totally inaccessible from any bad guys, or are you counting on
the fact that no one would believe you are still using wu-ftpd-2.6.1
(the last updated version supplied to RH 6.2), never mind patching all
of the rest of the security problems that have been uncovered since these
old releases became unsupported? Don't forget, there was an exploit in
the wild that "got to" RH 6.2 boxes running the out-of-box applications.
>I have older systems running older versions of linux that I wouldn't
>dream of upgrading.
Sure - I know where a Red Hat 3.0.3 Picasso (March 1996, 1.2.13 kernel)
is on one of the isolated networks, and I think there is still a Red Hat
2.1 box from late 1995 back there as well. But they are not reachable
from the building network, never mind the company net or Internet.
>Sure it means knowing or researching legacy apps if I ever need to
>change things, but upgrading just because you can is an even greater
>waste of time. Often the upgrade is too big and bulky for the older
>system anyways.
It also means you have to take the responsibility for securing the box,
patching the security problems as they are reported - even though the
application author doesn't support it.
>I leave my older systems alone if I can and just upgrade my new/unstable
>system.
It's costing less than US$500 for the current crop of systems we're buying
for the users. Our servers tend to be cast-off user systems that have the
hard drives replaced, memory max'ed out, and eye-candy video card removed.
The software installs are standardized and semi-automated such that it
takes longer to unpack and cable the box than the tech spends configuring
the software install. But how much does that $500 buy in admin time
trying to patch an unsupported distribution, or recover from an exploit.
Sorry - new hardware wins every time except in _most_ unusual circumstances..
Old guy
|
Similar Threads
Linear Mode
