hello paul~ sorry for my late reply.
----- Original Message ----- From: "Paul Fee" <p...@talk21.com> To: <dev@httpd.apache.org> 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. http://211.174.184.69/apache-tproxy4 > 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: >>> 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. > 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 Thanks JeHo Park
