Re: [PATCH] tproxy2 patch to the apache 2.2.15
hello Junyong Jiang
client <-conn 1-> tproxy <- conn 2 --> web server
211.x br0 : 10.a
10.b
as you know previously, there are 2 connections,
one is the connection between client and tproxy and the other is between tproxy
and web server
and if you configure bridged's IP address, tproxy server binds with this
address and random ports and
make connection with a client and server with this bridged IP address
but during run time, web server receives some packets whose source address is
real client address (211.x)
how about check out proxy_util.c .. modules/proxy/proxy_util.c
// snip --//
here! /* use bridged IP address as binding address */
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = inet_addr (conf->tproxy_ifaddr);
sin.sin_port = 0;
if(bind(dst->fd, (struct sockaddr *) &sin, sizeof(sin)) == -1) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
"%s/%d Z-linuxpark-2: Error bind (): [ifaddr:%s]: %d:%s\n",
__FUNCTION__, __LINE__, conf->tproxy_ifaddr, errno,
strerror (errno));
return -2;
}
here! /* use client address as source address using SOL_IP ipv4 socket
option */
itp.op = TPROXY_ASSIGN;
itp.v.addr.faddr = src->addr.sin_addr;
itp.v.addr.fport = ntohs (src->addr.sin_port);
ret = setsockopt(dst->fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp));
if (ret < 0 ) {
#if 0
if (errno == EADDRINUSE)
goto exit;
#endif
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
"%s/%d Z-linuxpark-3: Error setsockopt (): %d:%s: "
"[fd: %d, src: %u.%u.%u.%u port(%d)] \n",
__FUNCTION__, __LINE__, errno, strerror (errno),
dst->fd,
NIPQUAD (src->addr.sin_addr.s_addr), src->addr.sin_port);
return -3;
}
and then try to connect !
itp.op = TPROXY_FLAGS;
itp.v.flags = ITP_CONNECT;
ret = setsockopt(dst->fd, SOL_IP, IP_TPROXY, &itp, sizeof(itp));
if (ret < 0 ) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
"%s/%d Z-linuxpark-4: Error setsockopt (): %d:%s\n",
__FUNCTION__, __LINE__, errno, strerror (errno));
return -4;
}
// snip --//
- Original Message -
From: Junyong Jiang
To: JeHo Park
Sent: Thursday, August 05, 2010 11:26 AM
Subject: Re: [PATCH] tproxy2 patch to the apache 2.2.15
So I know!
In this case, what's the use of the bridge's IP address?
2010/8/5 JeHo Park
Junyong Jiang, previous my reply included wrong sentence, so i fixed it !
as you know, in transparent proxy mode [or in the tproxy mode], backend
server receives a packet whose source address is real client address
if you set your proxy box as NAT mode, backend server receives a packet
whose source address is the proxy server's bridge IP.
so if you set up my tproxy httpd correctly, backend server will receive a
packet whose source address is real client address
thanks~
- Original Message -
From: Junyong Jiang
To: jhp...@elim.net
Sent: Thursday, August 05, 2010 9:57 AM
Subject: Re: [PATCH] tproxy2 patch to the apache 2.2.15
Hello Park,
I want to ask you one more question. In you test of the apache tproxy
mode, on the backend server( that means the real web server), what is the
source IP address? Is it the real client's or the proxy server's bridge IP?
Thanks!
2010/8/5 JeHo Park
hello clere
- Original Message -
From: "jean-frederic clere"
To:
Sent: Wednesday, August 04, 2010 5:32 PM
Subject: Re: [PATCH] tproxy2 patch to the apache 2.2.15
> On 08/03/2010 04:57 PM, JeHo Park wrote:
>> hello ~
>> it's my first mail to apache dev .. and i am beginner of the apache.
:-)
>
> Interesting stuff... But:
> - The machine depend stuff in httpd usually goes to APR. (I would add
> the logic to APR and have a HAVE_APR_TPROXY*).
i absolutely understood what you said
> - The kernel is nice but was it accepted in the current kernels? If
yes
> since when?
no, i just ported tproxy2 kernel patch [refer the linke below] to the
CentOS kernel 2.6.18-194.el5
the mainstream of linux kernel applied tproxy4 from the version 2.6.24
but tproxy2 had not been applied ..
http://www.balabit.com/downloads/files/tproxy/
> - Without the performance results it is hard to see if it is worth the
> effort.
>
please check the link below
http://211.174.184.69/kisa-avalanche2900-20100712
and the test-result.ppt files shows the summarized result of the
performance test and etc
OS Keep-alive on forward proxy
Hi, Can you tell if the OS Keep-alive feature should be expected to work on forward proxy? The mod_proxy of latest httpd 2.2 and trunk (2.3) has OS Keep-alive (Keep-alive connection to origin server) feature, but it seems not working when we configure the httpd as the forward proxy server. If the client connection is kept alive, the proxy sends indeed "Connection: Keep-alive" to the origin server but the proxy doesn't actually try to keep the OS connection alive; it closes the OS connection immediately after receiving the response. The inconsistency between sending "Connection: Keep-alive" and immediate connection closing looks like a defect (and I've just posted a bug report 49699). But apart from the inconsistency, I wonder if the OS Keep-alive of mod_proxy is designed to work for the forward proxy in the first place. Regards, Ryujiro Shibuya
Re: HTTP trailers?
Just to kick this discussion a bit; The use cases that I've come across: - adding debug / trace information to responses (e.g., how long it took, resource consumption, errors encountered) - adding a late-bound ETag or Last-Modified to the response (so that you don't have to buffer) - adding Content-MD5 or perhaps even something cryptographically signed (ditto) I've had discussions with a few browser folks who have shown interest in making trailers available on their side (e.g., showing trace information in Firebug). I don't agree that Apache should 5xx if trailers are set and they aren't able to be sent (e.g., because of a HTTP/1.0 client); the semantics of trailers in HTTP/1.1 are that they have to be able to be ignored by clients anyway (unless TE: trailers is received in the request, which IME is very uncommon). Dropping them on the floor is a fine solution -- as long as the code inserting the trailers knows this. In the long run, it would also be interesting to have Apache examine the TE request header to determine whether trailers are supported; if they aren't, it could buffer the response and put the trailers up into the headers transparently. Of course, large responses might make this impractical, but in some cases it could be useful. Finally -- HTTPbis gives us an opportunity to refine the design of trailers if there are issues. Cheers, On 24/04/2010, at 2:01 AM, William A. Rowe Jr. wrote: > On 4/23/2010 10:25 AM, Brian J. France wrote: >> >> On Apr 23, 2010, at 10:08 AM, William A. Rowe Jr. wrote: >> >>> On 4/23/2010 9:03 AM, Brian J. France wrote: You can build a module that is able to insert a trailer by adding a filter and ap_hook_create_request call. >>> >>> But doesn't this defeat the purpose of using a modular server >>> architecture? It seems this should be a facility of the core HTTP >>> filter, if anyone wants to offer the patch for 2.3. >> >> >> I agree, my module was more of a proof of concept that I can do it and then >> get some other server to able able to use it. > > :) > >> Not sure what the best solution would be because multiple things need to >> happen. First part is you have to force chunk encoding either by removing >> content_length filter or tweaking the code to not add it if doing a trailer >> (which you might not know until it is time to insert a tailer). > > Well, you also have to insert the 'Trailers' header, which must be known at > the > beginning of the request, so that becomes a simple trigger for dropping the > content-length and forcing chunked encoding. > > "If no Trailer header field is present, the trailer SHOULD NOT include any > header > fields" is a very explicit statement :) > > This could be constructed from r->trailers_out, however users need to > understand > that after the beginning of the response, r->trailers out cannot be extended, > only > modified. > >> Then you have to tweak modules/http/chunk_filter.c to allow others to insert >> a trailer, like adding a ap_hook_http_trailer or a optional function for >> inserting it. I don't know if multiple modules should be allowed to add a >> trailer, if you do how to you join them since a trailer is nothing but a >> string ending with ASCII_CRLF (just strcat?). Should we just grab >> r->notes['http_trailer'] and let modules just add/set/append values? >> >> I think there is a bigger design discussion that should happen, but I might >> have a patch down the road as a starter if all goes well at work. > > These pieces seem more like implementation details. -- Mark Nottingham http://www.mnot.net/
Re: [PATCH] tproxy2 patch to the apache 2.2.15
hello clere - Original Message - From: "jean-frederic clere" To: Sent: Wednesday, August 04, 2010 5:32 PM Subject: Re: [PATCH] tproxy2 patch to the apache 2.2.15 > On 08/03/2010 04:57 PM, JeHo Park wrote: >> hello ~ >> it's my first mail to apache dev .. and i am beginner of the apache. :-) > > Interesting stuff... But: > - The machine depend stuff in httpd usually goes to APR. (I would add > the logic to APR and have a HAVE_APR_TPROXY*). i absolutely understood what you said > - The kernel is nice but was it accepted in the current kernels? If yes > since when? no, i just ported tproxy2 kernel patch [refer the linke below] to the CentOS kernel 2.6.18-194.el5 the mainstream of linux kernel applied tproxy4 from the version 2.6.24 but tproxy2 had not been applied .. http://www.balabit.com/downloads/files/tproxy/ > - Without the performance results it is hard to see if it is worth the > effort. > please check the link below http://211.174.184.69/kisa-avalanche2900-20100712 and the test-result.ppt files shows the summarized result of the performance test and etc > Cheers > > Jean-Frederic
Re: Failing startup for vhost configuration problems
On Thursday, August 5, 2010, Stefan Fritsch wrote: > On Tuesday 03 August 2010, Dan Poirier wrote: >> I'd like to propose that in 2.3/2.4, we fail startup for any of the >> virtual host misconfigurations for which behavior is undefined but >> right now we only issue a warning. >> >> E.g. no VirtualHosts matching a NameVirtualHost, overlapping >> VirtualHosts, use of _default_ in NameVirtualHost, mixing * and >> non-* ports in name-based virtual hosts. >> >> The rationale is that these configurations are unsupported, the >> behavior is undefined, and presumably they are the result of >> errors, so better to make sure the admin corrects the error than >> to continue and probably not behave as the admin expects. >> >> A new major version seems like a good time for a change like this. > > Makes sense. If one of the restriction turns out to be too painful in > practice, we can always allow that case again. Perhaps warnings around bad MPM configuration can be reviewed as well. >From memory it doesn't at the moment warn you when something like StartServers is set over what it can be based on MaxClients and ThreadsPerChild. I think it may just silently reduce the value. Since MPM settings are often misunderstood, better hints about bad configuration there would be useful. Graham
Re: Failing startup for vhost configuration problems
On Tuesday 03 August 2010, Dan Poirier wrote: > I'd like to propose that in 2.3/2.4, we fail startup for any of the > virtual host misconfigurations for which behavior is undefined but > right now we only issue a warning. > > E.g. no VirtualHosts matching a NameVirtualHost, overlapping > VirtualHosts, use of _default_ in NameVirtualHost, mixing * and > non-* ports in name-based virtual hosts. > > The rationale is that these configurations are unsupported, the > behavior is undefined, and presumably they are the result of > errors, so better to make sure the admin corrects the error than > to continue and probably not behave as the admin expects. > > A new major version seems like a good time for a change like this. Makes sense. If one of the restriction turns out to be too painful in practice, we can always allow that case again.
Re: svn commit: r982050 - in /httpd/httpd/trunk: modules/generators/ modules/slotmem/ modules/ssl/ server/ server/mpm/event/ server/mpm/netware/ server/mpm/prefork/
On Wednesday 04 August 2010, Jeff Trawick wrote: > > Author: sf > > Date: Tue Aug 3 22:12:19 2010 > > New Revision: 982050 > > > > URL: http://svn.apache.org/viewvc?rev=982050&view=rev > > Log: > > remove more unused variables > > revove some obsolete comments > > > > netware file is untested > > why remove AP_DEBUG_ASSERT(0)? Oops, somehow I was reading that as AP_DEBUG_ASSERT(1). Thanks for noticing.
Re: Failing startup for vhost configuration problems
On Tue, Aug 3, 2010 at 8:05 AM, Dan Poirier wrote: > I'd like to propose that in 2.3/2.4, we fail startup for any of the > virtual host misconfigurations for which behavior is undefined but right > now we only issue a warning. > > E.g. no VirtualHosts matching a NameVirtualHost, overlapping > VirtualHosts, use of _default_ in NameVirtualHost, mixing * and non-* > ports in name-based virtual hosts. > > The rationale is that these configurations are unsupported, the behavior > is undefined, and presumably they are the result of errors, so better to > make sure the admin corrects the error than to continue and probably not > behave as the admin expects. > > A new major version seems like a good time for a change like this. > > Thoughts? +1 concept (I'm lacking a sense of the frequency distribution of such config errors and related problem symptoms out in the real world)
Re: svn commit: r982050 - in /httpd/httpd/trunk: modules/generators/ modules/slotmem/ modules/ssl/ server/ server/mpm/event/ server/mpm/netware/ server/mpm/prefork/
On Tue, Aug 3, 2010 at 6:12 PM, wrote:
> Author: sf
> Date: Tue Aug 3 22:12:19 2010
> New Revision: 982050
>
> URL: http://svn.apache.org/viewvc?rev=982050&view=rev
> Log:
> remove more unused variables
> revove some obsolete comments
>
> netware file is untested
why remove AP_DEBUG_ASSERT(0)?
>
> Modified:
> httpd/httpd/trunk/modules/generators/mod_cgid.c
> httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_io.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_pphrase.c
> httpd/httpd/trunk/modules/ssl/ssl_engine_rand.c
> httpd/httpd/trunk/server/mpm/event/event.c
> httpd/httpd/trunk/server/mpm/event/fdqueue.c
> httpd/httpd/trunk/server/mpm/netware/mpm_netware.c
> httpd/httpd/trunk/server/mpm/prefork/prefork.c
> httpd/httpd/trunk/server/mpm_common.c
> httpd/httpd/trunk/server/mpm_unix.c
> httpd/httpd/trunk/server/request.c
> httpd/httpd/trunk/server/util_ebcdic.c
>
> Modified: httpd/httpd/trunk/server/mpm/event/event.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?rev=982050&r1=982049&r2=982050&view=diff
> ==
> --- httpd/httpd/trunk/server/mpm/event/event.c (original)
> +++ httpd/httpd/trunk/server/mpm/event/event.c Tue Aug 3 22:12:19 2010
> @@ -1155,7 +1155,6 @@ static void * APR_THREAD_FUNC listener_t
> ap_server_conf,
> "event_loop: unexpected state %d",
> cs->state);
> - AP_DEBUG_ASSERT(0);
> }
>
> apr_thread_mutex_lock(timeout_mutex);
>
> Modified: httpd/httpd/trunk/server/mpm/event/fdqueue.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/fdqueue.c?rev=982050&r1=982049&r2=982050&view=diff
> ==
> --- httpd/httpd/trunk/server/mpm/event/fdqueue.c (original)
> +++ httpd/httpd/trunk/server/mpm/event/fdqueue.c Tue Aug 3 22:12:19 2010
> @@ -165,7 +165,6 @@ apr_status_t ap_queue_info_wait_for_idle
> queue_info->idlers_mutex);
> if (rv != APR_SUCCESS) {
> apr_status_t rv2;
> - AP_DEBUG_ASSERT(0);
> rv2 = apr_thread_mutex_unlock(queue_info->idlers_mutex);
> if (rv2 != APR_SUCCESS) {
> return rv2;
>
Re: [PATCH] tproxy2 patch to the apache 2.2.15
On 08/03/2010 04:57 PM, JeHo Park wrote: > hello ~ > it's my first mail to apache dev .. and i am beginner of the apache. :-) Interesting stuff... But: - The machine depend stuff in httpd usually goes to APR. (I would add the logic to APR and have a HAVE_APR_TPROXY*). - The kernel is nice but was it accepted in the current kernels? If yes since when? - Without the performance results it is hard to see if it is worth the effort. Cheers Jean-Frederic
