On Sun, 25 Mar 2001, Karl J. Runge wrote:
> The author seems to be on the right track. Shame on Redhat for not doing
> the tiny tweak and saving the admins some time and brain cells.
I generally agree, but it occurs to me that Red Hat may have been trying to
avoid problems with duplicate service entries, when you combine the new config
files with a legacy /etc/inetd.conf file. The fact that said compatibility
option is undocumented sure doesn't help much. On the third hand, maybe the
proper thing would have been for Red Hat to document and/or improve the
compatibility option.
> But to *force* everybody to immediately change over to a new syntax is
> uncool IMHO. We've seen this in ipfwadm -> ipchains and now ipchains ->
> iptables and elsewhere.
The theory on that was that distro vendors were supposed to provide an
upgrade path, either via intelligent conversion of existing scripts, or via a
wrapper interface to ipchains. Both of which were provided with the new 2.2
kernel, IIRC. Red Hat Linux, for example, ships an ipadadm command that
translates to ipchains.
On Sun, 25 Mar 2001, Tom Rauschenbach wrote:
> Well no one is forcing you to upgrade, but look at all the posts saying
> that you are an incompetent moron if you don't...
Who said that? Heck, most of the people on this list (myself included) seem
to regard Red Hat 7.0 as "best avoided".
On Sun, 25 Mar 2001, Derek Martin wrote:
> Actually the old syntax IS supported... you need to load the ipchains
> module to get it, but then you CAN NOT use any of the new functionality.
> The two syntaxes are mutually exclusive.
Don't forget there are several kinds of backwards compatibility. In this
case, we've got command syntax, and the kernel binary interface. IIRC, from
2.0 to 2.2, the kernel was not binary compatible, but with the right
configuration, the command syntax could be. With 2.2 to 2.4, I understand you
can load kernel modules which provide actual binary compatibility to an older
ipchains program (at the expense of new features, as you note).
--
Ben Scott <[EMAIL PROTECTED]>
| The opinions expressed in this message are those of the author and do not |
| necessarily represent the views or policy of any other person, entity or |
| organization. All information is provided without warranty of any kind. |
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
