httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JeHo Park" <>
Subject Re: [PATCH] tproxy2 patch to the apache 2.2.15
Date Mon, 16 Aug 2010 01:46:23 GMT
hello paul~

sorry for my late reply. 

----- Original Message ----- 
From: "Paul Fee" <>
To: <>
Sent: Friday, August 13, 2010 9:18 PM
Subject: Re: [PATCH] tproxy2 patch to the apache 2.2.15

> 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.

here is my tproxy4 patch
actually speaking, i modified and fixed a patch file which i downloaded from the google svn.

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

good news :-) thanks

>>> Here's a post showing tproxy history, it recommends against tproxy2:
>>> 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.

i see what you mean ~

>>> 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

yes it is really disaster
> it's best not to pollute Apache with operation system networking setup, 
> especially non-portable settings that are unique to Linux.

i understand what you said
> Thanks,
> Paul

JeHo Park 
View raw message