Brothersoft - Software Download Report
Title: Software Download Report Brothersoft Software Download Report Hi, We will send you the statistics reports of your top 5 download amount software(if you have more than 5 software) every Monday. For more details of the report,please log in from http://author.brothersoft.com Brothersoft Team Become a fan of Brothersoft| Follow us @Brothersoft HAProxy 1.3.15.7 If you don't want to get the Newsletters any more, please 1.Login the user control panel here http://www.brothersoft.com/user/?act=member.login 2.Click "Manage My Newsletters" menu. 3.Uncheck the "Software Download Report" at the bottom of the page
Re: [PATCH] DOC: examples: provide simplified ssl configuration
On Thu, Jun 06, 2013 at 09:30:48PM +0200, Lukas Tribus wrote: Hi! Heres a patch to provide a simple example ssl configuration we could add to examples/*: DOC: examples: provide simplified ssl configuration (...) Applied, thank you Lukas. Willy
disable all servers on backend via socket
Hello! I have an a backend and a few servers in it. Sometimes I need to disable all servers on this backend to stop all traffic that flows to them. The best way to do this is to use haproxy unix socket connection.But there is an a question:Is there a some way to disable all servers in a backend by one command and enable them in the same way? Off course I can iterate each server and disable it, but such possibility can be very usefull. Thanks in advance!
Re: HAProxy maintains connection to proxied server after client disconnects
Hi Lukas, Thank you for your suggestion. It works! I guess this is a shortcoming of streaming and eventsource protocols, because there are two separate connections involved for each client, whereas for websocket and long-polling haproxy can tell for sure the connection breaks given there is only one connection. I guess *option abortonclose* is also good to have in general, since it helps defend against DDoS attacks? And I do not see much side-effect for turning it on. Correct me if I'm wrong here. Thanks again! Regards, Chris On Sun, Jun 9, 2013 at 11:51 AM, Lukas Tribus luky...@hotmail.com wrote: Hi Chris, you probably need to set the following option to achieve this behavior: option abortonclose http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-option%20abortonclose Regards, Lukas
RE: HAProxy latest on SSL
Probably a stupid question, but when you route to a backend configured like this will it keep SSL FC traffic on a SSL backend, or just pick one? Frontend SSL and backend SSL traffic has nothing to do with each other if thats what you mean. So both backends would be used, independently of whether the frontend connection is SSL or not. Regards, Lukas
Haproxy + nginx + naxsi
Hello all, I'm trying to make this tutorial work : http://blog.exceliance.fr/2012/10/16/high-performance-waf-platform-with-naxsi-and-haproxy/ But when I check the configuration of haproxy I've got a this errors : # haproxy -c -f /etc/haproxy/haproxy.test.cfg [ALERT] 160/191308 (22091) : parsing [/etc/haproxy/haproxy.test.cfg:32] : error detected while parsing ACL 'abuse' : ACL keyword 'sc1_http_req_rate' takes no argument. [ALERT] 160/191308 (22091) : parsing [/etc/haproxy/haproxy.test.cfg:33] : error detected while parsing ACL 'flag_abuser' : ACL keyword 'sc1_inc_gpc0' takes no argument. [ALERT] 160/191308 (22091) : parsing [/etc/haproxy/haproxy.test.cfg:34] : 'tcp-request content reject' : error detected in frontend 'ft_waf' while parsing 'if' condition : no such ACL : 'abuse' [ALERT] 160/191308 (22091) : parsing [/etc/haproxy/haproxy.test.cfg:56] : error detected while parsing ACL 'abuse' : ACL keyword 'sc1_http_err_rate' takes no argument. [ALERT] 160/191308 (22091) : parsing [/etc/haproxy/haproxy.test.cfg:57] : error detected while parsing ACL 'flag_abuser' : ACL keyword 'sc1_inc_gpc0' takes no argument. [ALERT] 160/191308 (22091) : parsing [/etc/haproxy/haproxy.test.cfg:58] : 'tcp-request content reject' : error detected in backend 'bk_waf' while parsing 'if' condition : no such ACL : 'abuse' [ALERT] 160/191308 (22091) : Error(s) found in configuration file : /etc/haproxy/haproxy.test.cfg [WARNING] 160/191308 (22091) : config : log format ignored for frontend 'ft_waf' since it has no log address. [WARNING] 160/191308 (22091) : config : log format ignored for frontend 'ft_web' since it has no log address. [ALERT] 160/191308 (22091) : Fatal errors found in configuration. I'm running on Debian Squeeze 64 bits this version of haproxy : # haproxy - HA-Proxy version 1.5-dev17 2012/12/28 Copyright 2000-2012 Willy Tarreau w...@1wt.eu Build options : TARGET = linux2628 CPU = native CC = gcc CFLAGS = -O2 -march=native -g -fno-strict-aliasing OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 USE_STATIC_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.3.4 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 0.9.8o 01 Jun 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. Any help is welcome. Best regards, Hug
RE: HAProxy maintains connection to proxied server after client disconnects
I guess this is a shortcoming of streaming and eventsource protocols, because there are two separate connections involved for each client, whereas for websocket and long-polling haproxy can tell for sure the connection breaks given there is only one connection. I'm not familiar with those protocols, I would have guessed that the same issue affects all those (long-) polling connections, where the server delays its response until a specific event is triggered. I guess option abortonclose is also good to have in general, since it helps defend against DDoS attacks? Thats depends on your backend application; if your server has long- response times (whether aritifical like in the polling/streaming case or due to a slow application) then yes; for small static files it doesn't make sense I guess. I do not see much side-effect for turning it on Its theoretically possibile that a client closes the session while waiting for the response, which is why this behavior is not fully HTTP compliant and thus disabled by default. I don't believe this is a practical problem though, since browsers don't behave this way. Regards, Lukas
Multiple Switching
Hi, I am hoping someone can help me. I am trying to use both path_beg and regrep at the same time, but it is not working. My config is as follows: frontend httpweb mode http option http-server-close bind :80 acl p_static1 path_beg /static1/ acl p_static2 path_beg /static2/ reqrep ^([^\ ]*)\ /static1/(.*) \1\ /\2 reqrep ^([^\ ]*)\ /static2/(.*) \1\ /\2 use_backend bk_web_82 if p_static1 use_backend bk_web_83 if p_static2 default_backend bk_web_http If I go to: http://ip/static1/item.htm , the backend should be http://ip:82/item.htm If I go to: http://ip/static2/item.htm , the backend should be http://ip:83/item.htm If I go to: http://ip/item.htm , the backend should be http://ip/item.htm I am finding that, the regrep works fine, but when it comes to the use_backend statement, it re-evaluates the acl and therefore always goes to the default_backend. If I comment out the regrep, I am sent to the correct backend, however this breaks what I am trying to achieve. If someone could help me, that would be great. Thanks, Chris Chris Brazier Solutions Architect IT DD 020 8780 6987 E chris.braz...@capsticks.commailto:chris.braz...@capsticks.com W www.capsticks.comhttp://www.capsticks.com capstickssignaturetag We’re supporting the Royal Hospital for Neuro-disability. Find out more about the Charity’s work at www.rhncharity.org.uk HealthInvestor Awards 2013: Finalists - Legal advisors of the year (public) HealthInvestor Awards 2012: Winner - Legal advisors of the year (public) The General Practice Awards 2011: Winner - Legal team of the year Laing Buisson - Independent Healthcare Awards 2011: Winner - Legal adviser of the year If you are not the intended recipient of the email entitled @|subject|@ then please delete the email. Disclaimer: The information contained in this communication is confidential and may be legally privileged. It is intended solely for use by the intended recipient(s) and others authorised to receive it. If you have received this message in error you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful. Please note that Capsticks does not accept service of proceedings by email. Capsticks Solicitors LLP is a limited liability partnership registered in England and Wales under registered number OC340360 and is authorised and regulated by the Solicitors Regulation Authority. A list of members is open to inspection at our registered office, 1 St Georges Road, St Georges East, Wimbledon, London, SW19 4DR or online at www.capsticks.com. The term partner is used to refer to a member of Capsticks Solicitors LLP or an employee or consultant with equivalent standing and qualifications. This footnote confirms this message has been scanned for viruses. Please consider the environment before printing this message.
Capture cookie and set as header
Sorry if this is a repeat. I sent last week but never saw it come into my inbox (Will I see my own messages come in on the list?) so I'm not sure it made it to the list. I need to capture a cookie value in a request and then append it as a http header value. I've been searching for examples for doing this with haproxy but have come up short. Is it possible? For example. If I have: Cookie: name1=999; name2=8 I want to capture the value of 'name1' and set it as 'x-header-value' which I know I could add with something like this: reqadd x-header-value:\ name1value Any examples or tips would be greatly appreciated. MG
Re: HAProxy latest on SSL
On 6/10/13 11:55 AM, Lukas Tribus wrote: Frontend SSL and backend SSL traffic has nothing to do with each other if thats what you mean. So both backends would be used, independently of whether the frontend connection is SSL or not. Maybe that should be made clear in the example. Since you have a front-end accepting both SSL and clear traffic, and a backend with SSL and clear servers, it is confusing to someone who doesn't know it works.
odd 10 seconds in websocket negotiation with more than one backend server
I'm seeing an very odd and consistent 10 second time to negotiate a websocket connection when using HAproxy, but only when I have more than one server in the rotation. Going directly to the server from the browser, I connect immediately. With only one server in the haproxy backend, I connect immediately in the browser. When I have two servers in the backend haproxy makes connections to both websocket backends and exactly 10 seconds after the client had negotiated the connection to haproxy the client considers itself connected to socket.io application. I added a stick-table based on src thinking it might help which didn't change the behavior. I tested in haproxy 1.4 (whatever the latest 12.04 LTS is shipping) and the June 1st snapshot of 1.5. Same behavior in both cases. haproxy server is a 64bit m1.small instance on EC2. I suspect that there is something off if in my cobbled together config from various blogs and serverfault answers. I can also get some proper tcpdump later tonight too. Ramin # PUPPETHEADER: This file is owned by Puppet. # vim:syntax=haproxy #- # global settings, start global daemon gid 0 maxconn 4000 pidfile /var/run/haproxy.pid stats socket /var/lib/haproxy/stats uid 0 ulimit-n 8192 log 127.0.0.1 local0 notice # global settings, end #- #- # default settings, start defaults mode http log global option httplog option http-server-close option dontlognull option redispatch option contstats retries 3 backlog 1 timeout client 25s timeout connect 5s timeout server 25s # timeout tunnel available in ALOHA 5.5 or HAProxy 1.5-dev10 and higher # timeout tunnel3600s timeout http-keep-alive 1s timeout http-request15s timeout queue 30s timeout tarpit 60s default-server inter 3s rise 2 fall 3 option forwardfor # default settings, end #- #- # frontend settings, start of ws frontend ws bind *:80 default_backend ws # frontend settings, end of ws #- #- # backend settings, start of ws backend ws balance roundrobin stick store-request src stick-table type ip size 200k expire 20m server fe01 fe01.stage.usw2.example.com:8000 maxconn 1000 check server fe03 fe03.stage.usw2.example.com:8000 maxconn 1000 check # backend settings, end of ws #-
RE: HAProxy latest on SSL
Maybe that should be made clear in the example. Since you have a front-end accepting both SSL and clear traffic, and a backend with SSL and clear servers, it is confusing to someone who doesn't know it works. The fact that both sides have encrypted and unencrypted traffic types was intentional; the idea being that since we are in HTTP mode we will always do request processing at layer 7 : so SSL processing needs to be decoupled from the other tasks, and I did implied this with this example. Do you have a concrete suggestion how to make this clearer? Regards, Lukas
RE: CPU spike after restarting with -sf pid
That's sound advice. We'll upgrade soon and see whether anything changes. Is the latest snapshot really what you recommend for running in production? I was nervous about using a dev release but we desperately needed support for the proxy protocol. On Fri, Jun 07, 2013 at 03:16 PM, Lukas Tribus luky...@hotmail.com wrote: Hi Malcolm, This works but we find that the new haproxy process uses a lot of cpu (100% of one core) for about 20 seconds after the restart. During this time it looks as if various queues fill up and haproxy logs fewer requests than normal. Once the cpu load drops we get a surge of requests (which cause a spike in connections to our db, and a raft of other problems if we do this during heavy traffic). I strongly suggest to update your code to a more recent release, there have been a lot of bug fixes since dev15. Grab dev18 or better yet, the latest snapshot. It doesn't make sense to start troubleshooting on those obsolete releases, especially in the development branch. Lukas
Re: HAProxy latest on SSL
On 6/10/13 7:18 PM, Lukas Tribus wrote: Do you have a concrete suggestion how to make this clearer? I think just make it clear that if you want SSL front-end traffic to go to SSL back-end traffic you need this: use-server backend:80 if !{ ssl_fc } use-server backend:443 if { ssl_fc } IMHO, it's confusing having clear and SSL backends defined and they being equivalent from a traffic routing perspective - I realize that's one of the great things HAProxy does, but might not be clear to a person new to the app. David
Re: CPU spike after restarting with -sf pid
Hi Malcolm, Le 11/06/2013 02:01, Malcolm Handley a écrit : I was nervous about using a dev release but we desperately needed support for the proxy protocol. If you only need the accept-proxy feature in the bind options and you are not comfortable with following the dev branch, I ported it to haproxy 1.4. It is used in production since about 3 years without any problems (first time was with haproxy 1.4.10). I provide it as a patch on github (created more recently) : https://github.com/cbonte/haproxy-patches/blob/master/proxy-protocol/haproxy-1.4-proxy-protocol.patch Each time a new stable version of haproxy is available, I update the patch. Maybe it can help you too. -- Cyril Bonté