RE: send/accept-proxy over unix socket not working
> Date: Wed, 18 Mar 2015 01:49:47 +0100 > From: denni...@conversis.de > To: luky...@hotmail.com; jarno.huusko...@uef.fi > CC: haproxy@formilux.org > Subject: Re: send/accept-proxy over unix socket not working > > On 13.03.2015 18:44, Lukas Tribus wrote: >>> What version of haproxy are you using ? (And what OS) ? >>> In the first frontend I set: server clear /var/lib/haproxy/test send-proxy In the second frontend I set: bind /var/lib/haproxy/test accept-proxy >>> >>> Are you able to connect to the /var/lib/haproxy/test socket with >>> netcat or socat ? And/or do you have chroot in haproxy.cfg ? >> >> Also if you drop privileges, check permission with the haproxy user. >> >> If supported by your kernel, you could use abstract namespaces >> instead. > > According to the documentation abstract namespaces are not recommended > when using nbproc> 1. The reason I'm dealing with unix sockets at all > is that I want to get around the problem of losing the stick table > content on reload I posted about in another mail. The idea is to run two > instances. One with nbproc> 1 for ssl offloading and that forwards the > requests to the second instance that is using nbproc = 1 and contains > the http frontend and a backend. In theory this should allow me to > reload the config of the backend instance without losing the stick table > content. > > I'm using chroot /var/lib/haproxy but the behavior is the same without > this directive. Either way a socket gets created as > /var/lib/haproxy/test as intended but for some reason I keep getting 503 > when using a unix socket but everything works fine when using abstract > namespaces or an ip address. > > I've attached the configuration and the debug output in case that helps > to pinpoint the issue. Comment user and group and run haproxy as root. If thats works, it means you have a permission problem. Lukas
Re: send/accept-proxy over unix socket not working
On Wed, Mar 18, 2015 at 1:07 PM, Lukas Tribus wrote: > > > >> Date: Wed, 18 Mar 2015 01:49:47 +0100 >> From: denni...@conversis.de >> To: luky...@hotmail.com; jarno.huusko...@uef.fi >> CC: haproxy@formilux.org >> Subject: Re: send/accept-proxy over unix socket not working >> >> On 13.03.2015 18:44, Lukas Tribus wrote: What version of haproxy are you using ? (And what OS) ? > In the first frontend I set: > server clear /var/lib/haproxy/test send-proxy > > In the second frontend I set: > bind /var/lib/haproxy/test accept-proxy Are you able to connect to the /var/lib/haproxy/test socket with netcat or socat ? And/or do you have chroot in haproxy.cfg ? >>> >>> Also if you drop privileges, check permission with the haproxy user. >>> >>> If supported by your kernel, you could use abstract namespaces >>> instead. >> >> According to the documentation abstract namespaces are not recommended >> when using nbproc> 1. The reason I'm dealing with unix sockets at all >> is that I want to get around the problem of losing the stick table >> content on reload I posted about in another mail. The idea is to run two >> instances. One with nbproc> 1 for ssl offloading and that forwards the >> requests to the second instance that is using nbproc = 1 and contains >> the http frontend and a backend. In theory this should allow me to >> reload the config of the backend instance without losing the stick table >> content. >> >> I'm using chroot /var/lib/haproxy but the behavior is the same without >> this directive. Either way a socket gets created as >> /var/lib/haproxy/test as intended but for some reason I keep getting 503 >> when using a unix socket but everything works fine when using abstract >> namespaces or an ip address. >> >> I've attached the configuration and the debug output in case that helps >> to pinpoint the issue. > > Comment user and group and run haproxy as root. If thats works, it means > you have a permission problem. > > > Lukas > > > Hi He has a permission problem! That's what I mentionned with the user parameter on the bind line.. Actually, HAProxy starts up as root and create the socket with root user, then it drops it switches to user haproxy, group haproxy (according to your conf). This user is not allowed to access the socket, since there is no write allowed for "others". To fix your issue, simply update your bind line: bind /var/lib/haproxy/test accept-proxy user haproxy group haproxy Same on server line: server clear /var/lib/haproxy/test send-proxy user haproxy group haproxy Hope this helps. Baptiste
RE: HAProxy signal queue not working correctly
As a workaround I've patched haproxy to check if a signal is present in the
signal queue, rather than rely on the signal_state[sig].count to determine
whether to add it.
--- a/src/signal.c 2015-02-01 06:54:32.0 +
+++ b/src/signal.c 2015-03-18 11:30:19.683413000 +
@@ -35,6 +35,17 @@
* Signal number zero has a specific status, as it cannot be delivered by the
* system, any function may call it to perform asynchronous signal delivery.
*/
+
+static int is_signal_queued(int sig)
+{
+ int i = 0;
+ while (i++ < signal_queue_len) {
+if (sig == signal_queue[i])
+ return 1;
+ }
+ return 0;
+}
+
void signal_handler(int sig)
{
if (sig < 0 || sig >= MAX_SIGNAL) {
@@ -44,7 +55,7 @@
return;
}
- if (!signal_state[sig].count) {
+ if (!is_signal_queued(sig)) {
/* signal was not queued yet */
if (signal_queue_len < MAX_SIGNAL)
signal_queue[signal_queue_len++] = sig;
From: Alan Fitton [mailto:alan.fit...@ig.com]
Sent: 17 March 2015 16:02
To: haproxy@formilux.org
Subject: HAProxy signal queue not working correctly
Hello,
We are in the process of deploying HAProxy to replace our existing internal
load balancers, 41 installations in our test environment. Backends will be
added and removed from the configuration automatically (maybe a few times an
hour) and then the "reload" functionality used.
Every few days, I find that 2 to 4 have ended up in a state where the reload
function doesn't work. More specifically, the SIGTTOU is ignored by the
existing HAProxy process, so the new one is unable to bind to its port.
I've been looking at the way HAProxy does signal handling and inspecting the
process using gdb. I think I can see why the signal is ignored, but am unsure
how exactly it ends up in this state.
Basically the signal_queue isn't being updated with a reference to SIGTTOU,
because signal_state[SIGTTOU].count is > 0. I guess there's an assumption in
the code that if any given signal already has events counted up in
signal_state, then it must have updated signal_queue so they will get processed
soon. But from what I see below, this doesn't seem to be the case always, and
then all events of a particular signal can end up getting "lost". I think there
is some timing or logic issue here.
(22 = SIGTTOU)
/* Break on SIGTTOU. There are 805 events in the
Program received signal SIGTTOU, Stopped (tty output).
0x2b369ab6a373 in __epoll_wait_nocancel () from /lib64/libc.so.6
(gdb) print signal_state[22]
$16 = {count = 805, handlers = {n = 0xe1efa80, p = 0xe1efa80}}
(gdb) print signal_queue_len
$17 = 0
(gdb) c
Continuing.
Program received signal SIGTTIN, Stopped (tty input).
0x2b369aac5320 in sigaction () from /lib64/libc.so.6
(gdb) print signal_queue_len
$18 = 0
(gdb) print signal_state[22]
$19 = {count = 806, handlers = {n = 0xe1efa80, p = 0xe1efa80}} <-- signal has
been counted, but they never get processed
(gdb) c
Continuing.
This is on RHEL5. Reload functionality is the reason we chose haproxy so it's
really important to us that it works correctly :) Please let me know if any
more details would be useful.
Thanks and Best Regards,
The information contained in this email is strictly confidential and for the
use of the addressee only, unless otherwise indicated. If you are not the
intended recipient, please do not read, copy, use or disclose to others this
message or any attachment. Please also notify the sender by replying to this
email or by telephone (+44(020 7896 0011) and then delete the email and any
copies of it. Opinions, conclusion (etc) that do not relate to the official
business of this company shall be understood as neither given nor endorsed by
it. IG is a trading name of IG Markets Limited (a company registered in England
and Wales, company number 04008957) and IG Index Limited (a company registered
in England and Wales, company number 01190902). Registered address at Cannon
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Both IG Markets Limited
(register number 195355) and IG Index Limited (register number 114059) are
authorised and regulated by the Financial Conduct Authority.
Re: Haproxy 1.5 ssl redirect
Thanks for the link. That looks promising, but testing did not change anything and I am waiting on the developers to give me some indication of what headers they may expect. Maybe we can tackle this a different way since we know it works in apache. I am attempting to replace the following VirtualHost in apache and put it into haproxy: ## [test.test123.com] ServerName test.test123.com SSLEngine on SSLProtocol all -SSLv3 SSLHonorCipherOrder On SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM:!SSLV2:!eNULL ProxyPassReverse / http://10.0.60.5/ ProxyPass / http://10.0.60.5/ what haproxy frontend settings do I need to make this match whatever apache and mod_proxy is doing? 10.0.60.5:80 is already in haproxy I think the problem may be that there are some headers getting set by ProxyPass and ProxyPassReverse that I am not setting in haproxy. More specifically, I think that the apache ProxyPassReverse is rewiting the problem URI to https, and haproxy is not. --Sean Patronis Auto Data Direct Inc. 850.877.8804 On 03/17/2015 06:24 PM, Cyril Bonté wrote: Hi, Le 17/03/2015 20:42, Sean Patronis a écrit : Unfortunately that did not fix it. I mirrored your config and the problem still exists. I am not quite sure how the URL is getting built on the backend (the developers say it is all relative URL/URI), but whatever haproxy is doing, it is doing it differently than apache (with mod_proxy). Just for fun, I swapped back the ssl termination to apache to prove that is does not have an issue (once it passes through apache for ssl, it still goes through Haproxy and all of the backends/acl etc). My goal in all of this was to ditch apache and go all haproxy on the front end. Any other ideas? Have a look at this answer : http://permalink.gmane.org/gmane.comp.web.haproxy/10361 I assume that your application is not aware of an SSL termination, so you have to notify it with the right configuration, which depends on your backends softwares. Can you provide some information on them ? --Sean Patronis Auto Data Direct Inc. 850.877.8804 On 03/17/2015 11:51 AM, Scott McKeown|redIT wrote: Hi Sean, I've got a setup that is somewhat like what you are after. I have however, done it in a very dirrerent way for this very same reason. Example below: global log /dev/log local4 debug maxconn 4096 daemon tune.ssl.default-dh-param 2048 ssl-default-bind-ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH ssl-default-bind-options no-sslv3 ssl-default-server-ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH ssl-default-server-options no-sslv3 defaults log global option httplog retries 3 timeout client 5 timeout connect 5 timeout server 5 listen http-in bind x.x.x.x:80 mode http default_backend www_redit listen https-in bind x.x.x.x:443 ssl crt /etc/certs/server_2015.pem mode http acl samson_vpn_gateway src 10.8.0.1 acl missing_nagios_slash path_reg -i ^/nagios3[^/]*$ acl missing_cacti_slash path_reg -i ^/cacti[^/]*$ acl missing_dradis_slash path_reg -i ^/customers[^/]*$ redirect code 301 prefix / drop-query append-slash if missing_nagios_slash redirect code 301 prefix / drop-query append-slash if missing_cacti_slash redirect code 301 prefix / drop-query append-slash if missing_dradis_slash acl is_nagios path_reg -i /nagios3/ acl is_cacti path_reg -i /cacti/ acl is_dradis path_reg -i /customers/ #VPN Access Only use_backend services if is_nagios samson_vpn_gateway use_backend services if is_cacti samson_vpn_gateway use_backend dradis if is_dradis default_backend corp_site listen corp_site mode http log global option httpclose source 0.0.0.0 usesrc clientip option forwardfor server websites01 172.16.0.10:80 check inter 3000 fall 3 server services1 172.16.0.5:80 check inter 3000 fall 3 listen www_redit mode http redirect scheme https This should do the trick for you you may want to try putting your reqrep in or play around with the acl list and re-test with your Headers but I've got mine built with TProxy enabled. ~Scott On 17/03/2015 15:36, Sean Patronis wrote: I seem to be having an interesting issue with forced ssl redirects in Haproxy 1.5.11 Sorry if this sounds clear as mud, but here goes: When I load a domain that is served by haproxy that is supposed to force https, it initially forces the connection to be https (if you attempt to connect over http), but I get a Mixed content warning when it attempts to load another u
Re: Haproxy 1.5 ssl redirect
Hi Sean, You may find some useful information here: http://blog.haproxy.com/2014/04/28/howto-write-apache-proxypass-rules-in-haproxy/ and here: http://blog.haproxy.com/2013/02/26/ssl-offloading-impact-on-web-applications/ Baptiste On Wed, Mar 18, 2015 at 3:39 PM, Sean Patronis wrote: > Thanks for the link. That looks promising, but testing did not change > anything and I am waiting on the developers to give me some indication of > what headers they may expect. Maybe we can tackle this a different way > since we know it works in apache. I am attempting to replace the following > VirtualHost in apache and put it into haproxy: > > ## [test.test123.com] > > ServerName test.test123.com > SSLEngine on > SSLProtocol all -SSLv3 > SSLHonorCipherOrder On > SSLCipherSuite > ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM:!SSLV2:!eNULL > ProxyPassReverse / http://10.0.60.5/ > ProxyPass / http://10.0.60.5/ > > > what haproxy frontend settings do I need to make this match whatever apache > and mod_proxy is doing? > > 10.0.60.5:80 is already in haproxy I think the problem may be that > there are some headers getting set by ProxyPass and ProxyPassReverse that I > am not setting in haproxy. More specifically, I think that the apache > ProxyPassReverse is rewiting the problem URI to https, and haproxy is not. > > --Sean Patronis > Auto Data Direct Inc. > 850.877.8804 > > On 03/17/2015 06:24 PM, Cyril Bonté wrote: >> >> Hi, >> >> Le 17/03/2015 20:42, Sean Patronis a écrit : >>> >>> Unfortunately that did not fix it. I mirrored your config and the >>> problem still exists. I am not quite sure how the URL is getting built >>> on the backend (the developers say it is all relative URL/URI), but >>> whatever haproxy is doing, it is doing it differently than apache (with >>> mod_proxy). Just for fun, I swapped back the ssl termination to apache >>> to prove that is does not have an issue (once it passes through apache >>> for ssl, it still goes through Haproxy and all of the backends/acl etc). >>> >>> My goal in all of this was to ditch apache and go all haproxy on the >>> front end. >>> >>> Any other ideas? >> >> >> Have a look at this answer : >> http://permalink.gmane.org/gmane.comp.web.haproxy/10361 >> >> I assume that your application is not aware of an SSL termination, so you >> have to notify it with the right configuration, which depends on your >> backends softwares. Can you provide some information on them ? >> >> >>> >>> --Sean Patronis >>> Auto Data Direct Inc. >>> 850.877.8804 >>> >>> On 03/17/2015 11:51 AM, Scott McKeown|redIT wrote: Hi Sean, I've got a setup that is somewhat like what you are after. I have however, done it in a very dirrerent way for this very same reason. Example below: global log /dev/log local4 debug maxconn 4096 daemon tune.ssl.default-dh-param 2048 ssl-default-bind-ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH ssl-default-bind-options no-sslv3 ssl-default-server-ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH ssl-default-server-options no-sslv3 defaults log global option httplog retries 3 timeout client 5 timeout connect 5 timeout server 5 listen http-in bind x.x.x.x:80 mode http default_backend www_redit listen https-in bind x.x.x.x:443 ssl crt /etc/certs/server_2015.pem mode http acl samson_vpn_gateway src 10.8.0.1 acl missing_nagios_slash path_reg -i ^/nagios3[^/]*$ acl missing_cacti_slash path_reg -i ^/cacti[^/]*$ acl missing_dradis_slash path_reg -i ^/customers[^/]*$ redirect code 301 prefix / drop-query append-slash if missing_nagios_slash redirect code 301 prefix / drop-query append-slash if missing_cacti_slash redirect code 301 prefix / drop-query append-slash if missing_dradis_slash acl is_nagios path_reg -i /nagios3/ acl is_cacti path_reg -i /cacti/ acl is_dradis path_reg -i /customers/ #VPN Access Only use_backend services if is_nagios samson_vpn_gateway use_backend services if is_cacti samson_vpn_gateway use_backend dradis if is_dradis default_backend corp_site listen corp_site mode http log global option httpclose source 0.0.0.0 usesrc clientip option forwardfor server websites0
Affortable SEO
Addressing Good Morning, Hope you are doing well I am Babita, Website Expert for SEO. Our professional SEO team checked your website: www.formilux.org You should get Search Engine Optimization and Social Media Promotions. We are a team of 50+ professionals which includes 18 full time SEO experts. As per the trends in your industry - over 90% of people search for your products/services online and make a purchase decision. Google rankings also influence other channels of revenue generation as well. We will be glad to assist you by offering our services. We bring Traffic to Your Site and rank You Top with our LSI based campaign. We would love to hear from you and would be happy to share our methods of promotions, past work details, testimonials of our clients, service fee etc for your reference. I look forward to hear from you! We have expertise in the following areas:- . eCommerce website promotions, . Product promotions, . Social media campaign management, . Content writing. . Web designing Kind Regards, Babita Website Expert for SEO Karol Bagh New Delhi (India)
Re: Haproxy 1.5 ssl redirect
Baptiste, Thanks for the links, I had run across them earlier this morning in my google searching, but your post made me pay more attention to them... I have it working now, and the trick that seemed to do it for me was making all the paths absolute (since I am forcing https anyhow, and each since frontend/backend combo is unique) with this line in my backend config: # ProxyPassReverse /mirror/foo/ http://bk.dom.com/bar # Note: we turn the urls into absolute in the mean time acl hdr_location res.hdr(Location) -m found rspirep ^Location:\ (https?://localtest.test123.com(:[0-9]+)?)?(/.*) Location:\ \3 if hdr_location Thanks for all the help from everyone is this thread! --Sean Patronis Auto Data Direct Inc. 850.877.8804 On 03/18/2015 12:06 PM, Baptiste wrote: Hi Sean, You may find some useful information here: http://blog.haproxy.com/2014/04/28/howto-write-apache-proxypass-rules-in-haproxy/ and here: http://blog.haproxy.com/2013/02/26/ssl-offloading-impact-on-web-applications/ Baptiste On Wed, Mar 18, 2015 at 3:39 PM, Sean Patronis wrote: Thanks for the link. That looks promising, but testing did not change anything and I am waiting on the developers to give me some indication of what headers they may expect. Maybe we can tackle this a different way since we know it works in apache. I am attempting to replace the following VirtualHost in apache and put it into haproxy: ## [test.test123.com] ServerName test.test123.com SSLEngine on SSLProtocol all -SSLv3 SSLHonorCipherOrder On SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM:!SSLV2:!eNULL ProxyPassReverse / http://10.0.60.5/ ProxyPass / http://10.0.60.5/ what haproxy frontend settings do I need to make this match whatever apache and mod_proxy is doing? 10.0.60.5:80 is already in haproxy I think the problem may be that there are some headers getting set by ProxyPass and ProxyPassReverse that I am not setting in haproxy. More specifically, I think that the apache ProxyPassReverse is rewiting the problem URI to https, and haproxy is not. --Sean Patronis Auto Data Direct Inc. 850.877.8804 On 03/17/2015 06:24 PM, Cyril Bonté wrote: Hi, Le 17/03/2015 20:42, Sean Patronis a écrit : Unfortunately that did not fix it. I mirrored your config and the problem still exists. I am not quite sure how the URL is getting built on the backend (the developers say it is all relative URL/URI), but whatever haproxy is doing, it is doing it differently than apache (with mod_proxy). Just for fun, I swapped back the ssl termination to apache to prove that is does not have an issue (once it passes through apache for ssl, it still goes through Haproxy and all of the backends/acl etc). My goal in all of this was to ditch apache and go all haproxy on the front end. Any other ideas? Have a look at this answer : http://permalink.gmane.org/gmane.comp.web.haproxy/10361 I assume that your application is not aware of an SSL termination, so you have to notify it with the right configuration, which depends on your backends softwares. Can you provide some information on them ? --Sean Patronis Auto Data Direct Inc. 850.877.8804 On 03/17/2015 11:51 AM, Scott McKeown|redIT wrote: Hi Sean, I've got a setup that is somewhat like what you are after. I have however, done it in a very dirrerent way for this very same reason. Example below: global log /dev/log local4 debug maxconn 4096 daemon tune.ssl.default-dh-param 2048 ssl-default-bind-ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH ssl-default-bind-options no-sslv3 ssl-default-server-ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH ssl-default-server-options no-sslv3 defaults log global option httplog retries 3 timeout client 5 timeout connect 5 timeout server 5 listen http-in bind x.x.x.x:80 mode http default_backend www_redit listen https-in bind x.x.x.x:443 ssl crt /etc/certs/server_2015.pem mode http acl samson_vpn_gateway src 10.8.0.1 acl missing_nagios_slash path_reg -i ^/nagios3[^/]*$ acl missing_cacti_slash path_reg -i ^/cacti[^/]*$ acl missing_dradis_slash path_reg -i ^/customers[^/]*$ redirect code 301 prefix / drop-query append-slash if missing_nagios_slash redirect code 301 prefix / drop-query append-slash if missing_cacti_slash redirect code 301 prefix / drop-query append-slash if missing_dradis_slash acl is_nagios path_reg -i /nagios3/ acl is_cacti path_reg -i /cacti/ acl is_dradis path_reg -i /customers/ #VPN Access Only use_backend services if is_nagios samson
-sf seems to be not causing a reload of the config
so i'm launching haproxy like below: #!/bin/sh pidfile=/data/haproxy.pidhaproxy -db -f /haproxy-1.5.8/haproxy.cfg -p $pidfile -sf $(cat $pidfile) Then i use the stats page to monitor the server list. I drop in a new cfg file with an added or removed server, however, the stats page does not show any changes. The old servers (now removed from the cfg) continue to get hit as well. Is this because of -db or is there something else that I'm missing? When i do a cat /data/haproxy.pid and compare that with what a ps command shows i see that -sf has the right value thanks jeff
135-145Lm/w Ra>80 PF>0.95 18w t8 led tube light 1200mm Manufacturer give you best price
Dear Manager, Have a nice day! 135-145lm/w; PF>0.95, RA>80, Pass VDE UL TUV SAA PSE certificate, which is the core advantages in our 2014-2015 newest led tude -TSMD led tube. Plus reasonable price, up to 5 years gurantee to our consumers and good communication etc... If we are the just right cooperation partner you were searching in China, kindly pls contact us! This is Susan From a 5-years experience T-UVDEULED tube professional manufacturer. Best Regards! Yours Susan (sales1# Manager) T-UVDEULED TUBE Co.,LTD www.tuvdeuled.com
Re: Haproxy 1.5 ssl redirect
Hi Sean! You're welcome :) I still have in my TODO list to contact you about your AVI network experience ;) Talk to you soon. Baptiste On Wed, Mar 18, 2015 at 7:06 PM, Sean Patronis wrote: > Baptiste, > > Thanks for the links, I had run across them earlier this morning in my > google searching, but your post made me pay more attention to them... I have > it working now, and the trick that seemed to do it for me was making all the > paths absolute (since I am forcing https anyhow, and each since > frontend/backend combo is unique) with this line in my backend config: > > # ProxyPassReverse /mirror/foo/ http://bk.dom.com/bar > # Note: we turn the urls into absolute in the mean time > acl hdr_location res.hdr(Location) -m found > rspirep ^Location:\ (https?://localtest.test123.com(:[0-9]+)?)?(/.*) > Location:\ \3 if hdr_location > > > Thanks for all the help from everyone is this thread! > > --Sean Patronis > Auto Data Direct Inc. > 850.877.8804 > > On 03/18/2015 12:06 PM, Baptiste wrote: >> >> Hi Sean, >> >> You may find some useful information here: >> >> http://blog.haproxy.com/2014/04/28/howto-write-apache-proxypass-rules-in-haproxy/ >> and here: >> >> http://blog.haproxy.com/2013/02/26/ssl-offloading-impact-on-web-applications/ >> >> Baptiste >> >> >> On Wed, Mar 18, 2015 at 3:39 PM, Sean Patronis >> wrote: >>> >>> Thanks for the link. That looks promising, but testing did not change >>> anything and I am waiting on the developers to give me some indication of >>> what headers they may expect. Maybe we can tackle this a different way >>> since we know it works in apache. I am attempting to replace the >>> following >>> VirtualHost in apache and put it into haproxy: >>> >>> ## [test.test123.com] >>> >>> ServerName test.test123.com >>> SSLEngine on >>> SSLProtocol all -SSLv3 >>> SSLHonorCipherOrder On >>> SSLCipherSuite >>> >>> ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM:!SSLV2:!eNULL >>> ProxyPassReverse / http://10.0.60.5/ >>> ProxyPass / http://10.0.60.5/ >>> >>> >>> what haproxy frontend settings do I need to make this match whatever >>> apache >>> and mod_proxy is doing? >>> >>> 10.0.60.5:80 is already in haproxy I think the problem may be that >>> there are some headers getting set by ProxyPass and ProxyPassReverse that >>> I >>> am not setting in haproxy. More specifically, I think that the apache >>> ProxyPassReverse is rewiting the problem URI to https, and haproxy is >>> not. >>> >>> --Sean Patronis >>> Auto Data Direct Inc. >>> 850.877.8804 >>> >>> On 03/17/2015 06:24 PM, Cyril Bonté wrote: Hi, Le 17/03/2015 20:42, Sean Patronis a écrit : > > Unfortunately that did not fix it. I mirrored your config and the > problem still exists. I am not quite sure how the URL is getting built > on the backend (the developers say it is all relative URL/URI), but > whatever haproxy is doing, it is doing it differently than apache (with > mod_proxy). Just for fun, I swapped back the ssl termination to apache > to prove that is does not have an issue (once it passes through apache > for ssl, it still goes through Haproxy and all of the backends/acl > etc). > > My goal in all of this was to ditch apache and go all haproxy on the > front end. > > Any other ideas? Have a look at this answer : http://permalink.gmane.org/gmane.comp.web.haproxy/10361 I assume that your application is not aware of an SSL termination, so you have to notify it with the right configuration, which depends on your backends softwares. Can you provide some information on them ? > --Sean Patronis > Auto Data Direct Inc. > 850.877.8804 > > On 03/17/2015 11:51 AM, Scott McKeown|redIT wrote: >> >> Hi Sean, >> >> I've got a setup that is somewhat like what you are after. I have >> however, done it in a very dirrerent way for this very same reason. >> >> Example below: >> >> global >> log /dev/log local4 debug >> maxconn 4096 >> daemon >> tune.ssl.default-dh-param 2048 >> >> ssl-default-bind-ciphers >> >> >> ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH >> >> ssl-default-bind-options no-sslv3 >> ssl-default-server-ciphers >> >> >> ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:HIGH:!RC4:!MD5:!aNULL:!EDH >> >> ssl-default-server-options no-sslv3 >> >> defaults >> log global >> option httplog >> retries 3 >> timeout client 5 >> timeout connect 5 >> timeout server 5 >> >> listen http-in >> bind x.x.x.x:80 >> mode
Sportsanka supplies Sports Attire Cycling Outfits - HK ANKA
Hello there! Very nice to have this opportunity to introduce myself and our company to you. And sorry if my mail may disturb you. This is Dalia, writing from Sportsanka - Hong Kong Anka Industiral Development Co., Limited. We have many years of experience in manufacturing sports attires. Our products such as running T-shirts for promotion, cycling jerseys for racing, outdoor waterproof jackets for hiking and skiing, have gained much attention and interest from our other customers. We would like to produce our quality sportswear for your company, if you have any query on us please feel free to let me know. Or if you don't want to receive our mails again, please feel free to inform me too. I appreciate your precious time. In the last, wish you a nice day ahead! Dalia Pao Sales Executive HONG KONG ANKA INDUSTRIAL DEVELOPMENT CO., LIMITED Website: www.sportsanka.com Email: i...@sportsanka.com
Haproxy Consuing CPU 100% : need a fix
Hello, we are facing issue of haproxy consuming 100% CPU , we tried different tunings on haproxy cfg . But only solution remains is of making the nbproc > 1, which is not a permanent solution. _Pasting the common config section:_ global maxconn 28 nbproc 1 userhaproxy group haproxy chroot /var/lib/haproxy stats socket/var/run/haproxy.sock defaults modehttp balance roundrobin maxconn 275000 timeout connect 5000 timeout server 5 timeout client 5 timeout http-keep-alive 5s timeout http-request15s retries 3 option redispatch option abortonclose option tcp-smart-accept option tcp-smart-connect #option splice-auto listen stats self.prv:x0x0x stats enable stats uri / Kindly suggest, any solution possible. We need fix badly , do not wish to migrate to nginx just for this reason. p.s. Fell free to connect in case of any Query. Thanks & Regards, Saurabh Tiwari Server Admin.
