Found a program BUG ??????

2017-05-16 Thread ?t????????
??1??
backend web
ption  httpchk /test.html
http-check expect string Test
balance roundrobin
server my1192.168.37.135:80 check
server my2192.168.37.134:80 check

??2??
backend web
ption  httpchk /test.html
http-check expect rstatus ^2
balance roundrobin
server my1192.168.37.135:80 check
server my2192.168.37.134:80 check

??3??
backend web
#ption  httpchk /test.html
http-check expect string Test
balance roundrobin
server my1192.168.37.135:80 check
server my2192.168.37.134:80 check


 The first configuration error.
 The second, the third configuration is normal.

 I suspect that this is a program BUG.
 Expect to get your reply




This is all the configuration
###-
# main frontend which proxys to the backends
#-
frontend  main *:80


default_backend web


#stats auth  : no authenticat
#stats scope : no restriction
#-
# static backend for serving up images, stylesheets and such
#-
backend web
option  httpchk /test.html
http-check expect rstatus ^2


balance roundrobin
server my1192.168.37.135:80 check
server my2192.168.37.134:80 check


listen stats
bind :9099
stats enable
stats uri /stats
stats realm HAPorxy\ Stats\ Page
stats auth admin:admin
stats admin if TRUE
stats hide-version
##
[root@localhost ~]# curl 192.168.37.135/test.html
Test Page







--

Re: truncated request in log lines

2017-05-16 Thread Stéphane Cottin
Thanks, this is the right answer, recompile with 
DEFINE=-DREQURI_LEN=4096 fixes this issue.
This limit should be raised at runtime according to the log "len" 
option, if you want long log lines, you want them complete :)


Thanks again.
Stéphane


On 16 May 2017, at 19:29, J. Kendzorra wrote:


On 16.05.2017 19:23, J. Kendzorra wrote:

On 16.05.2017 15:58, Stéphane Cottin wrote:

Only the content of "GET /?test=my_very_long_request_truncated" is
truncated to 1024 characters, not the whole line.
The end quote is still present, it does not seems related to syslog
daemon limitations.


I think you're looking for this thread:
http://marc.info/?t=14033356971=1=2


... and pro'ly this one, too :)
http://marc.info/?t=14333217201=1=2

Regards,
J.




Re: haproxy + RDP

2017-05-16 Thread Aleksandar Lazic
Hi Antonio Trujillo Carmona.

Antonio Trujillo Carmona have written on Mon, 15 May 2017 08:40:16
+0200:

> El 12/05/17 a las 11:55, Aleksandar Lazic escribió:
> > Hi Antonio Trujillo Carmona.
> >
> > Antonio Trujillo Carmona have written on Fri, 12 May 2017 10:23:59
> > +0200:
> >  
> >> El 11/05/17 a las 15:06, Aleksandar Lazic escribió:  
> >>> .../
> >>> How about to activate the 'option tcp-check' as mentioned in the
> >>> Warning?
> >>> In the config below is it's commented, any reason why?
> >>>
> >>> It's also active in the doc which you maybe know.
> >>>
> >>> https://www.haproxy.com/doc/aloha/7.0/deployment_guides/microsoft_remote_desktop_services.html
> >>>
> >>> Does this changes anything?
> >> ok cleaing up a liter I try:
> >> frontend RDP
> >> mode tcp
> >> bind *:3389
> >> timeout client 1h
> >> tcp-request inspect-delay 5s
> >> tcp-request content accept if RDP_COOKIE
> >> default_backend bk_rdp
> >> #
> >> backend bk_rdp
> >> mode tcp
> >> balance leastconn
> >> #balance rdp_coockie
> >> timeout server 1h
> >> timeout connect 4s
> >> log global
> >> option tcplog
> >> stick-table type string len 32 size 10k expire 1h peers
> >> pares stick on rdp_cookie(msthash)
> >> #   persist rdp-cookie
> >> option tcp-check
> >> #   option ssl-hello-chk
> >> #   option tcpka
> >> tcp-check connect port 3389 ssl
> >>
> >> #   server gr43sterminal01  10.104.22.142:3389 weight 1 check
> >> verify none inter 2000 rise 2 fall 3
> >> #   server gr43sterminal02  10.104.23.141:3389 weight 1 check
> >> verify none inter 2000 rise 2 fall 3
> >> #
> >> default-server inter 3s rise 2 fall 3
> >> server gr43sterminal01  10.104.22.142:3389 weight 1 check
> >> server gr43sterminal02  10.104.23.141:3389 weight 1 check
> >>
> >> And I got:
> >> [ALERT] 131/100222 (8564) : Proxy 'bk_rdp', server
> >> 'gr43sterminal01' [/etc/haproxy/haproxy.cfg:189] verify is enabled
> >> by default but no CA file specified. If you're running on a LAN
> >> where you're certain to trust the server's certificate, please set
> >> an explicit 'verify none' statement on the 'server' line, or use
> >> 'ssl-server-verify none' in the global section to disable
> >> server-side verifications by default. [ALERT] 131/100222 (8564) :
> >> Proxy 'bk_rdp', server
> >> 'gr43sterminal02' [/etc/haproxy/haproxy.cfg:190] verify is enabled
> >> by default but no CA file specified. If you're running on a LAN
> >> where you're certain to trust the server's certificate, please set
> >> an explicit 'verify none' statement on the 'server' line, or use
> >> 'ssl-server-verify none' in the global section to disable
> >> server-side verifications by default. [ALERT] 131/100222 (8564) :
> >> Fatal errors found in configuration.
> >>
> >> So I try adding verify none in server line
> >>
> >> and haproxy see both server up (but one is down).
> >> I try  withou ssl:
> >>
> >> tcp-check connect port 3389
> >> server gr43sterminal01  10.104.22.142:3389 weight 1 check
> >> server gr43sterminal02  10.104.23.141:3389 weight 1 check
> >>
> >> but the result is the same haproxy see both server up (but one is
> >> down)
> >>
> >> only if I leve only option tcp-check (or none) it seem work
> >>
> >>
> >> #
> >> #   persist rdp-cookie
> >> option tcp-check
> >> #   option ssl-hello-chk
> >> #   option tcpka
> >> #   tcp-check connect port 3389 ssl
> >> #   tcp-check connect port 3389
> >>
> >> #   server gr43sterminal01  10.104.22.142:3389 weight 1 check
> >> verify none inter 2000 rise 2 fall 3
> >> #   server gr43sterminal02  10.104.23.141:3389 weight 1 check
> >> verify none inter 2000 rise 2 fall 3
> >> #
> >> default-server inter 3s rise 2 fall 3
> >> server gr43sterminal01  10.104.22.142:3389 weight 1 check
> >> server gr43sterminal02  10.104.23.141:3389 weight 1 check
> >> ##
> >>
> >>
> >> output:
> >>
> >> [WARNING] 131/102105 (8773) : Server bk_rdp/gr43sterminal01 is
> >> DOWN, reason: Layer4 timeout, info: " at initial connection step of
> >> tcp-check", check duration: 3001ms. 1 active and 0 backup servers
> >> left. 0 sessions active, 0 requeued, 0 remaining in queue.  
> > So finally it works.
> >
> > Regards
> > Aleks  
> But in that mode it check server available, not service, if RDP
> service is down haproxy don't detect it.

Maybe you will need some tcp-check squence to check the service.

http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#4.2-tcp-check%20send
http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#4.2-tcp-check%20send-binary

I have found a perl script which checks the rdp maybe this will help
you to find the right sequence.


Re: HAProxy Page Element Request Times Slowly Increase

2017-05-16 Thread Aleksandar Lazic
Hi Caleb Anthony.

Caleb Anthony have written on Mon, 15 May 2017 19:10:30 -0600:

> Hello All,
> 
> I've got a strange issue with our deployment of HAProxy 1.6 where a
> user will make a request to a page, and as each page element comes
> in, the time taken shown on each file downloaded in the IE developer
> tools increases by a factor of 3, until finally the user is prompted
> for credentials, but the page load never continues. I should mention
> that this is an ASP.NET web application running with Integrated
> Windows Authentication on IIS 8. I know, I know, IE + IIS + IWA =
> terrible, but it's hard for the enterprise to not use these platforms
> internally, especially the IWA single sign on part.
> 
> So a request looks like this in the developer tools:
> 
> mainpage.aspx - HTTP 200 - 130.04KB - 421ms
> css file - HTTP 200 - 1.51KB - 296ms
> css file - HTTP 200 - 14.93KB - 0.96s
> css file - HTTP 200 - 13.99KB - 2.73s
> css file - HTTP 200 - 29.92KB - 8.14s
> css file - HTTP 200 - 23.44KB - 24.36s
> webresource.axd - Pending - Pending - Pending (this is where the user
> is prompted for credentials)
> 
> And on that last file is where it then prompts for credentials, which
> never works because I believe that HAProxy has hit the timeout and
> closed the connection, and breaking IWA.
> 
> I should mention that our HAProxy server works great 99.9% of the
> time, and we do a lot of L7 load balancing on different URLs, and
> host headers, and we handle a good amount of traffic that returns
> page elements in ms, and it also handles Integrated Windows Auth fine
> - most of the time. It's just these occasional things that have me at
> a loss.
> 
> Any suggestions from the mailing list?

Is compression enabled?
In more general way.
Please can you send us the output of haproxy -vv and the haproxy conf,
thanks

Can you reproduce this behavior only for one client/enduser or for
several?

Regards
aleks



Re: truncated request in log lines

2017-05-16 Thread J. Kendzorra
On 16.05.2017 19:23, J. Kendzorra wrote:
> On 16.05.2017 15:58, Stéphane Cottin wrote:
>> Only the content of "GET /?test=my_very_long_request_truncated" is
>> truncated to 1024 characters, not the whole line.
>> The end quote is still present, it does not seems related to syslog
>> daemon limitations.
> 
> I think you're looking for this thread:
> http://marc.info/?t=14033356971=1=2

... and pro'ly this one, too :)
http://marc.info/?t=14333217201=1=2

Regards,
J.




Re: truncated request in log lines

2017-05-16 Thread J. Kendzorra
On 16.05.2017 15:58, Stéphane Cottin wrote:
> Only the content of "GET /?test=my_very_long_request_truncated" is
> truncated to 1024 characters, not the whole line.
> The end quote is still present, it does not seems related to syslog
> daemon limitations.

I think you're looking for this thread:
http://marc.info/?t=14033356971=1=2

Regards,
J.




Re: truncated request in log lines

2017-05-16 Thread Stéphane Cottin

Hi mark,

Thanks for this link, but I guess this is not related to this issue.

Let's use an example.

A log line with method+request+protocol < 1024 characters and a very 
long captured header is ok :


172.17.0.1:38318 [16/May/2017:08:00:31.266] abcde fghij 0/0/106/139/268 
200 9 - -  1/1/0/0/0 0/0 
{ONE_CAPURED_HEADER|ANOTHER_HEADER|A_2048_CHAR_LONG_HEADER} "GET / 
HTTP/1.1"


when method+request+protocol > 1024 characters the log line is still 
valid, but the request is truncated:


172.17.0.1:38318 [16/May/2017:08:00:31.266] abcde fghij 0/0/106/139/268 
200 9 - -  1/1/0/0/0 0/0 {ONE_CAPURED_HEADER|ANOTHER_HEADER| 
A_2048_CHAR_LONG_HEADER} "GET /?test=my_very_long_request_truncated"


Only the content of "GET /?test=my_very_long_request_truncated" is 
truncated to 1024 characters, not the whole line.
The end quote is still present, it does not seems related to syslog 
daemon limitations.


Stéphane


On 16 May 2017, at 14:16, Mark Staudinger wrote:


Hi Stéphane,

On some OSes, including FreeBSD, the syslogd daemon has a hard-coded 
line length of 1024 characters.


Your log daemon may support run-time or configuration options to 
extend this limit.  So you can either use another log daemon, or 
re-compile syslogd with a higher limit, here's one example:


http://bsdpants.blogspot.com/2010/08/truncated-syslog-messages.html

Cheers,
-Mark


On Tue, 16 May 2017 07:28:30 -0400, Stéphane Cottin 
 wrote:



Hi,

Version: haproxy 1.7.2

I'm logging to a unix socket, allowing long lines.

   log /dev/log len 8192 local0
[...]
   option dontlognull
   option log-separate-errors
   option httplog

I'm also capturing the referer header.

   capture request header Referer len 4096

When using large strings (length > 1024 ) the request is truncated to 
1024 characters in the log line, the captured header is not.
The log line is still valid, quotes are present, only the end of the 
request string is missing.


Do I miss some config parameter ? setting the len in the log 
configuration directive shouldn't prevent this ?



Stéphane




Re: truncated request in log lines

2017-05-16 Thread Daniel Schneller
This is a limitation of the syslog protocol, IIRC.

-- 
Daniel Schneller
Principal Cloud Engineer
 
CenterDevice GmbH  | Hochstraße 11
   | 42697 Solingen
tel: +49 1754155711| Deutschland
daniel.schnel...@centerdevice.de   | www.centerdevice.de

Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina,
Michael Rosbach, Handelsregister-Nr.: HRB 18655,
HR-Gericht: Bonn, USt-IdNr.: DE-815299431


> On 16. May. 2017, at 13:28, Stéphane Cottin  wrote:
> 
> Hi,
> 
> Version: haproxy 1.7.2
> 
> I'm logging to a unix socket, allowing long lines.
> 
>  log /dev/log len 8192 local0
> [...]
>  option dontlognull
>  option log-separate-errors
>  option httplog
> 
> I'm also capturing the referer header.
> 
>  capture request header Referer len 4096
> 
> When using large strings (length > 1024 ) the request is truncated to 1024 
> characters in the log line, the captured header is not.
> The log line is still valid, quotes are present, only the end of the request 
> string is missing.
> 
> Do I miss some config parameter ? setting the len in the log configuration 
> directive shouldn't prevent this ?
> 
> 
> Stéphane
> 



truncated request in log lines

2017-05-16 Thread Stéphane Cottin

Hi,

Version: haproxy 1.7.2

I'm logging to a unix socket, allowing long lines.

  log /dev/log len 8192 local0
[...]
  option dontlognull
  option log-separate-errors
  option httplog

I'm also capturing the referer header.

  capture request header Referer len 4096

When using large strings (length > 1024 ) the request is truncated to 
1024 characters in the log line, the captured header is not.
The log line is still valid, quotes are present, only the end of the 
request string is missing.


Do I miss some config parameter ? setting the len in the log 
configuration directive shouldn't prevent this ?



Stéphane



Re: OpenSSL engine and async support

2017-05-16 Thread Emeric Brun
Hi Grant,

On 05/15/2017 08:11 PM, Grant Zhang wrote:
> 
>> On May 15, 2017, at 03:14, Emeric Brun  wrote:
>>
>> What does it look like?
> New patches attached.
> 
>>
>> The issue is very similar: 
>> https://mta.openssl.org/pipermail/openssl-dev/2016-March/005909.html
> Interesting. yeah, it looks similar.
> 
> Regards,
> 
> Grant
> 

I've re-based your patches on latest master and also adds two fixes (in 
attachment).

All my tests are good for now, so i think Willy could merge them.

R,
Emeric


>From 3d5a8bbc96e1e6d6f275c29f416cac9e356389fa Mon Sep 17 00:00:00 2001
From: Grant Zhang 
Date: Sat, 21 Jan 2017 01:10:18 +
Subject: [PATCH 1/4] MEDIUM: ssl: add basic support for OpenSSL crypto engine

This patch adds the global 'ssl-engine' keyword. First arg is an engine
identifier followed by a list of default_algorithms the engine will
operate.

If the openssl version is too old, an error is reported when the option
is used.
---
 doc/configuration.txt|  16 ++
 include/proto/ssl_sock.h |   2 +
 src/haproxy.c|   4 ++
 src/ssl_sock.c   | 147 ---
 4 files changed, 148 insertions(+), 21 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index edd9e79..ffe9f76 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -591,6 +591,7 @@ The following keywords are supported in the "global" section :
- spread-checks
- server-state-base
- server-state-file
+   - ssl-engine
- tune.buffers.limit
- tune.buffers.reserve
- tune.bufsize
@@ -1265,6 +1266,21 @@ spread-checks <0..50, in percent>
   and +/- 50%. A value between 2 and 5 seems to show good results. The
   default value remains at 0.
 
+ssl-engine  [algo ]
+  Sets the OpenSSL engine to . List of valid values for  may be
+  obtained using the command "openssl engine".  This statement may be used
+  multiple times, it will simply enable multiple crypto engines. Referencing an
+  unsupported engine will prevent haproxy from starting. Note that many engines
+  will lead to lower HTTPS performance than pure software with recent
+  processors. The optional command "algo" sets the default algorithms an ENGINE
+  will supply using the OPENSSL function ENGINE_set_default_string(). A value
+  of "ALL" uses the engine for all cryptographic operations.  If no list of
+  algo is specified then the value of "ALL" is used.  A comma-seperated list
+  of different algorithms may be specified, including: RSA, DSA, DH, EC, RAND,
+  CIPHERS, DIGESTS, PKEY, PKEY_CRYPTO, PKEY_ASN1. This is the same format that
+  openssl configuration file uses:
+  https://www.openssl.org/docs/man1.0.2/apps/config.html
+
 tune.buffers.limit 
   Sets a hard limit on the number of buffers which may be allocated per process.
   The default value is zero which means unlimited. The minimum non-zero value
diff --git a/include/proto/ssl_sock.h b/include/proto/ssl_sock.h
index 6f779fa..8779770 100644
--- a/include/proto/ssl_sock.h
+++ b/include/proto/ssl_sock.h
@@ -68,7 +68,9 @@ struct tls_keys_ref *tlskeys_ref_lookupid(int unique_id);
 #endif
 #ifndef OPENSSL_NO_DH
 int ssl_sock_load_global_dh_param_from_file(const char *filename);
+void ssl_free_dh(void);
 #endif
+void ssl_free_engines(void);
 
 SSL_CTX *ssl_sock_create_cert(struct connection *conn, const char *servername, unsigned int key);
 SSL_CTX *ssl_sock_get_generated_cert(unsigned int key, struct bind_conf *bind_conf);
diff --git a/src/haproxy.c b/src/haproxy.c
index 261b213..be1e11d 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -109,6 +109,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* list of config files */
 static struct list cfg_cfgfiles = LIST_HEAD_INIT(cfg_cfgfiles);
@@ -2162,6 +2163,9 @@ int main(int argc, char **argv)
 for (proc = 0; proc < global.nbproc; proc++)
 	while (waitpid(-1, NULL, 0) == -1 && errno == EINTR);
 			}
+#ifndef OPENSSL_NO_DH
+			ssl_free_dh();
+#endif
 			exit(0); /* parent must leave */
 		}
 
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 21d50c7..bad9b99 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -52,6 +52,7 @@
 #ifndef OPENSSL_NO_DH
 #include 
 #endif
+#include 
 
 #include 
 #include 
@@ -207,6 +208,13 @@ static int ssl_capture_ptr_index = -1;
 struct list tlskeys_reference = LIST_HEAD_INIT(tlskeys_reference);
 #endif
 
+static unsigned int openssl_engines_initialized;
+struct list openssl_engines = LIST_HEAD_INIT(openssl_engines);
+struct ssl_engine_list {
+	struct list list;
+	ENGINE *e;
+};
+
 #ifndef OPENSSL_NO_DH
 static int ssl_dh_ptr_index = -1;
 static DH *global_dh = NULL;
@@ -302,6 +310,47 @@ struct ocsp_cbk_arg {
 	};
 };
 
+static int ssl_init_single_engine(const char *engine_id, const char *def_algorithms)
+{
+	int err_code = ERR_ABORT;
+	ENGINE *engine;
+	struct ssl_engine_list *el;
+
+	/* grab the structural reference to the engine */
+	engine = ENGINE_by_id(engine_id);
+	if (engine  == NULL) {
+