[ale] ipchains in 2.4.13

[Stuffed Crust]

On Thu, Jan 31, 2002 at 08:09:12PM -0500, Transam wrote:
> How is that a fatal flaw in my reasoning?  I stated that unnecessary
> incompatibility introduced in the later version of a design is bad in
> that it has a substantial cost for the users using that design who are
> faced with an upgrade.  This is one of the biggest criticisms of Winbloz
> and rightly so.

And if the incompatibility was necessary?   Why would they deliberately
make things incompatible unless it was necessary?  Come on, the
userspace tools are utterly simple compared to the kernel code behind
them.
 
> Again, you miss my point.  It's irrelevant what a tool's purpose is.  The
> issue is unnecessary incompatibility requiring significant effort by the
> user of the tool.  As I am the user of this tool it is a big issue with me.

No, the purpose of the tool makes the interface completely relevant.

To make a tool analogy with woodworking -- 

Would you complain when you use an edger instead of a planer to plane
boards? The interface is quite different, and it is relatively difficult
and time-consuming to properly plane a board with an edger. But it is
doable.

Use the tool that's most appropriate.

> > Does DENY mean "don't allow" or "tell them they're not allowed?"
> > DENY != DROP.  
> DENY == DROP.

Yes, iptables's DENY and ipchains DROP mean the same thing.

However, what if I now want to explicitly REJECT a packet? Then I end up
with REJECT and DENY.  Now that's mighty confusing, given that the words
seem to mean about the same thing according to my dictionary.  So DENY
was renamed to DROP, because DENY actually DROPs packets!  What a novel
idea!

> Someone with zero knowledge has no business configuring Firewalls.

You are correct in this statement, but you missed my point.

Instead, let me rephrase my statement to read (change in caps)

> And for someone coming in with zero knowledge OF LINUX FIREWALLS, at 
> worst, the new syntax is just as arbitrary as the old syntax.  And
> at best, it makes more sense to them.

Especially considering that iptables seperation of input/foward/output
is in line with what just about every other firewall implementation
provides.

> Let's go through the source of the kernel, c, c++, and Perl language
> processors, vi & emacs, the shells, etc. and try to find every command
> which could be named better and change the name and create a Linux
> distribution from it and sell it as the Improved Linux.  Even Ken
> Thompson said that the creat() system call should have been named create()
> in retrospect.  See how many people will use what you created.

Apples and oranges.  

You know what? What you described never happens.  What happens is that a
new tool comes along, usually with different syntax (C++, perl5 vs
perl4, zsh, whatever) that ends up winning people over due to improved
functionality and/or ease of use.

By changing C's syntax or the standard unix system calls, it's no longer
the "standard" C/whatever.  

And since they changed the syntax and how it behaves, it's not called 
ipchains2.  It's called iptables and requires a different way of
thinking.
 
> I don't use ipfwadm often enough to answer this question without research.
> It may be that dumb decisions were made there too.  However, the number of
> people that use (used) IP Chains is vastly larger and so it is a more
> important matter in the transition to IP Tables.

And a year from now, the number of people that use iptables will be
vastly larger than the number of people that use ipchains.  Don't new
users just suck sometimes?
 
> You only need to know both input and output for forwarding because of the
> arbitrary separation of the handling of forwarding from incoming/outgoing
> packets.

...and?  This is one of the core design changes.  Perhaps the second
most important core changes.  And that's why it's called iptables, not
ipchains-improved.
 
> > The whole reason we have iptables at all is because of the
> > "failures" of the ipchains design!
> 
> No, we have it because of the designer's failure to understand the
> importance of upward compatibility.

Um.  Yeah.   Whatever.

The people I work for currently have ~30 machines deployed around the
country; most are running 2.2, but about half a dozen (the newer ones)
are running 2.4.  Their firewall rules required ZERO changes to get them
to work.  How? They're still using ipchains.  We have no reason to
change either, because we don't need any of the new functionality.  (And
we have more important things to spend our time on)

The "upward compatibility" of iptables is to simply not use it.  It
doesn't get any simpler and more backwards-compatible than that.

> I don't care how iptables works any more than I care how the c compiler
> or vi works.  I want new and improved, not new and different.  Vim versus
> the original Berkeley vi (of which I had input as to its design) is a
> perfect example of the right way to do things.  Vim is vastly different and
> has very useful new features such as color hilighting of different elements
> of the source of whatever common language that one is using.

And again, this is apples to oranges.  

You should be comparing vim to emacs.  They both let you get the same
things done (edit files) but have different syntax and interfaces.

Obviously, emacs is a poor design because its interface isn't compatible
with vi.  But wait, it is! There's a vi-mode.  And most things work! But
not everything.  By your reasoning, this means emacs sucks, because when
using it in vi-mode it doesn't do everyhing that vi does.  But the real
problem is not emacs, but rather you are you're using emacs when you
should be using vi.
 
> However, there was NO learning curve because they were used in the
> same way.  Nor has there been in the 25 years or so that I've been
> using one or the other.  Ditto for csh versus tcsh or bash verses the
> Bourne shell.  Both of those are far more sophisticated and complex than
> either IP Chains or IP Tables.

...And ipchains and iptables do not work in the same way.  Probably
because they do different things with a common purpose.   The end result
is the same, but they are different products.  

DVDs and VHS tapes are different and require different equipment, but
they both do the same thing -- let you watch a movie.  
 
> > If you don't want to switch, then you don't have to.  Hell, you can even
> > continue to use your ipfwadm rules if you still want to!
> 
> Your point?

To restate what I've said above, if iptables offends you so much,
there's absolutely no reason to use it.  The 2.4 ipchains module is
completely backwards compatible except for port forwarding.  (that could
be remedied if one wanted to update the ipfwadm tool.  Interested?)

Hell, you can't even use the excuse of port forwarding forcing you to
use iptables.  You don't have to be using 2.4 at all; You can use 2.2.20
or even 2.0.40 if you want.  It's not like we're holding a gun to your
head, saying "upgrade or die"
 
> Am I?  There are timeouts in IP Tables, such as for UDP pseudo connections.
> Under IP Chains I can change these as needed for various types of UDP
> services.  The failure to have them be programmable in IP Tables was just
> laziness on the part of the developer.

Hmm.  No, ipchains lets you set a single timeout for UDP masquerading.  
Not one for each service.  (Though obviously with a helper module you
have more control..)

But perhaps there's a more relevant point.  You shouldn't be
masquerading UDP to begin with.  The only UDP service that has any
business going through a firewall is DNS, and that should only go to a
designated DNS server inside your network.  NTP?  ditto.  

> When I went from the 2.2 to the 2.4 kernel, the only thing I had to change
> was firewalling so your distinction between kernel vs. non-kernel changes
> is incorrect.  Many other things changed between the 2.2 and 2.4 kernel

You are wrong.  2.4 required changes to binutils, util-linux, modutils,
raid-tools, the e2fs tools, ppp, and not to mention updated compilers to
make it all build.  The fact that you "had to change nothing but
firewalling" is because your vendor was looking out for you. If I wanted
to put a 2.4 kernel on a RedHat 6.2 box, I'd have to upgrade a minimum
of half-dozen packages or it wouldn't even compile.  Oh wait, under your
reasoning the kernel developers are obviously at fault for requiring
newer versions of these support tools. 

And note this is completely different from upgrading the tools to
support the new features (like needing glibc >2.1.23 for >2G file
support).  You'd need many of the above for the system to even boot.

And finally, once again:

You didn't have to change firewalling.  You could have continued to use
ipchains until you needed to do something that it didn't allow.

The only constant in the universe is change.

 - Pizza
-- 
Solomon Peachy                                    pizzaATfucktheusers.org
I ain't broke, but I'm badly bent.                           ICQ# 1318344
Patience comes to those who wait.
    ...It's not "Beanbag Love", it's a "Transanimate Relationship"...

 PGP signature