Am 31.08.2011 15:35, schrieb Karanbir Singh:
>> PS: To install iptables from source is pretty straightforward:
>> get the tarball from netfilter.org, unpack and run:
>> ./configure --prefix=/opt/iptables&& make&& make install
>
> And at that point you lose. All management capability or the ability to
> audit / track or even upgrade along the distro. Installing from source,
> is almost always the wrong solution; There are *some* places where it
Yes, it should be an exception. I wanted to present a fix to the OP problem.
The correct solution would be to point him to a repository from where he can
install/update a newer iptables package. Unfortunately, I don't know any.
Installing from source should be considered the "quick & dirty" solution.
That is why I install to a _distinct_ /opt directory, _not_ overwriting
any rpm-owned files, and set the path to it only where needed, not globally.
Your advice holds true if one is not careful to keep the distro "clean",
i.e. prevent mixing it with non-distro files when running just running
configure without --prefix (thus installing to /usr/local or, even worse,
to /usr) or by installing "alien" other-distro rpm packages.
Maybe it should be emphasized that it is _critical_ to keep a "clean"
distribution. Otherwise yes, I absolutely agree with your statement above.
Installing a few packages to a distinct directory don't hurt cleanliness,
IMHO. It is not in the PATH by default and can easily be "uninstalled" by
a "rm -r /opt/foo".
Not to forget: Any manually installed package must be maintained anyways,
regardless if built from source or installed by rpm.
> might be a workable solution, but really do you want your first line of
> machine defence to be from source ? Just the amount of effort needed to
> make something like that work is huge.
In my particular case, the new iptables are _only_ used to fill the mangle
table. Anything else is done by the stock iptables, so only the QoS rules
would be affected. Not that critical.
Of course, when running a newer (read: unsupported) kernel, such as 2.6.32
or 2.6.35, on CentOS 5, you'd better verify everything works for you in a test
environment before deploying it in the wild.
Regards,
Walter
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
