Is it possible to rewrite or redirect based on path
I have an acl rule to see if path begins with /ww as in domain.tdl/ww/en... acl has_ww_uri path_beg -i /ww If it is just the domain.tdl, I want to rewrite it to /ww ~ example.com/ww Do I do it like something like this: !has_ww_uri reqirep ^([^\ :]*)\ /(.*) \1\ /ww\2 But this does not work, does anyone have any idea how I can do this? Do I have to create a backend to do the rewrite? use_backend needsrewrite if !has_ww_uri backend needsrewrite reqirep ^([^\ :]*)\ /(.*) \1\ /ww\2 or this server Backend1 10.0.0.1:80 redir http:// example.com/backend1 ... Because I have more logic that this would bypass, like all my checks to see what servers are up, so I would have to have more backends defined for this to work, so I thought I would ask first for an easier way. Is there a way to modify this to work: redirect location http://domain.tdl/ww code 301 if !has_ww_uri so I do not have to use a full url, since I might have many on this account, so its not hard coded: redirect location /ww code 301 if !has_ww_uri I do not have Apache Loaded, so I can not use mod_rewrite, this is a Wt Application running httpd. Thanks
Re: jBoss thread count issue while upgrading from 1.5dev21 to 1.5.1
Hi, On Wed, Jun 25, 2014 at 10:00:25AM +0530, Sarvesh Padwal wrote: > Dear Team, > > We upgraded my haproxy from 1.5dev21 to 1.5.1 stable version with same > configuartion. At the backend, we are using jBoss. > As soon as we upgraded, we encountered serious issue regarding jBoss thread > counts. It has been increased tremendously. > After rollback to 1.5dev21, everything works fine. > Please find my below configuration file of haproxy. Kindly suggest any > changes required to migrate/upgrade to 1.5.1. Since then we've added support for server-side keep-alive, so it could be related, though you're working in forceclose mode so you shouldn't be affected. However, there are no logs in your config, so it's really hard to guess what could be happening :-/ Did you at least save a copy of the stats page when you first detected the issue ? Also, did you see the jboss thread count slowly increase or did you feel like it went high very fast (as if connections were not closed anymore), or very slow (as if it was related to health checks) ? I have a few unrelated comments concerning your configuration below : > backend backend_http > mode http > cookie JSESSIONID prefix > balance leastconn > option forceclose > option persist > option redispatch > option forwardfor > server server3 192.168.58.211:80 cookie server3_cokkie maxconn 1024 > check Here you wrote "server3_cokkie" instead of "server3_cookie" as tested in the ACL below. I think it might be the value you changed by hand before posting the configuration, but just in case you may want to double-check. > server server4 192.168.58.212:80 cookie server4_cookie maxconn 1024 > check > acl force_sticky_server3 hdr_sub(server3_cookie) TEST=true The way you're using your HTTP headers seems very strange to me, what I understand here is that in order to force access to server3, you add a header named "server3_cookie" and put the value "TEST=true" in it. If so, that's quite ugly. If you pick both 3 and 4, the first one wins. If for any reason you need to use headers instead of cookies to pick your server, you should use the same header and put the server name in it, it will be safer. And better prepend "X-" in front of your custom headers to avoid messing up with valid ones. > force-persist if force_sticky_server3 > acl force_sticky_server4 hdr_sub(server4_cookie) TEST=true > force-persist if force_sticky_server4 > rspidel ^Server:.* > rspidel ^X-Powered-By:.* > rspidel ^AMF-Ver:.* > > listen frontend_http *:80 >mode http >maxconn 2 >default_backend backend_http When you have no server, you'd rather declare a "frontend" section instead of a "listen" section. > listen frontend_https >mode http >maxconn 2 >bind *:443 ssl crt /opt/haproxy-ssl/conf/ssl/testsite.pem >reqadd X-Forwarded-Proto:\ https >reqadd X-Forwarded-Protocol:\ https >reqadd X-Forwarded-Port:\ 443 >reqadd X-Forwarded-SSL:\ on >acl valid_domains hdr_end(host) -i gateway.testsite.com > www.testsite.com m.testsite.com >redirect scheme http if !valid_domains >default_backend backend_http if valid_domains Same here. Regards, Willy
jBoss thread count issue while upgrading from 1.5dev21 to 1.5.1
Dear Team, We upgraded my haproxy from 1.5dev21 to 1.5.1 stable version with same configuartion. At the backend, we are using jBoss. As soon as we upgraded, we encountered serious issue regarding jBoss thread counts. It has been increased tremendously. After rollback to 1.5dev21, everything works fine. Please find my below configuration file of haproxy. Kindly suggest any changes required to migrate/upgrade to 1.5.1. - global daemon maxconn 2 defaults mode http timeout connect 15000ms timeout client 5ms timeout server 5ms timeout queue 60s stats enable stats refresh 5s backend backend_http mode http cookie JSESSIONID prefix balance leastconn option forceclose option persist option redispatch option forwardfor server server3 192.168.58.211:80 cookie server3_cokkie maxconn 1024 check server server4 192.168.58.212:80 cookie server4_cookie maxconn 1024 check acl force_sticky_server3 hdr_sub(server3_cookie) TEST=true force-persist if force_sticky_server3 acl force_sticky_server4 hdr_sub(server4_cookie) TEST=true force-persist if force_sticky_server4 rspidel ^Server:.* rspidel ^X-Powered-By:.* rspidel ^AMF-Ver:.* listen frontend_http *:80 mode http maxconn 2 default_backend backend_http listen frontend_https mode http maxconn 2 bind *:443 ssl crt /opt/haproxy-ssl/conf/ssl/testsite.pem reqadd X-Forwarded-Proto:\ https reqadd X-Forwarded-Protocol:\ https reqadd X-Forwarded-Port:\ 443 reqadd X-Forwarded-SSL:\ on acl valid_domains hdr_end(host) -i gateway.testsite.com www.testsite.com m.testsite.com redirect scheme http if !valid_domains default_backend backend_http if valid_domains --
Re: Email Alert Proposal
On Tue, Jun 24, 2014 at 07:29:15AM +0200, Willy Tarreau wrote: > Hi Simon, > > On Tue, Jun 24, 2014 at 09:15:13AM +0900, Simon Horman wrote: > > Hi Willy, > > > > Malcolm has asked me to open a discussion with you regarding adding > > email alerts to haproxy and that is the purpose of this email. > > > > In essence the motivation is to provide a lightweight email alert > > feature that may be used in situations where a full-blown monitoring > > system is not in use. > > > > There is some discussion of this topic and several solutions, > > including patches to haproxy, on the loadbalancer.org log. > > > > http://blog.loadbalancer.org/3-ways-to-send-haproxy-health-check-email-alerts/ > > > > Would you be open to including such a feature in haproxy? > > > > If so I had it in mind to have haproxy send emails using the sendmail > > command, > > a variation of the mailx implementation at the link above, avoiding the > > need to implement an SMTP client. > > > > I was thinking it could be configured using directives like the following, > > borrowing ideas from my recent external-agent patch. > > > > global > > email-alert > > > > listen ... > > > > option email-alert > > email-alert command sendmail > > email-alert path/usr/sbin:/usr/lib > > email-alert fromfrom@x.y.z > > email-alert to to@x.y.z > > email-alert cc cc1@x.y.z, cc2@x.y.z > > email-alert bcc bcc@x.y.z > > email-alert subject Loadbalancer alert > > email-alert custom-header X-Custom: foo > > > > It might be nice to allow the use of printf style directives in > > the subject to allow it to include the name of the proxy and other > > useful information. I expect that different users have different needs > > there. > > We had such an idea in the past, however the principle was to use the > address of a smart relay host. We cannot use a command because the process > is supposed to be chrooted. Thanks, if that is the direction you wish to take things then I'm happy to do so. I guess a simple SMTP client is not an insurmountable challenge. But I wonder if there is any infrastructure in haproxy that might make such an implementation easier. If so, could you point me at it? > Also, in my opinion the SMTP relay should be > per section (ie: supported in the defaults section) because in shared > environments, customers want to use a different gateway and e-mail > settings. Yes, I agree that sounds like a good idea. > In fact in the ALOHA we have implemented a daemon which watches > the unix socket to send e-mails because by then it was too much work to > implement it natively. Now it should be much simpler. I'm clad to hear it will be simpler though I'm not sure that I understand why this is so. > I was just wondering whether we should not go slightly further and support > "mailer" sections just like we have peers. I'd like to do the same for DNS > resolving later and I think it makes the configs more understandable, and > more flexible (eg: later we can think about having multiple mail relays). I also agree that sounds reasonable. I'll see about making it so. > We also want to have the ability to define what events can result in an > e-mail alert. For example, I know some hosting providers who absolutely > want to know when a service is operational again (so that they can drive > back home), while others absolutely refuse to be spammed with such info. Thanks. I meant to include that in my proposal. I agree it is important. > Sections also make it possible to add extra settings for the mail relays, > for example SSL + a certificate. Or maybe some default from/to/... Agreed. I would prefer to only handle plain-text to start with. To allow a working prototype to be slightly closer to hand. But I agree that SSL support, I assume in the form of STLS, is an important feature.
Re: [ANNOUNCE] haproxy-1.5.1
On Tue, Jun 24, 2014 at 04:19:20PM +0200, Olivier wrote: > > I don't understand, you're the third one to tell me that, while I have > > updated it 5 minutes after the announce. One of my coworkers had the > > same issue while I had it display the updated version, and he saw it > > correctly after a forced reload, indicating that the old copy was > > cached in his browser. But I find it surprizing that so many people > > have a browser doing excessive caching :-/ > > i'm sure this is not browser caching, I made sure of this before > disturbing you with an email ;) > > GET / HTTP/1.1 > Host: www.haproxy.org > [...] > HTTP/1.1 200 OK > Date: Tue, 24 Jun 2014 14:16:32 GMT > Server: Apache (Unix; Formilux/0.1.8) > Last-Modified: Tue, 24 Jun 2014 10:52:28 GMT > Accept-Ranges: bytes > Cache-Control: max-age=28800 > Expires: Tue, 24 Jun 2014 22:16:32 GMT > Vary: Accept-Encoding > Content-Type: text/html > Content-Encoding: gzip > X-Cache: MISS from www.haproxy.org > Transfer-Encoding: chunked > [...] > 1.5.0 Ah OK, we were not speaking about the same thing, due to the previous report of my coworker. In your case these are just the links, and yes I forgot to update them :-) Done now! Thanks for the explanation ! Willy
Re: [ANNOUNCE] haproxy-1.5.1
> I don't understand, you're the third one to tell me that, while I have > updated it 5 minutes after the announce. One of my coworkers had the > same issue while I had it display the updated version, and he saw it > correctly after a forced reload, indicating that the old copy was > cached in his browser. But I find it surprizing that so many people > have a browser doing excessive caching :-/ i'm sure this is not browser caching, I made sure of this before disturbing you with an email ;) GET / HTTP/1.1 Host: www.haproxy.org [...] HTTP/1.1 200 OK Date: Tue, 24 Jun 2014 14:16:32 GMT Server: Apache (Unix; Formilux/0.1.8) Last-Modified: Tue, 24 Jun 2014 10:52:28 GMT Accept-Ranges: bytes Cache-Control: max-age=28800 Expires: Tue, 24 Jun 2014 22:16:32 GMT Vary: Accept-Encoding Content-Type: text/html Content-Encoding: gzip X-Cache: MISS from www.haproxy.org Transfer-Encoding: chunked [...] 1.5.0 [...]
Re: [ANNOUNCE] haproxy-1.5.1
Hi Olivier, On Tue, Jun 24, 2014 at 04:04:11PM +0200, Olivier wrote: > Hello, > > > The usual URLs follow : > > Site index : http://www.haproxy.org/ > > Homepage is not updated with link to 1.5.1 (still referencing 1.5.0). I don't understand, you're the third one to tell me that, while I have updated it 5 minutes after the announce. One of my coworkers had the same issue while I had it display the updated version, and he saw it correctly after a forced reload, indicating that the old copy was cached in his browser. But I find it surprizing that so many people have a browser doing excessive caching :-/ Regards, Willy
Re: [ANNOUNCE] haproxy-1.5.1
Hello, > The usual URLs follow : > Site index : http://www.haproxy.org/ Homepage is not updated with link to 1.5.1 (still referencing 1.5.0). Olivier
Re: 3rd regression : enough is enough!
*From: *Lukas Tribus *Sent: * 2014-06-24 06:44:44 EDT *To: *Willy Tarreau , Patrick Hemmer *CC: *haproxy@formilux.org , Rachel Chavez *Subject: *RE: 3rd regression : enough is enough! > > >> Date: Tue, 24 Jun 2014 07:33:41 +0200 >> From: w...@1wt.eu >> To: hapr...@stormcloud9.net >> CC: haproxy@formilux.org; rachel.chave...@gmail.com >> Subject: Re: 3rd regression : enough is enough! >> >> Hi Patrick, >> >> On Mon, Jun 23, 2014 at 09:30:11PM -0400, Patrick Hemmer wrote: >>> This is unfortunate. I'm guessing a lot of the issue was in ensuring the >>> client timeout was observed. Would it at least be possible to change the >>> response, so that even if the server timeout is what kills the request, >>> that the client gets sent back a 408 instead of a 503? >> For now I have no idea. All the mess came from the awful changes that >> were needed to ignore the server-side timeout and pretend it came from >> the client despite the server triggering first. This required to mess >> up with these events in a very dangerous way :-( >> >> So right now I'd suggest to try with a shorter client timeout than the >> server timeout. I can try to see how to better *report* this specific >> event if needed, but I don't want to put the brown paper bag on >> timeouts anymore. > I fully agree. > > > But perhaps we can document the current behavior in those particular > conditions better, so that this is better known until we find a good > code-based solution. > > > What is the issue here exactly? When the client uploads large POST > requests and the server timeout is larger than the client timeout, > we will see a sD flag in the log? Is that all, or are there other > conditions in which a client timeout trigger a sD log? The issue is that the 'timeout client' parameter isn't being observed once the client goes into the data phase. If the server is waiting for data (http body), it won't send anything back until the client sends in a body. Since 'timeout client' isn't being observed, the 'timeout server' kicks in and haproxy responds with a 503 because the server took too long to respond when it was really the client's issue because the client didn't send a body. This is supposed to be a 408. > Can it be workarounded completely by configuring the server timeout > larger then the client timeout? > > > > > > Regards, > > Lukas > >
Re: 3rd regression : enough is enough!
*From: *Willy Tarreau *Sent: * 2014-06-24 01:33:41 EDT *To: *Patrick Hemmer *CC: *haproxy@formilux.org, Rachel Chavez *Subject: *Re: 3rd regression : enough is enough! > Hi Patrick, > > On Mon, Jun 23, 2014 at 09:30:11PM -0400, Patrick Hemmer wrote: >> This is unfortunate. I'm guessing a lot of the issue was in ensuring the >> client timeout was observed. Would it at least be possible to change the >> response, so that even if the server timeout is what kills the request, >> that the client gets sent back a 408 instead of a 503? > For now I have no idea. All the mess came from the awful changes that > were needed to ignore the server-side timeout and pretend it came from > the client despite the server triggering first. This required to mess > up with these events in a very dangerous way :-( > > So right now I'd suggest to try with a shorter client timeout than the > server timeout. That's what we're doing. The 'timeout client' is set to 6, 'timeout server' is set to 17 > I can try to see how to better *report* this specific > event if needed, but I don't want to put the brown paper bag on > timeouts anymore. > > Regards, > Willy >
RE: 3rd regression : enough is enough!
> Date: Tue, 24 Jun 2014 07:33:41 +0200 > From: w...@1wt.eu > To: hapr...@stormcloud9.net > CC: haproxy@formilux.org; rachel.chave...@gmail.com > Subject: Re: 3rd regression : enough is enough! > > Hi Patrick, > > On Mon, Jun 23, 2014 at 09:30:11PM -0400, Patrick Hemmer wrote: >> This is unfortunate. I'm guessing a lot of the issue was in ensuring the >> client timeout was observed. Would it at least be possible to change the >> response, so that even if the server timeout is what kills the request, >> that the client gets sent back a 408 instead of a 503? > > For now I have no idea. All the mess came from the awful changes that > were needed to ignore the server-side timeout and pretend it came from > the client despite the server triggering first. This required to mess > up with these events in a very dangerous way :-( > > So right now I'd suggest to try with a shorter client timeout than the > server timeout. I can try to see how to better *report* this specific > event if needed, but I don't want to put the brown paper bag on > timeouts anymore. I fully agree. But perhaps we can document the current behavior in those particular conditions better, so that this is better known until we find a good code-based solution. What is the issue here exactly? When the client uploads large POST requests and the server timeout is larger than the client timeout, we will see a sD flag in the log? Is that all, or are there other conditions in which a client timeout trigger a sD log? Can it be workarounded completely by configuring the server timeout larger then the client timeout? Regards, Lukas
[ANNOUNCE] haproxy-1.5.1
Hi all, we've got a few bug reports since 1.5.0, among which a very annoying one reported by Finn Arne Gangstad which causes file descriptor leaks since 1.5-dev25 for clients that disappear without disconnecting. Thus I'm releasing 1.5.1 early, before everyone gets hit by this nasty bug. The usual URLs follow : Site index : http://www.haproxy.org/ Sources : http://www.haproxy.org/download/1.5/src/ Git repository : http://git.haproxy.org/git/haproxy-1.5.git/ Git Web browsing : http://git.haproxy.org/?p=haproxy-1.5.git Changelog: http://www.haproxy.org/download/1.5/src/CHANGELOG Cyril's HTML doc : http://cbonte.github.com/haproxy-dconv/configuration-1.5.html And the small change log : 2014/06/24 : 1.5.1 - BUG/MINOR: config: http-request replace-header arg typo - BUG/MINOR: ssl: rejects OCSP response without nextupdate. - BUG/MEDIUM: ssl: Fix to not serve expired OCSP responses. - BUG/MINOR: ssl: Fix OCSP resp update fails with the same certificate configured twice. - BUG/MEDIUM: Consistently use 'check' in process_chk - BUG/MAJOR: session: revert all the crappy client-side timeout changes - BUG/MINOR: logs: properly initialize and count log sockets Please continue to report anything abnormal! Best regards, Willy
Re: Increasing MAX_SYSLOG_LEN
Hi Eugene, On Sat, Jun 21, 2014 at 10:27:17AM +0300, Eugene Istomin wrote: > Hello, > > right now MAX_SYSLOG_LEN is hardcoded in log.h. We have JSON-based > logging with rsyslog parsing, some logs are more then 1024 and i think, > fits in 2048. > > Do you have plans to make syslog_len configuration file variable? > > In February Herve has an idea about this: > http://comments.gmane.org/gmane.comp.web.haproxy/15099[1] Yes it could possibly be done, as it does not look hard to implement, it's just that someone has to work on it. Are you willing to provide a patch ? Thanks, Willy
Re: Email Alert Proposal
On Tue, Jun 24, 2014 at 07:29:15AM +0200, Willy Tarreau wrote: > Maybe we should bring this discussion to the mailing list so that other > users can suggest some features we don't have in mind ? hehe -ENOCOFFEE, I didn't notice the ML was already CC'd :-) Willy
