Re: export aluminum sheet and coil in China
Dear director, hope you and your family are fine! I am Mr. Jack, general manager of WANXINYUAN ALUMINUM INDUSTRY CO.,LIMITED from Shenzhen city, China. our products mainly aluminum sheet&coils/aluminum mirror sheet&coil/Aluminum sheet&coil for curtain wall/Aluminum sheet&coil for bottle cap/Aluminum embossed/pattern/Checkered sheet&coil,etc. for aluminum mirror finish coil&sheet, we mainly supply 1060/1100-H18 thickness range: 0.18/0.19/0.2/0/3/0.4/0.5/0.6/0.7/0.8/0.9/1.0mm color including: silver/gold/copper/blue/pink/black,etc. while for other material, including alloy: 1050/1060/1070/1100/3003/3004/3103/3104/5005/5052/5083/5182/5754/6005/6061/6063/7021/8011,etc. thickness: 0.2mm-6mm&8mm-30mm Width: 1000/1220/1250/1300/1350/1500/2000mm(maximum),and other special width. Length: 2000/2400/2440/2500/3000/4000/5000/6000mm, or, coils, etc. Thickness tolerance: +0mm, -0.03mm any inquiry regarding to aluminum sheet&coil, please feel free to contact me anytinem, i am pleased to help. wish we will have chance to cooperate. regards! Mr.Jack(Geneal Manager)SHENZHEN WANXINYUAN ALUMINUM INDUSTRY CO.,LTDhttp://wanxinyuanaluminum.en.made-in-china.com/ E-mail：jack...@gdwanxin.comMobile: 0086-18502085515Fax:0086-0755-23033800Skype: jackwxy88
Re: Lua patchset merged
Hi Steven, On Thu, Mar 05, 2015 at 11:16:14PM +0100, Steven Le Roux wrote: > Hi, > > why not just a github so that people can fork, play and submit their > own Lua scripts? Well, anyone can just do that by himself. I meant something more discussion-oriented than development-oriented. Probably the type of place were you'd find the links to the most common github projects for example. It was suggested that Reddit could be suited for this, we'll check. Willy
Re: Peers with long hostnames
Hi Lukas, On Thu, Mar 05, 2015 at 11:17:31PM +0100, Lukas Tribus wrote: > > So maybe it's time that we backport this patch into 1.5. We haven't > > received any negative feedback for 1.6 yet after almost 2 months. What > > do people think? > > It think it would be a good thing to release 1.6-dev1, unless there are some > critical issues that still need work. > > Even if a lot of people interested in development version are using git, > a -dev release still sends a message and I think it would encourage more > users to give it a try (thus, providing feedback). That's a very good point. I'll check with Thierry tomorrow, I know he has some pending doc, and I'll issue dev1. Thanks, Willy
Re: Lua patchset merged
Hi, why not just a github so that people can fork, play and submit their own Lua scripts? On Thu, Mar 5, 2015 at 8:00 AM, Willy Tarreau wrote: > On Mon, Mar 02, 2015 at 11:33:39PM +0100, Baptiste wrote: >> I love it ! >> >> Just wrote, as a proof of concept, a forward proxy... >> That said, it seems my lua script is "blocking"... I mean, if the >> remote server is slow to deliver the response, then HAProxy doesn't >> process any other request or response. > > As explained by Thierry, this is because you used the native sockets > instead of haproxy's non-blocking ones. I think that after some time > we'll start to collect some best practices regarding Lua and such > issues will not happen anymore since (as usual), people will write > configs by copy-pasting working ones. > > We're still thinking about setting up a forum dediated to Lua so that > people can share their code easily. It's a bit early for now since > we're mostly fixing the code and/or design, but once things settle > down it should be helpful. > > Willy > > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
RE: Peers with long hostnames
> So maybe it's time that we backport this patch into 1.5. We haven't > received any negative feedback for 1.6 yet after almost 2 months. What > do people think? It think it would be a good thing to release 1.6-dev1, unless there are some critical issues that still need work. Even if a lot of people interested in development version are using git, a -dev release still sends a message and I think it would encourage more users to give it a try (thus, providing feedback). -Lukas
Re: agent-check sets status "DRAIN" for no apparent reason.
On Thu, Mar 05, 2015 at 02:07:06PM +0100, Lukas Tribus wrote: > > Using HA-Proxy version 1.5.6 2014/10/18 on CentOS 6, recently updated, etc. > > Upgrade anyway, you may be hitting a bug thats already fixed: > ~/haproxy-1.5$ git log --oneline v1.5.6.. | grep agent > bfb8f88 BUG/MEDIUM: Do not consider an agent check as failed on L7 error > 8eccbf7 MEDIUM/BUG: Only explicitly report "DOWN (agent)" if the agent health > is zero > 5ed62d6 BUG/MEDIUM: Do not set agent health to zero if server is disabled in > config > 1f96a87 BUG/MEDIUM: checks: fix conflicts between agent checks and ssl > healthchecks > ~/haproxy-1.5$ Damn, I started a response yesterday after checking this and it looks like I lost it before sending it. Never mind. After some review of the bugs above I suspected that none of them could cause this. But it might still be a side effect of one of them that was not detected nor documented. So yes, upgrading would help, especially given that the problem seems quite reproduceable. Thanks, Willy
Re: [PATCH] Certificate Transparency support
Hi Janusz, On Thu, Mar 05, 2015 at 09:20:54PM +0100, rrapt...@nails.eu.org wrote: > From: Janusz Dziemidowicz > > Adds ability to include Signed Certificate Timestamp List in TLS > extension. File containing SCTL must be present at the same path of > the certificate file, suffixed with '.sctl'. This requires OpenSSL > 1.0.2 or later. > --- (...) > This patch also applies cleanly on haproxy 1.5 branch. > > I'm not sure if this is the right way to implement this, so I'm > looking for any comments. Well, I don't know if it's the right way to implement it, I'll let the SSL experts review your work. However what I can say is that it's the right way to write and submit a patch for quick inclusion. Your code is very clean is the doc is provided as well. Good job for a first patch! Concerning 1.5, we avoid backporting features into 1.5 to avoid reproducing the mess that 1.4 was with regressions. That said, we seldom make a few exceptions when the feature addresses an ongoing problem to expect soon. Here I don't think it's the case, but if everyone thinks it would be nice to have it there, users decide :-) Thanks, Willy
[PATCH] Certificate Transparency support
From: Janusz Dziemidowicz Adds ability to include Signed Certificate Timestamp List in TLS extension. File containing SCTL must be present at the same path of the certificate file, suffixed with '.sctl'. This requires OpenSSL 1.0.2 or later. --- Notes: Certificate Transparency is a Google project to create system of public logs of all issued TLS certificates. After submitting a certificate to some log, the log issues so called Signed Certificate Timestamp. This timestamp must be then distributed to browsers in one of three ways: - as a certificate extension - as an OCSP response extension - as a TLS extension This patch add support for including SCTs in TLS extension to haproxy. Unfortunately, there is currently no standard format for SCT, so it simply loads binary format of TLS extension data from a file with '.sctl' suffix. It should contain a Signed Certificate Timestamp List (simply multiple SCTs from possibly many logs) structure as described in CT RFC. Since SCTs will be retrieved very rarely from logs (usually shortly after certificate issuance) and they are valid indefinitely, there is no support for refreshing '.sctl' file (one can always reload haproxy to load new '.sctl' file). Current CT tools are rather not well documented and not very user friendly, so I've created a simple Python script that allows one to submit any existing certificate to currently known public logs. It can also output '.sctl' file for use in haproxy. The script can be found at: https://gist.github.com/rraptorr/2efaaf21caaf6574e8ff I've set up a test site at https://tlsinfo.nails.eu.org:8443 (note the port, as the main site does not run on haproxy). Chrome users can see all of this in action after clicking on the padlock icon and selecting connection tab. This patch also applies cleanly on haproxy 1.5 branch. I'm not sure if this is the right way to implement this, so I'm looking for any comments. doc/configuration.txt | 20 +++--- src/ssl_sock.c| 169 +- 2 files changed, 181 insertions(+), 8 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 0aac7e9..4df281b 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -8686,13 +8686,13 @@ crt If a directory name is used instead of a PEM file, then all files found in that directory will be loaded in alphabetic order unless their name ends with - '.issuer' or '.ocsp' (reserved extensions). This directive may be specified - multiple times in order to load certificates from multiple files or - directories. The certificates will be presented to clients who provide a valid - TLS Server Name Indication field matching one of their CN or alt subjects. - Wildcards are supported, where a wildcard character '*' is used instead of the - first hostname component (eg: *.example.org matches www.example.org but not - www.sub.example.org). + '.issuer', '.ocsp' or '.sctl' (reserved extensions). This directive may be + specified multiple times in order to load certificates from multiple files or + directories. The certificates will be presented to clients who provide a + valid TLS Server Name Indication field matching one of their CN or alt + subjects. Wildcards are supported, where a wildcard character '*' is used + instead of the first hostname component (eg: *.example.org matches + www.example.org but not www.sub.example.org). If no SNI is provided by the client or if the SSL library does not support TLS extensions, or if the client provides an SNI hostname which does not @@ -8724,6 +8724,12 @@ crt be loaded from a file at the same path as the PEM file suffixed by ".issuer" if it exists otherwise it will fail with an error. + For each PEM file, haproxy also checks for the presence of file at the same + path suffixed by ".sctl". If such file is found, support for Certificate + Transparency (RFC6962) TLS extension is enabled. The file must contain a + valid Signed Certificate Timestamp List, as described in RFC. File is parsed + to check basic syntax, but no signatures are verified. + crt-ignore-err This setting is only available when support for OpenSSL was built in. Sets a comma separated list of errorIDs to ignore during verify at depth == 0. If diff --git a/src/ssl_sock.c b/src/ssl_sock.c index 69f754c..e987c57 100644 --- a/src/ssl_sock.c +++ b/src/ssl_sock.c @@ -596,6 +596,146 @@ out: #endif +#if (OPENSSL_VERSION_NUMBER >= 0x1000200fL && !defined OPENSSL_NO_TLSEXT && !defined OPENSSL_IS_BORINGSSL) + +#define CT_EXTENSION_TYPE 18 + +static int sctl_ex_index = -1; + +/* + * Try to parse Signed Certificate Timestamp List structure. This function + * makes only basic test if the data seems like SCTL. No signature validation + * is performed. + */ +static int ssl_sock_parse_sctl(struct chunk *
Re: WebDAV via HAproxy simply won't work with Microsoft Windows
Hi, On Thu, Mar 05, Eamonn Hynes wrote: > Hello Jarno, > > Thank you very much for your message. > > Yes, I was wondering about that 301 code. I wonder do you have any more > suggestions here? Can you try to set the port 8080 virtualhost to use ServerName https://myserver.com (or https://myserver.com:443) and see if the windows client redirects use https. (or modify the Location header(s/http/https/) on haproxy: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-rspirep) Also maybe you could use tcpdump to capture the client traffic between haproxy <-> apache and see if osx/linux vs. windows send different headers etc. that might explain why windows behaves differently. (BTW: Does the windows client work with plain http thru haproxy ? (no http -> https redirect on haproxy and net use ... w/out @SSL)). -Jarno > Apache2 isn't listening on https at all. All the SSL is done by haproxy. > > It's Apache2, not TomCat. > > Thanks again, > > Eamonn > > > On 5 March 2015 at 14:33, Jarno Huuskonen wrote: > > > Hi, > > > > On Thu, Mar 05, Eamonn Hynes wrote: > > > `net use X: \\myserver.com@SSL\home\eamorr` #A Windows command > > > > > > here's the server-side HAProxy log (/var/log/haproxy.log): > > > > > > Mar 5 11:51:00 apacheserver1 haproxy[22786]: 137.43.130.107:51168 > > > [05/Mar/2015:11:50:25.233] www-https~ http-backend/apacheserver1 > > > 35691/0/1/11/35703 301 511 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr > > > HTTP/1.1" > > > Mar 5 11:51:01 apacheserver1 haproxy[22786]: 137.43.130.107:51168 > > > [05/Mar/2015:11:51:00.936] www-https~ http-backend/apacheserver1 > > > 97/0/0/2/99 301 497 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home HTTP/1.1" > > > > > > And here's the output from Apache2 (with trace8 debugging info enabled): > > > > [some lines removed] > > > > > fixups hook gave 301: /home > > > Response sent with status 301, headers: > > > Location: http://myserver.com/home/ > > > > Hmm, this looks like something redirects the request back to http > > (response 301 and Location: http://) ? > > > > Maybe the apache virtualhost needs some config to think it's ssl > > enabled, so it'll redirect to https ? > > > > (Is the backend server apache or is it tomcat(cookie JSESSIONID) (or > > both)) ? > > (With tomcat maybe try setting secure=true and/or scheme=https to port > > 8080 connector). > > > > -Jarno > > > > > When I connect from Linux (which works fine!), I get the following > > > `/var/log/haproxy.log`: > > > > > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > > [05/Mar/2015:12:20:10.062] www-https~ http-backend/apacheserver1 > > > 114/0/0/14/128 200 303 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr > > > HTTP/1.1" > > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > > [05/Mar/2015:12:20:10.190] www-https~ http-backend/apacheserver1 > > 3/0/0/3/6 > > > 207 474 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr HTTP/1.1" > > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > > [05/Mar/2015:12:20:10.196] www-https~ http-backend/apacheserver1 > > 1/0/0/2/3 > > > 200 172 - - --VN 1/1/0/1/0 0/0 "OPTIONS /home/ HTTP/1.1" > > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > > [05/Mar/2015:12:20:10.200] www-https~ http-backend/apacheserver1 > > > 31/0/0/3/34 207 901 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr > > HTTP/1.1" > > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > > [05/Mar/2015:12:20:10.234] www-https~ http-backend/apacheserver1 > > > 52/0/0/10/62 207 2188 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr > > > HTTP/1.1" > > > > -- > > Jarno Huuskonen > > > > > > -- > Eamonn Hynes -- Jarno Huuskonen
Re: WebDAV via HAproxy simply won't work with Microsoft Windows
Hello Jarno, Thank you very much for your message. Yes, I was wondering about that 301 code. I wonder do you have any more suggestions here? Apache2 isn't listening on https at all. All the SSL is done by haproxy. It's Apache2, not TomCat. Thanks again, Eamonn On 5 March 2015 at 14:33, Jarno Huuskonen wrote: > Hi, > > On Thu, Mar 05, Eamonn Hynes wrote: > > `net use X: \\myserver.com@SSL\home\eamorr` #A Windows command > > > > here's the server-side HAProxy log (/var/log/haproxy.log): > > > > Mar 5 11:51:00 apacheserver1 haproxy[22786]: 137.43.130.107:51168 > > [05/Mar/2015:11:50:25.233] www-https~ http-backend/apacheserver1 > > 35691/0/1/11/35703 301 511 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr > > HTTP/1.1" > > Mar 5 11:51:01 apacheserver1 haproxy[22786]: 137.43.130.107:51168 > > [05/Mar/2015:11:51:00.936] www-https~ http-backend/apacheserver1 > > 97/0/0/2/99 301 497 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home HTTP/1.1" > > > > And here's the output from Apache2 (with trace8 debugging info enabled): > > [some lines removed] > > > fixups hook gave 301: /home > > Response sent with status 301, headers: > > Location: http://myserver.com/home/ > > Hmm, this looks like something redirects the request back to http > (response 301 and Location: http://) ? > > Maybe the apache virtualhost needs some config to think it's ssl > enabled, so it'll redirect to https ? > > (Is the backend server apache or is it tomcat(cookie JSESSIONID) (or > both)) ? > (With tomcat maybe try setting secure=true and/or scheme=https to port > 8080 connector). > > -Jarno > > > When I connect from Linux (which works fine!), I get the following > > `/var/log/haproxy.log`: > > > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > [05/Mar/2015:12:20:10.062] www-https~ http-backend/apacheserver1 > > 114/0/0/14/128 200 303 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr > > HTTP/1.1" > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > [05/Mar/2015:12:20:10.190] www-https~ http-backend/apacheserver1 > 3/0/0/3/6 > > 207 474 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr HTTP/1.1" > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > [05/Mar/2015:12:20:10.196] www-https~ http-backend/apacheserver1 > 1/0/0/2/3 > > 200 172 - - --VN 1/1/0/1/0 0/0 "OPTIONS /home/ HTTP/1.1" > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > [05/Mar/2015:12:20:10.200] www-https~ http-backend/apacheserver1 > > 31/0/0/3/34 207 901 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr > HTTP/1.1" > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > > [05/Mar/2015:12:20:10.234] www-https~ http-backend/apacheserver1 > > 52/0/0/10/62 207 2188 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr > > HTTP/1.1" > > -- > Jarno Huuskonen > -- Eamonn Hynes
Re: WebDAV via HAproxy simply won't work with Microsoft Windows
Hi, On Thu, Mar 05, Eamonn Hynes wrote: > `net use X: \\myserver.com@SSL\home\eamorr` #A Windows command > > here's the server-side HAProxy log (/var/log/haproxy.log): > > Mar 5 11:51:00 apacheserver1 haproxy[22786]: 137.43.130.107:51168 > [05/Mar/2015:11:50:25.233] www-https~ http-backend/apacheserver1 > 35691/0/1/11/35703 301 511 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr > HTTP/1.1" > Mar 5 11:51:01 apacheserver1 haproxy[22786]: 137.43.130.107:51168 > [05/Mar/2015:11:51:00.936] www-https~ http-backend/apacheserver1 > 97/0/0/2/99 301 497 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home HTTP/1.1" > > And here's the output from Apache2 (with trace8 debugging info enabled): [some lines removed] > fixups hook gave 301: /home > Response sent with status 301, headers: > Location: http://myserver.com/home/ Hmm, this looks like something redirects the request back to http (response 301 and Location: http://) ? Maybe the apache virtualhost needs some config to think it's ssl enabled, so it'll redirect to https ? (Is the backend server apache or is it tomcat(cookie JSESSIONID) (or both)) ? (With tomcat maybe try setting secure=true and/or scheme=https to port 8080 connector). -Jarno > When I connect from Linux (which works fine!), I get the following > `/var/log/haproxy.log`: > > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > [05/Mar/2015:12:20:10.062] www-https~ http-backend/apacheserver1 > 114/0/0/14/128 200 303 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr > HTTP/1.1" > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > [05/Mar/2015:12:20:10.190] www-https~ http-backend/apacheserver1 3/0/0/3/6 > 207 474 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr HTTP/1.1" > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > [05/Mar/2015:12:20:10.196] www-https~ http-backend/apacheserver1 1/0/0/2/3 > 200 172 - - --VN 1/1/0/1/0 0/0 "OPTIONS /home/ HTTP/1.1" > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > [05/Mar/2015:12:20:10.200] www-https~ http-backend/apacheserver1 > 31/0/0/3/34 207 901 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr HTTP/1.1" > Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295 > [05/Mar/2015:12:20:10.234] www-https~ http-backend/apacheserver1 > 52/0/0/10/62 207 2188 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr > HTTP/1.1" -- Jarno Huuskonen
Re: HAProxy 1.5 SSL Behavior Issue For Zone Apex & “www”
Hi,
On Sun, Mar 01, BGaudreault Brian wrote:
> Hello, I'm seeing weird behaviors forwarding on traffic coming in over HTTPS
> and was hoping someone could provide a solution. I believe I have SSL setup
> properly for HAProxy 1.5, but this is the first time I'm using it with SNI
> for multiple domain support. I'm also not sure where my logs are on this
> server.
Do you have a chroot statement in haproxy.cfg (is /dev/log available inside
chroot) ?
Check your syslog configuration it should show where the logs go
(usually /var/log).
(And your logs will show what frontend/backend the traffic uses).
> • https domain.com - The browser spreads out the page layout vertically and
> starts with a vertical list of URLs in text form instead of a horizontal list
> in graphical form with pop-up menus. I suspect this may be an issue with the
> web server configuration and/or the code.
>
> • https www.domain.com - I'm getting redirected to our secure "order" page
> instead of our "main" website page and I'm not sure why.
For testing try adding (to frontend https_in):
acl domain.com hdr_dom(host) -i domain.com
use_backend domain.com if domain.com
this should help debug that traffic goes to correct backend.
Also you can use openssl s_client to send requests with sni:
openssl s_client -connect ip.add.re.ss:443 -servername www.domain.com
openssl s_client -connect ip.add.re.ss:443 -servername domain.com
(And type something like this to send a request:
GET /someurl HTTP/1.1
Host: www.domain.com
).
But get logging working and add ssl_fc_sni to logformat, something
like this:
http://bedis.eu/haproxy/haproxy_configuration_for_dokuwiki
-Jarno
> acl domain.com hdr_dom(host) -i domain.com
> use_backend domain.com if domain.com
> default_backend web
>
> frontend https_in
>
> bind :443 ssl crt /etc/ssl/WILDCARD.domain.com.chain.pem
> use_backend domain.com if { ssl_fc_sni domain.com }
> use_backend domain.com if { ssl_fc_sni www.domain.com }
> default_backend web
--
Jarno Huuskonen
Re: WebDAV via HAproxy simply won't work with Microsoft Windows
Hi Lukas, I added that option to the default section. Unfortunately, it hasn't done anything for my problem... On 5 March 2015 at 13:36, Lukas Tribus wrote: > > Hi Lukas, > > > > Thank you for taking the time to reply. > > > > Here are the global and defaults sections: > > Add: > option prefer-last-server > > to your default section. > > > Lukas > > -- Eamonn Hynes
RE: WebDAV via HAproxy simply won't work with Microsoft Windows
> Hi Lukas, > > Thank you for taking the time to reply. > > Here are the global and defaults sections: Add: option prefer-last-server to your default section. Lukas
Re: WebDAV via HAproxy simply won't work with Microsoft Windows
Hi Lukas, Thank you for taking the time to reply. Here are the global and defaults sections: global log /dev/loglocal0 log /dev/loglocal1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy daemon # Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/private # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). #ssl-default-bind-ciphers kEECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL #ssl-default-bind-options no-sslv3 tune.ssl.default-dh-param 2048 maxconn 2048 defaults log global modehttp option httplog option dontlognull timeout connect 5000 timeout client 5 timeout server 5 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http #option forwardfor #option http-server-close #option httpclose #option redispatch stats enable stats uri /haproxy?stats stats realm Strictly\ Private stats auth admin: On 5 March 2015 at 13:08, Lukas Tribus wrote: > > Here's my haproxy config: > > This config is incomplete. We need at least all options and timeouts, > including global and default sections. > > > Lukas > > -- Eamonn Hynes Computational Support Specialist E4.05 Science Centre East Earth Institute & Complex and Adaptive Systems Laboratory University College Dublin Belfield Dublin 4 Ireland +353 1 716 2696 eamonn.hy...@ucd.ie
RE: WebDAV via HAproxy simply won't work with Microsoft Windows
> Here's my haproxy config: This config is incomplete. We need at least all options and timeouts, including global and default sections. Lukas
RE: agent-check sets status "DRAIN" for no apparent reason.
> Using HA-Proxy version 1.5.6 2014/10/18 on CentOS 6, recently updated, etc. Upgrade anyway, you may be hitting a bug thats already fixed: ~/haproxy-1.5$ git log --oneline v1.5.6.. | grep agent bfb8f88 BUG/MEDIUM: Do not consider an agent check as failed on L7 error 8eccbf7 MEDIUM/BUG: Only explicitly report "DOWN (agent)" if the agent health is zero 5ed62d6 BUG/MEDIUM: Do not set agent health to zero if server is disabled in config 1f96a87 BUG/MEDIUM: checks: fix conflicts between agent checks and ssl healthchecks ~/haproxy-1.5$ Regards, Lukas
WebDAV via HAproxy simply won't work with Microsoft Windows
Hello,
I thought I would ask here for some help with WebDav through HAproxy.
So I have successfully set up HAproxy to listen for http/https on a virtual
IP.
I have two Apache2 (apacheserver1 and apacheserver2) servers serving web
traffic.
Everything is working fine - I am serving web pages, my clients are forced
to use https, my SSL cert is signed correctly and my users can connect to
their WebDAV areas using Finder (Mac) and Nautilus (Linux).
Great.
Now, here comes the serious trouble - **Windows clients can't connect via
WebDAV.**
Here is the command:
`net use X: \\myserver.com@SSL\home\eamorr`
And the error:
System error 67 has occurred.
(I can connect perfectly fine to https://myserver.com/home/eamorr on
Mac/Linux)
When I do:
`net use X: \\apacheserver1.com@8080\home\eamorr`
It works fine (I'm connecting directly to apacheserver1:8080 - no SSL).
When I do:
`net use X: \\apacheserver1.com@SSL@8081\home\eamorr`
It works fine (I'm connecting directly to apacheserver1:8081 - SSL enabled).
But when I go through the haproxy, it just will not work...
Here's my haproxy config:
frontend www-http
bind 137.43.99.100:80 #A virtual IP
#reqadd X-Forwarded-Proto:\ http
default_backend http-backend
frontend www-https
bind 137.43.93.215:443 ssl crt /etc/apache2/ssl/combined.pem
#reqadd X-Forwarded-Proto:\ http
#reqirep Destination:\ https(.*) Destination:\ http\\1
#rspidel ^translate
default_backend http-backend
backend http-backend
cookie JSESSIONID insert
#reqirep Destination:\ https(.*) Destination:\ http\\1
server apacheserver1 137.43.99.101:8080 cookie apacheserver1 check
server apacheserver2 137.43.99.102:8080 cookie apacheserver2 check
#redirect scheme https if !{ ssl_fc } #forces https!
#option forwardfor
#http-request set-header X-Forwarded-Port %[dst_port]
#http-request add-header X-Forwarded-Proto https if { ssl_fc }
When I try to connect via
`net use X: \\myserver.com@SSL\home\eamorr` #A Windows command
here's the server-side HAProxy log (/var/log/haproxy.log):
Mar 5 11:51:00 apacheserver1 haproxy[22786]: 137.43.130.107:51168
[05/Mar/2015:11:50:25.233] www-https~ http-backend/apacheserver1
35691/0/1/11/35703 301 511 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr
HTTP/1.1"
Mar 5 11:51:01 apacheserver1 haproxy[22786]: 137.43.130.107:51168
[05/Mar/2015:11:51:00.936] www-https~ http-backend/apacheserver1
97/0/0/2/99 301 497 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home HTTP/1.1"
And here's the output from Apache2 (with trace8 debugging info enabled):
Request received from client: OPTIONS /home HTTP/1.1
Headers received from client:
User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601
translate: f
Host: myserver.com
AH01626: authorization result of Require all granted: granted
AH01626: authorization result of : granted
request authorized without authentication by access_checker_ex hook:
/home
fixups hook gave 301: /home
Response sent with status 301, headers:
Date: Thu, 05 Mar 2015 12:09:50 GMT
Server: Apache/2.4.7 (Ubuntu)
Location: http://myserver.com/home/
Content-Length: 312
Content-Type: text/html; charset=iso-8859-1
core_output_filter: flushing because of FLUSH bucket
core_output_filter: flushing because of FLUSH bucket
When I connect from Linux (which works fine!), I get the following
`/var/log/haproxy.log`:
Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295
[05/Mar/2015:12:20:10.062] www-https~ http-backend/apacheserver1
114/0/0/14/128 200 303 - - --NI 1/1/0/1/0 0/0 "OPTIONS /home/eamorr
HTTP/1.1"
Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295
[05/Mar/2015:12:20:10.190] www-https~ http-backend/apacheserver1 3/0/0/3/6
207 474 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr HTTP/1.1"
Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295
[05/Mar/2015:12:20:10.196] www-https~ http-backend/apacheserver1 1/0/0/2/3
200 172 - - --VN 1/1/0/1/0 0/0 "OPTIONS /home/ HTTP/1.1"
Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295
[05/Mar/2015:12:20:10.200] www-https~ http-backend/apacheserver1
31/0/0/3/34 207 901 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr HTTP/1.1"
Mar 5 12:20:10 apacheserver1 haproxy[22786]: 137.43.130.107:51295
[05/Mar/2015:12:20:10.234] www-https~ http-backend/apacheserver1
52/0/0/10/62 207 2188 - - --VN 1/1/0/1/0 0/0 "PROPFIND /home/eamorr
HTTP/1.1"
and here is the Apache2 output:
Request received from client: OPTIONS /home/eamorr HTTP/1.1
Setting redirect-carefully
Headers received from client:
Host: myserver.com
Accept-Encoding: gzip, deflate
User-Agent: gvfs/1.20.1
Accept-Language: en-ie, en;q=0.9, en;q=0.8
AH01626: authorization result of Require all granted: granted
AH01626: authorization result of : granted
request authorized without authentication by access_checker_ex hook:
/home/eam
[SPAM] about our photo clipping path
We want to introduce our photo retouching/clipping path. Here are our offerings below: photo retouching, photo clipping path, jewellery photo retouching, ecommerce products photo editing, photo cut out and masking, beauty and skin retouching, wedding photos editing. You may send us a photo for free testing to check quality. Looking foroward to receive your soonest response. Thanks, Jeff Email: lovocont...@tom.com
Re: bug? rand based acl keep re-evaluating
Hi Vivek,
On Thu, Mar 05, 2015 at 01:31:53AM -0600, Vivek Malik wrote:
> Hi Willy,
>
> I am using haproxy/rand to simulate A/B/C... testing between multiple
> environments. Each backend emits a long expiry cookie to put the
> session into their experiment. If a request comes with a cookie of the
> experiment, the request goes to that backend. If a session comes
> without a cookie, rand is used to decide which backend would be used
> for the request.
OK.
> My earlier code looked similar to
>
> acl testa req.cookie(abtest) eq a
> acl testb req.cookie(abtest) eq b
> acl testa_rand rand(100) lt 80
> acl testb_rand rand(20) lt 20
> http-request set-header expirment=a if testa
> http-request set-header expirment=b if testb
>
> http-request set-header expirment=a if !testa !testb testa_rand
> http-request set-header expirment=a if !testa !testb testb_rand
>
> use_backend bk_a if testa
> use_backend bk_b if testb
> use_backend bk_a if testa_rand
> use_backend bk_b if testb_rand
One possibility is also to use default_backend as a fallback. But
it would indeed not fix the multiple/missing header addition.
> However, this config was failing as request would often to backend
> with experiment header not set properly. Once I understood that acl
> was evaluating rand every time, I was able to write the configuration
> something like
>
> http-request del-header experiment
> http-request set-header experiment a if { req.cook(abtest) eq a }
> http-request set-header experiment b if { req.cook(abtest) eq b } &&
> !{ req.hdr(experiment) -m found }
> http-request set-header experiment a if { rand(100) lt 80 } && !{
> req.hdr(experiment) -m found }
> http-request set-header experiment b if { rand(20) lt 20 } && !{
> req.hdr(experiment) -m found }
>
> use_backend bk_a if { req.hdr(experiment) eq a }
> use_backend bk_b if { req.hdr(experiment) eq b }
>
> Using the request header as a temporary variable, I was able to keep
> state and avoid calling rand acl more than once.
Yes that definitely is the way to go.
Cheers,
Willy
