httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fee <p...@talk21.com>
Subject Re: [PATCH] tproxy2 patch to the apache 2.2.15
Date Fri, 13 Aug 2010 12:18:45 GMT
JeHo Park wrote:

<snip>
> 
> yes, i see,
> so i  also made tproxy4 apache patch  to the version httpd 2.2.9 and
> tested it in debian linux box successfully!. the software version i tested
> looks below --
> kernel:  vanilla 2.6.31 [tproxy4 included as default ]
> apache: 2.2.9 [tproxy4 patch applied]
> iptables: 1.4.3
> ebtables: 2.0.8
> --
> i tested the tproxy4 apache successfully in the debian lenny. but i met
> some strange things that was .. the same tproxy4 software did not operated
> correctly in the CentOS the main Environment me and our team developed in
> is not the debian but the CentOS so i had to give up the tproxy4.
> this is why i made the tproxy2 apache patch... in the kernel 2.6.18 CentOS
> kernel :-(

Can you share your tproxy4 based patches.  I think they're more interesting 
as they'll work across more distributions in the future.

RHEL6 beta has tproxy4 support, as will CentOS6 in time.  Your tproxy4 work 
will become usable when your main environment upgrades.

> 
>> 
>> Here's a post showing tproxy history, it recommends against tproxy2:
>> https://lists.balabit.hu/pipermail/tproxy/2008-November/000994.html
>> 
>> Bazsi suggests starting with tproxy4 for 2.6.17 and propagate that
>> forward
>> to a 2.6.18 kernel.  The tproxy4 API looks easier to use than tproxy2. 
>> forex- Unfortunately I didn't find the tproxy4 for 2.6.17 kernel patch.
> 
> really ?  great! i didn't know that !

Hopefully you can locate the tproxy4 for 2.6.17 patch as that would allow 
Apache to work consistently in both your environment and with 2.6.28+ 
kernels.

> 
> but it seems wondering whether Bazsi do backport the tproxy4 kernel patch
> to the kernel 2.6.17 or 2.6.18 anyway recently, i applied my
> tproxy2 patch - exactly speaking, i modified or inserted some little bit
> codes to the existing patch --- to a commercial sites and then i found
> ..maybe .. tproxy2 is not real transparency.. because i had to insert some
> route infomations to the box for packet routing problems.
> 
>> 
>> However most important is to have future proof Apache changes that will
>> be compatible with distros other than just CentOS5/RHEL5, for example
>> RHEL6.

Although you're tied to CentOS5 now, I think Apache trunk would benefit more 
from tproxy4 patches.  The tproxy2 work has a limited future.

>> 
>> Incidentally, how are you managing the iptables rules?  Is it assumed
>> that
>> these will be setup before Apache httpd is started?  Or do you think
>> Apache should "own" the rules, creating them at startup and removing them
>> on shutdown.
> yes, i see, both tproxy2 and tproxy4 need some L2 bridge, L3 or route
> rules by the iptables and etc so i always insert the rules before or after
> starting apache httpd. and i hope Apache don't own the rules. i call the
> deletion of the rules from the box as software bypass :-) i think it is
> not needed the Apache httpd own the rules .. for more easy debugging and
> other usages ..

Handling the iptables rules within Apache would present difficulties.  For 
example if Apache died/crashed, the rules could be left lingering.  Perhaps 
it's best not to pollute Apache with operation system networking setup, 
especially non-portable settings that are unique to Linux.

Thanks,
Paul

Mime
View raw message