Re: rewrite header http:// to https://

[Abdelouahed Haitoute]

Hello Lukas,

Based on the haproxy documentation 
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#4-reqirep 
 I have 
changed the configuration.
Beside changing rspirep, I saw the traffic in wireshark and saw “GET http:/ 
….” data. So I also changed the value “Location:” to 
“Get”.

frontend http1 127.0.0.10:1080
default_backend ssl1

backend ssl1
reqirep ^GET\ http://(.*):80(.*) GET\ https://\1:443\2
reqirep ^GET\ http://(.*) GET\ https://\1
server nginx 192.168.68.100:443 ssl verify required ca-file 
/etc/haproxy/certs/ca.crt crt /etc/haproxy/certs/client.pem

And it works now!

Thanks for your help!

> Op 30 mrt. 2015, om 18:03 heeft Lukas Tribus  het 
> volgende geschreven:
> 
>> I have the following configuration: 
>> 
>> frontend http1 127.0.0.10:1080 
>> rspirep ^Location:\ http://(.*):80(.*) Location:\ https://\1:443\2 
>> rspirep ^Location:\ http://(.*) Location:\ https://\1 
>> default_backend ssl1 
>> 
>> backend ssl1 
>> server sslserver 192.168.68.100:443 ssl verify required ca-file 
>> /etc/haproxy/certs/ca.crt crt /etc/haproxy/certs/client.pem 
>> 
>> Everything is going great, except the rewriting part. The requests are 
>> sended to the sslserver with the original http:// location. 
> 
> rspirep rewrites HTTP responses, not requests.
> 
> What *exactly* are you trying to do?
> 
> 
> 

Re: ldap-check with Active Directory

[Baptiste]

you should believe it :)

On Mon, Mar 30, 2015 at 11:34 PM, Neil - HAProxy List
 wrote:
> Hello
>
> Thanks so much. That worked well, I now get
> L7OK/0 in 0ms
> not sure I believe the 0ms but maybe I should
>
> Thanks again,
>
> Neil
>
> On 30 March 2015 at 22:14, Baptiste  wrote:
>>
>> On Mon, Mar 30, 2015 at 10:33 PM, Neil - HAProxy List
>>  wrote:
>> > Hello
>> >
>> > I'm trying to use ldap-check with active directory and the response
>> > active
>> > directory gives is not one ldap-check is happy to accept
>> >
>> > when I give a 389 directory backend ldap server all is well, when I use
>> > AD I
>> > get 'Not LDAPv3 protocol'
>> >
>> > I've done a little poking about and found that
>> > if ((msglen > 2) ||
>> > (memcmp(check->bi->data + 2 + msglen,
>> > "\x02\x01\x01\x61", 4) != 0)) {
>> > set_server_check_status(check,
>> > HCHK_STATUS_L7RSP, "Not LDAPv3 protocol");
>> > is where I'm getting stopped as msglen is 4
>> >
>> > Here is tcpdump of 389 directory response (the one that works) 2 packets
>> > 21:29:34.195699 IP 389.ldap > HAPROXY.57109: Flags [.], ack 15, win 905,
>> > options [nop,nop,TS val 856711882 ecr 20393440], length 0
>> > 0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
>> > 0x0010:  0034 9d07 4000 3f06 3523 ac1b e955 ac18  .4..@.?.5#...U..
>> > 0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8010  (.\...c.w...
>> > 0x0030:  0389 2c07  0101 080a 3310 62ca 0137  ..,...3.b..7
>> > 0x0040:  2de0 -.
>> > 21:29:34.195958 IP 389.ldap > HAPROXY.57109: Flags [P.], seq 1:15, ack
>> > 15,
>> > win 905, options [nop,nop,TS val 856711882 ecr 20393440], length 14
>> > 0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
>> > 0x0010:  0042 9d08 4000 3f06 3514 ac1b e955 ac18  .B..@.?.5U..
>> > 0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8018  (.\...c.w...
>> > 0x0030:  0389 e878  0101 080a 3310 62ca 0137  ...x..3.b..7
>> > 0x0040:  2de0 300c 0201 0161 070a 0100 0400 0400  -.0a
>> >
>> > Here is tcpdump of active directory (broken) 1 packet
>> >
>> > 21:25:24.519883 IP ADSERVER.ldap > HAPROXY.57789: Flags [P.], seq 1:23,
>> > ack
>> > 15, win 260, options [nop,nop,TS val 1870785 ecr 20331021], length 22
>> > 0x:  0050 5688 7042 0050 5688 7780 0800 4500  .PV.pB.PV.w...E.
>> > 0x0010:  004a 1d7d 4000 8006 34e3 ac18 280d ac18  .J.}@...4...(...
>> > 0x0020:  2810 0185 e1bd 5a3f 2ae7 3ced 7b5b 8018  (.Z?*.<.{[..
>> > 0x0030:  0104 1d7a  0101 080a 001c 8bc1 0136  ...z...6
>> > 0x0040:  3a0d 3084  0010 0201 0161 8400   :.0a
>> > 0x0050:  070a 0100 0400 0400
>> >
>> > this was discussed but not finished before see
>> > http://www.serverphorums.com/read.php?10,394453
>> >
>> > I can see the string \02\01\01\61 is there but not in the correct place
>> >
>> > Anyone have any ideas about fixing this so that both (and possibly
>> > other)
>> > ldap implementations work?
>> >
>> > Thanks,
>> >
>> > Neil
>>
>>
>> Hi Neil
>>
>> Yes you can switch to the tcp-check checking method.
>> I works with binary protocols as well.
>> Here is what I use for the AD in my lab:
>>
>>  option tcp-check
>>  tcp-check connect port 389
>>  tcp-check send-binary 300c0201 # LDAP bind request "" simple
>>  tcp-check send-binary 01 # message ID
>>  tcp-check send-binary 6007 # protocol Op
>>  tcp-check send-binary 0201 # bind request
>>  tcp-check send-binary 03 # LDAP v3
>>  tcp-check send-binary 04008000 # name, simple authentication
>>  tcp-check expect binary 0a0100 # bind response + result code: success
>>  tcp-check send-binary 30050201034200 # unbind request
>>
>>
>> You could add the same sequence for LDAPs on port 636:
>>  tcp-check connect port 636 ssl
>>  tcp-check send-binary 300c0201 # LDAP bind request "" simple
>>  tcp-check send-binary 01 # message ID
>>  tcp-check send-binary 6007 # protocol Op
>>  tcp-check send-binary 0201 # bind request
>>  tcp-check send-binary 03 # LDAP v3
>>  tcp-check send-binary 04008000 # name, simple authentication
>>  tcp-check expect binary 0a0100 # bind response + result code: success
>>  tcp-check send-binary 30050201034200 # unbind request
>>
>>
>> Note for myself: put this tip on the blog..
>>
>> Baptiste
>
>

Re: ldap-check with Active Directory

[Neil - HAProxy List]

Hello

Thanks so much. That worked well, I now get

*L7OK/0 in 0ms*
not sure I believe the 0ms but maybe I should

Thanks again,

Neil

On 30 March 2015 at 22:14, Baptiste  wrote:

> On Mon, Mar 30, 2015 at 10:33 PM, Neil - HAProxy List
>  wrote:
> > Hello
> >
> > I'm trying to use ldap-check with active directory and the response
> active
> > directory gives is not one ldap-check is happy to accept
> >
> > when I give a 389 directory backend ldap server all is well, when I use
> AD I
> > get 'Not LDAPv3 protocol'
> >
> > I've done a little poking about and found that
> > if ((msglen > 2) ||
> > (memcmp(check->bi->data + 2 + msglen,
> > "\x02\x01\x01\x61", 4) != 0)) {
> > set_server_check_status(check,
> > HCHK_STATUS_L7RSP, "Not LDAPv3 protocol");
> > is where I'm getting stopped as msglen is 4
> >
> > Here is tcpdump of 389 directory response (the one that works) 2 packets
> > 21:29:34.195699 IP 389.ldap > HAPROXY.57109: Flags [.], ack 15, win 905,
> > options [nop,nop,TS val 856711882 ecr 20393440], length 0
> > 0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
> > 0x0010:  0034 9d07 4000 3f06 3523 ac1b e955 ac18  .4..@.?.5#...U..
> > 0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8010  (.\...c.w...
> > 0x0030:  0389 2c07  0101 080a 3310 62ca 0137  ..,...3.b..7
> > 0x0040:  2de0 -.
> > 21:29:34.195958 IP 389.ldap > HAPROXY.57109: Flags [P.], seq 1:15, ack
> 15,
> > win 905, options [nop,nop,TS val 856711882 ecr 20393440], length 14
> > 0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
> > 0x0010:  0042 9d08 4000 3f06 3514 ac1b e955 ac18  .B..@.?.5U..
> > 0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8018  (.\...c.w...
> > 0x0030:  0389 e878  0101 080a 3310 62ca 0137  ...x..3.b..7
> > 0x0040:  2de0 300c 0201 0161 070a 0100 0400 0400  -.0a
> >
> > Here is tcpdump of active directory (broken) 1 packet
> >
> > 21:25:24.519883 IP ADSERVER.ldap > HAPROXY.57789: Flags [P.], seq 1:23,
> ack
> > 15, win 260, options [nop,nop,TS val 1870785 ecr 20331021], length 22
> > 0x:  0050 5688 7042 0050 5688 7780 0800 4500  .PV.pB.PV.w...E.
> > 0x0010:  004a 1d7d 4000 8006 34e3 ac18 280d ac18  .J.}@...4...(...
> > 0x0020:  2810 0185 e1bd 5a3f 2ae7 3ced 7b5b 8018  (.Z?*.<.{[..
> > 0x0030:  0104 1d7a  0101 080a 001c 8bc1 0136  ...z...6
> > 0x0040:  3a0d 3084  0010 0201 0161 8400   :.0a
> > 0x0050:  070a 0100 0400 0400
> >
> > this was discussed but not finished before see
> > http://www.serverphorums.com/read.php?10,394453
> >
> > I can see the string \02\01\01\61 is there but not in the correct place
> >
> > Anyone have any ideas about fixing this so that both (and possibly other)
> > ldap implementations work?
> >
> > Thanks,
> >
> > Neil
>
>
> Hi Neil
>
> Yes you can switch to the tcp-check checking method.
> I works with binary protocols as well.
> Here is what I use for the AD in my lab:
>
>  option tcp-check
>  tcp-check connect port 389
>  tcp-check send-binary 300c0201 # LDAP bind request "" simple
>  tcp-check send-binary 01 # message ID
>  tcp-check send-binary 6007 # protocol Op
>  tcp-check send-binary 0201 # bind request
>  tcp-check send-binary 03 # LDAP v3
>  tcp-check send-binary 04008000 # name, simple authentication
>  tcp-check expect binary 0a0100 # bind response + result code: success
>  tcp-check send-binary 30050201034200 # unbind request
>
>
> You could add the same sequence for LDAPs on port 636:
>  tcp-check connect port 636 ssl
>  tcp-check send-binary 300c0201 # LDAP bind request "" simple
>  tcp-check send-binary 01 # message ID
>  tcp-check send-binary 6007 # protocol Op
>  tcp-check send-binary 0201 # bind request
>  tcp-check send-binary 03 # LDAP v3
>  tcp-check send-binary 04008000 # name, simple authentication
>  tcp-check expect binary 0a0100 # bind response + result code: success
>  tcp-check send-binary 30050201034200 # unbind request
>
>
> Note for myself: put this tip on the blog..
>
> Baptiste
>

Re: using a fetcher in wrong context, performance tip

[Baptiste]

On Mon, Mar 30, 2015 at 10:11 PM, Pavlos Parissis
 wrote:
> Hi all,
>
> During a stress test I discovered a drop of 5% performance at rate of
> 380K req/s when the following 3 statements were added in a frontend
> where HTTPS is not used
>
> http-request add-header X-Cipher-Name %sslc
> http-request add-header X-Cipher-Version %sslv
> http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize]
>
> Here is the stress result
> # wrk --timeout 3s --latency -c 1000 -d 5m -t 24
> http://10.190.3.1/
> Running 5m test @ http://10.190.3.1/
>   24 threads and 1000 connections
>   Thread Stats   Avg  Stdev Max   ± Stdev
> Latency 2.31ms  815.14us  27.06ms   74.32%
> Req/Sec16.98k 2.25k   32.00k85.12%
>   Latency Distribution
>  50%2.43ms
>  75%2.71ms
>  90%3.15ms
>  99%3.88ms
>   115019521 requests in 5.00m, 16.50GB read
>   Socket errors: connect 0, read 0, write 0, timeout 13264
> Requests/sec: 383420.54
> Transfer/sec: 56.31MB
>
> After I removed only the ssl_fc_use_keysize fetcher
> http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize]
>
> performance was improved by 5%, see below
> # wrk --timeout 3s --latency -c 1000 -d 5m -t 24
> http://10.190.3.1/
> Running 5m test @ http://10.190.3.1/
>   24 threads and 1000 connections
>   Thread Stats   Avg  Stdev Max   ± Stdev
> Latency 2.12ms  831.01us 206.61ms   74.86%
> Req/Sec17.88k 2.22k   31.56k80.62%
>   Latency Distribution
>  50%2.30ms
>  75%2.62ms
>  90%2.88ms
>  99%3.72ms
>   120947683 requests in 5.00m, 17.35GB read
>   Socket errors: connect 0, read 0, write 0, timeout 17255
> Requests/sec: 403180.76
> Transfer/sec: 59.21MB
>
> When I added it back but with a condition if traffic is HTTPS
> performance at that high rate of request was increased
>  http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize] if
> https_traffic
>
> stress results:
> # wrk --timeout 3s --latency -c 1000 -d 5m -t 24
> http://10.190.3.1/
> Running 5m test @ http://10.190.3.1/
>   24 threads and 1000 connections
>   Thread Stats   Avg  Stdev Max   ± Stdev
> Latency 2.07ms  823.41us  32.08ms   75.64%
> Req/Sec17.86k 2.27k   29.56k81.81%
>   Latency Distribution
>  50%2.27ms
>  75%2.54ms
>  90%2.76ms
>  99%3.80ms
>   120945989 requests in 5.00m, 17.35GB read
>   Socket errors: connect 0, read 0, write 0, timeout 19828
> Requests/sec: 403177.77
> Transfer/sec: 59.21MB
>
>
> I also added the same condition for other 2 variables accessed as log
> formatters and the performance was improved even more
>
> stress results with
>  http-request add-header X-Cipher-Name %sslc if https_traffic
>  http-request add-header X-Cipher-Version %sslv if https_traffic
>  http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize] if
> https_traffic
>
> # wrk --timeout 3s --latency -c 1000 -d 5m -t 24
> http://10.190.3.1/
> Running 5m test @ http://10.190.3.1/
>   24 threads and 1000 connections
>   Thread Stats   Avg  Stdev Max   ± Stdev
> Latency 2.12ms9.64ms 607.23ms   99.79%
> Req/Sec19.43k 3.28k   33.56k82.82%
>   Latency Distribution
>  50%1.95ms
>  75%2.20ms
>  90%2.41ms
>  99%3.36ms
>   131646991 requests in 5.00m, 18.88GB read
>   Socket errors: connect 0, read 0, write 0, timeout 30179
> Requests/sec: 438828.20
> Transfer/sec: 64.45MB
>
> Lesson learned here is to either condition all your statements or pay
> attention at the context you apply a logic.
>
>
> Cheers,
> Pavlos
>


Hey

Just to highlight the most important point, from my point of view:
  "Requests/sec: 438828.20"

nice job man!

Baptiste

Re: ldap-check with Active Directory

[Baptiste]

On Mon, Mar 30, 2015 at 10:33 PM, Neil - HAProxy List
 wrote:
> Hello
>
> I'm trying to use ldap-check with active directory and the response active
> directory gives is not one ldap-check is happy to accept
>
> when I give a 389 directory backend ldap server all is well, when I use AD I
> get 'Not LDAPv3 protocol'
>
> I've done a little poking about and found that
> if ((msglen > 2) ||
> (memcmp(check->bi->data + 2 + msglen,
> "\x02\x01\x01\x61", 4) != 0)) {
> set_server_check_status(check,
> HCHK_STATUS_L7RSP, "Not LDAPv3 protocol");
> is where I'm getting stopped as msglen is 4
>
> Here is tcpdump of 389 directory response (the one that works) 2 packets
> 21:29:34.195699 IP 389.ldap > HAPROXY.57109: Flags [.], ack 15, win 905,
> options [nop,nop,TS val 856711882 ecr 20393440], length 0
> 0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
> 0x0010:  0034 9d07 4000 3f06 3523 ac1b e955 ac18  .4..@.?.5#...U..
> 0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8010  (.\...c.w...
> 0x0030:  0389 2c07  0101 080a 3310 62ca 0137  ..,...3.b..7
> 0x0040:  2de0 -.
> 21:29:34.195958 IP 389.ldap > HAPROXY.57109: Flags [P.], seq 1:15, ack 15,
> win 905, options [nop,nop,TS val 856711882 ecr 20393440], length 14
> 0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
> 0x0010:  0042 9d08 4000 3f06 3514 ac1b e955 ac18  .B..@.?.5U..
> 0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8018  (.\...c.w...
> 0x0030:  0389 e878  0101 080a 3310 62ca 0137  ...x..3.b..7
> 0x0040:  2de0 300c 0201 0161 070a 0100 0400 0400  -.0a
>
> Here is tcpdump of active directory (broken) 1 packet
>
> 21:25:24.519883 IP ADSERVER.ldap > HAPROXY.57789: Flags [P.], seq 1:23, ack
> 15, win 260, options [nop,nop,TS val 1870785 ecr 20331021], length 22
> 0x:  0050 5688 7042 0050 5688 7780 0800 4500  .PV.pB.PV.w...E.
> 0x0010:  004a 1d7d 4000 8006 34e3 ac18 280d ac18  .J.}@...4...(...
> 0x0020:  2810 0185 e1bd 5a3f 2ae7 3ced 7b5b 8018  (.Z?*.<.{[..
> 0x0030:  0104 1d7a  0101 080a 001c 8bc1 0136  ...z...6
> 0x0040:  3a0d 3084  0010 0201 0161 8400   :.0a
> 0x0050:  070a 0100 0400 0400
>
> this was discussed but not finished before see
> http://www.serverphorums.com/read.php?10,394453
>
> I can see the string \02\01\01\61 is there but not in the correct place
>
> Anyone have any ideas about fixing this so that both (and possibly other)
> ldap implementations work?
>
> Thanks,
>
> Neil


Hi Neil

Yes you can switch to the tcp-check checking method.
I works with binary protocols as well.
Here is what I use for the AD in my lab:

 option tcp-check
 tcp-check connect port 389
 tcp-check send-binary 300c0201 # LDAP bind request "" simple
 tcp-check send-binary 01 # message ID
 tcp-check send-binary 6007 # protocol Op
 tcp-check send-binary 0201 # bind request
 tcp-check send-binary 03 # LDAP v3
 tcp-check send-binary 04008000 # name, simple authentication
 tcp-check expect binary 0a0100 # bind response + result code: success
 tcp-check send-binary 30050201034200 # unbind request


You could add the same sequence for LDAPs on port 636:
 tcp-check connect port 636 ssl
 tcp-check send-binary 300c0201 # LDAP bind request "" simple
 tcp-check send-binary 01 # message ID
 tcp-check send-binary 6007 # protocol Op
 tcp-check send-binary 0201 # bind request
 tcp-check send-binary 03 # LDAP v3
 tcp-check send-binary 04008000 # name, simple authentication
 tcp-check expect binary 0a0100 # bind response + result code: success
 tcp-check send-binary 30050201034200 # unbind request


Note for myself: put this tip on the blog..

Baptiste

[SPAM] Hot Sale Smart Watch,simliar with MOTO360

[David]

Title: Dear Friend






Dear Friend,
How are you?
 
As the Apple Watch launching,smart watch 
is becoming very hot product.
We have several hot sale smart watches 
for your reference,such as D360,round circle,similar with MOTO 360.
More details,pls contact with me 
directly.thanks.
 

Jump2U offers the best platform to access Manufacturers 
directly, and offer local after sales support. All advantages for your business!

 
David 
Customer Service
Shenzhen Jump2U Technology Limited
Hotline: +86-13828709445
Skype: davidken1
www.jump2u.com
 

	
		
			
			
			
			This email communication (and any attachments) is proprietary 
			information for the sole use of its intended recipient. Any 
			unauthorized review, use or distribution by anyone other than the 
			intended recipient is strictly prohibited. If you are not the 
			intended recipient, please delete this email and any copies of it 
			immediately. Thank you.
			
			
			If you don't want to continue receiving news and offers from Jump2U, 
			please click 
			here to 
			unsubscribe.
			
			
			 
		
		
			
			
			
			 
		
		
			
			
			
			 
		
		
			
			
			
			 
		
	


 
 
 

How can I secure multiple haproxy ssl certs at rest?

[Kirsten Stewart]

To not fill this up with text, I'll link directly to my post.  Surely
someone else has run into this problem before.

http://stackoverflow.com/questions/29354110/how-to-protect-haproxy-ssl-certificates-as-a-service

ldap-check with Active Directory

[Neil - HAProxy List]

Hello

I'm trying to use ldap-check with active directory and the response active
directory gives is not one ldap-check is happy to accept

when I give a 389 directory backend ldap server all is well, when I use AD
I get 'Not LDAPv3 protocol'

I've done a little poking about and found that
if ((msglen > 2) ||
(memcmp(check->bi->data + 2 + msglen,
"\x02\x01\x01\x61", 4) != 0)) {
set_server_check_status(check,
HCHK_STATUS_L7RSP, "Not LDAPv3 protocol");
is where I'm getting stopped as msglen is 4

Here is tcpdump of 389 directory response (the one that works) 2 packets
21:29:34.195699 IP 389.ldap > HAPROXY.57109: Flags [.], ack 15, win 905,
options [nop,nop,TS val 856711882 ecr 20393440], length 0
0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
0x0010:  0034 9d07 4000 3f06 3523 ac1b e955 ac18  .4..@.?.5#...U..
0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8010  (.\...c.w...
0x0030:  0389 2c07  0101 080a 3310 62ca 0137  ..,...3.b..7
0x0040:  2de0 -.
21:29:34.195958 IP 389.ldap > HAPROXY.57109: Flags [P.], seq 1:15, ack 15,
win 905, options [nop,nop,TS val 856711882 ecr 20393440], length 14
0x:  0050 5688 7042 0064 403b 2700 0800 4500  .PV.pB.d@;'...E.
0x0010:  0042 9d08 4000 3f06 3514 ac1b e955 ac18  .B..@.?.5U..
0x0020:  2810 0185 df15 5cab ffcd 63ba 77d3 8018  (.\...c.w...
0x0030:  0389 e878  0101 080a 3310 62ca 0137  ...x..3.b..7
0x0040:  2de0 300c 0201 0161 070a 0100 0400 0400  -.0a

Here is tcpdump of active directory (broken) 1 packet

21:25:24.519883 IP ADSERVER.ldap > HAPROXY.57789: Flags [P.], seq 1:23, ack
15, win 260, options [nop,nop,TS val 1870785 ecr 20331021], length 22
0x:  0050 5688 7042 0050 5688 7780 0800 4500  .PV.pB.PV.w...E.
0x0010:  004a 1d7d 4000 8006 34e3 ac18 280d ac18  .J.}@...4...(...
0x0020:  2810 0185 e1bd 5a3f 2ae7 3ced 7b5b 8018  (.Z?*.<.{[..
0x0030:  0104 1d7a  0101 080a 001c 8bc1 0136  ...z...6
0x0040:  3a0d 3084  0010 0201 0161 8400   :.0a
0x0050:  070a 0100 0400 0400

this was discussed but not finished before see
http://www.serverphorums.com/read.php?10,394453

I can see the string \02\01\01\61 is there but not in the correct place

Anyone have any ideas about fixing this so that both (and possibly other)
ldap implementations work?

Thanks,

Neil

Re: [haproxy]: Performance of haproxy-to-4-nginx vs direct-to-nginx

[Pavlos Parissis]

On 30/03/2015 07:13 πμ, Krishna Kumar Unnikrishnan (Engineering) wrote:
> Hi all,
> 
> I am testing haproxy as follows:
> 
> System1: 24 Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz, 64 GB. This system
> is running 3.19.0 kernel, and hosts the following servers:
> 1. nginx1 server - cpu 1-2, 1G memory, runs as a Linux
> container using cpuset.cpus feature.
> 2. nginx2 server - cpu 3-4, 1G memory, runs via LXC.
> 3. nginx3 server - cpu 5-6, 1G memory, runs via LXC.
> 4. nginx4 server - cpu 7-8, 1G memory, runs via LXC.
> 5. haproxy - cpu 9-10, 1G memory runs via LXC. Runs haproxy
> ver 1.5.8: configured with above 4 container's ip
> addresses as the backend.
> 
> System2: 56 Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz, 128 GB. This system
> is running 3.19.0, and run's 'ab' either to the haproxy node, or
> directly to an nginx container. System1 & System2 are locally
> connected via a switch with Intel 10G cards.
> 
> With very small packets of 64 bytes, I am getting the following results:
> 
> A. ab -n 10 -c 4096 http://nginx1:80/64
> -
> 
> Concurrency Level:  4096
> Time taken for tests:   3.232 seconds
> Complete requests:  10
> Failed requests:0
> Total transferred:  2880 bytes
> HTML transferred:   640 bytes
> Requests per second:30943.26 [#/sec] (mean)
> Time per request:   132.371 [ms] (mean)
> Time per request:   0.032 [ms] (mean, across all concurrent requests)
> Transfer rate:  8702.79 [Kbytes/sec] received
> 
> Connection Times (ms)
>   min  mean[+/-sd] median   max
> Connect:9   65 137.4 451050
> Processing: 4   52  25.3 51 241
> Waiting:3   37  19.2 35 234
> Total: 16  117 146.11111142
> 
> Percentage of the requests served within a certain time (ms)
>   50%111 66%119 75%122
>   80%124 90%133 95%215
>   98%254 99%   1126 100%   1142 (longest request)
> 
> B. ab -n 10 -c 4096 http://haproxy:80/64
> --
> 
> Concurrency Level:  4096
> Time taken for tests:   5.503 seconds
> Complete requests:  10
> Failed requests:0
> Total transferred:  2880 bytes
> HTML transferred:   640 bytes
> Requests per second:18172.96 [#/sec] (mean)
> Time per request:   225.390 [ms] (mean)
> Time per request:   0.055 [ms] (mean, across all concurrent requests)
> Transfer rate:  5111.15 [Kbytes/sec] received
> 
> Connection Times (ms)
>   min  mean[+/-sd] median   max
> Connect:0  134 358.3 233033
> Processing: 2   61  47.7 51 700
> Waiting:2   50  43.0 42 685
> Total:  7  194 366.7 793122
> 
> Percentage of the requests served within a certain time (ms)
>   50% 79 66%105 75%134
>   80%159 90%318 95%   1076
>   98%   1140 99%   1240 100%   3122 (longest request)
> 
> I expected haproxy to deliver better results with multiple connections,
> since
> haproxy will round-robin between the 4 servers. I have done no tuning,
> and have
> used the config file at the end of this mail. With 256K file size, the times
> are slightly better for haproxy vs nginx. I notice that %requests served is
> similar for both cases till about 90%.
> 
> Any help is very much appreciated.
> 

You have mentioned the CPU load on the host and on the guest systems.
Use pidstat -p $(pgrep -d ',' haproxy) -u  1 to monitor CPU stats of
haproxy processes and  mpstat -P ALL 1 and check CPU load for software
interrupts.


Cheers,
Pavlos




signature.asc
Description: OpenPGP digital signature

using a fetcher in wrong context, performance tip

[Pavlos Parissis]

Hi all,

During a stress test I discovered a drop of 5% performance at rate of
380K req/s when the following 3 statements were added in a frontend
where HTTPS is not used

http-request add-header X-Cipher-Name %sslc
http-request add-header X-Cipher-Version %sslv
http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize]

Here is the stress result
# wrk --timeout 3s --latency -c 1000 -d 5m -t 24
http://10.190.3.1/
Running 5m test @ http://10.190.3.1/
  24 threads and 1000 connections
  Thread Stats   Avg  Stdev Max   ± Stdev
Latency 2.31ms  815.14us  27.06ms   74.32%
Req/Sec16.98k 2.25k   32.00k85.12%
  Latency Distribution
 50%2.43ms
 75%2.71ms
 90%3.15ms
 99%3.88ms
  115019521 requests in 5.00m, 16.50GB read
  Socket errors: connect 0, read 0, write 0, timeout 13264
Requests/sec: 383420.54
Transfer/sec: 56.31MB

After I removed only the ssl_fc_use_keysize fetcher
http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize]

performance was improved by 5%, see below
# wrk --timeout 3s --latency -c 1000 -d 5m -t 24
http://10.190.3.1/
Running 5m test @ http://10.190.3.1/
  24 threads and 1000 connections
  Thread Stats   Avg  Stdev Max   ± Stdev
Latency 2.12ms  831.01us 206.61ms   74.86%
Req/Sec17.88k 2.22k   31.56k80.62%
  Latency Distribution
 50%2.30ms
 75%2.62ms
 90%2.88ms
 99%3.72ms
  120947683 requests in 5.00m, 17.35GB read
  Socket errors: connect 0, read 0, write 0, timeout 17255
Requests/sec: 403180.76
Transfer/sec: 59.21MB

When I added it back but with a condition if traffic is HTTPS
performance at that high rate of request was increased
 http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize] if
https_traffic

stress results:
# wrk --timeout 3s --latency -c 1000 -d 5m -t 24
http://10.190.3.1/
Running 5m test @ http://10.190.3.1/
  24 threads and 1000 connections
  Thread Stats   Avg  Stdev Max   ± Stdev
Latency 2.07ms  823.41us  32.08ms   75.64%
Req/Sec17.86k 2.27k   29.56k81.81%
  Latency Distribution
 50%2.27ms
 75%2.54ms
 90%2.76ms
 99%3.80ms
  120945989 requests in 5.00m, 17.35GB read
  Socket errors: connect 0, read 0, write 0, timeout 19828
Requests/sec: 403177.77
Transfer/sec: 59.21MB


I also added the same condition for other 2 variables accessed as log
formatters and the performance was improved even more

stress results with
 http-request add-header X-Cipher-Name %sslc if https_traffic
 http-request add-header X-Cipher-Version %sslv if https_traffic
 http-request add-header X-Cipher-Bits %[ssl_fc_use_keysize] if
https_traffic

# wrk --timeout 3s --latency -c 1000 -d 5m -t 24
http://10.190.3.1/
Running 5m test @ http://10.190.3.1/
  24 threads and 1000 connections
  Thread Stats   Avg  Stdev Max   ± Stdev
Latency 2.12ms9.64ms 607.23ms   99.79%
Req/Sec19.43k 3.28k   33.56k82.82%
  Latency Distribution
 50%1.95ms
 75%2.20ms
 90%2.41ms
 99%3.36ms
  131646991 requests in 5.00m, 18.88GB read
  Socket errors: connect 0, read 0, write 0, timeout 30179
Requests/sec: 438828.20
Transfer/sec: 64.45MB

Lesson learned here is to either condition all your statements or pay
attention at the context you apply a logic.


Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature

RE: [SPAM] jBoss thread count issue while upgrading from 1.5dev21 to 1.5.11

[Lukas Tribus]

Hi Willy,

>> Put "option http-tunnel" in your default section, this will restore pre 
>> 1.5dev22
>> behavior. Read more about this here:
>> http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-tunnel
>
> Hmmm no, there's option forceclose, so the two are supposed to close.
> There's something else I guess

Ups, I overlooked that, yes. forceclose is set on the only backend, so this is 
not the problem,
if this is the complete configuration.

In case the configuration is (over-)"simplified" however, there may be some 
services affected
by this anyway.

Nevertheless, more details are required.


Lukas

  

RE: rewrite header http:// to https://

[Lukas Tribus]

> I have the following configuration: 
> 
> frontend http1 127.0.0.10:1080 
> rspirep ^Location:\ http://(.*):80(.*) Location:\ https://\1:443\2 
> rspirep ^Location:\ http://(.*) Location:\ https://\1 
> default_backend ssl1 
> 
> backend ssl1 
> server sslserver 192.168.68.100:443 ssl verify required ca-file 
> /etc/haproxy/certs/ca.crt crt /etc/haproxy/certs/client.pem 
> 
> Everything is going great, except the rewriting part. The requests are 
> sended to the sslserver with the original http:// location. 

rspirep rewrites HTTP responses, not requests.

What *exactly* are you trying to do?


  

Re: rewrite header http:// to https://

[Abdelouahed Haitoute]

By the way, just to be complete. The HTTP-traffic is proxied from a squid proxy 
server. 

Abdelouahed

> Op 30 mrt. 2015, om 16:26 heeft Abdelouahed Haitoute  het 
> volgende geschreven:
> 
> Hello,
> 
> I’m trying to rewrite the HTTP header, rewriting http to https. Using the 
> following article 
> http://blog.haproxy.com/2013/02/26/ssl-offloading-impact-on-web-applications/ 
> 
>  .
> 
> I have the following configuration:
> 
> frontend http1 127.0.0.10:1080
> rspirep ^Location:\ http://(.*):80(.*) Location:\ https://\1:443\2 
> 
> rspirep ^Location:\ http://(.*) Location:\ https://\1 
> default_backend ssl1
> 
> backend ssl1
>   server sslserver 192.168.68.100:443 ssl verify required ca-file 
> /etc/haproxy/certs/ca.crt crt /etc/haproxy/certs/client.pem
> 
> Everything is going great, except the rewriting part. The requests are sended 
> to the sslserver with the original http:// location.
> 
> Hopefully someone can help me with the rewrite part.
> 
> Abdelouahed

rewrite header http:// to https://

[Abdelouahed Haitoute]

Hello,

I’m trying to rewrite the HTTP header, rewriting http to https. Using the 
following article 
http://blog.haproxy.com/2013/02/26/ssl-offloading-impact-on-web-applications/ 
 
.

I have the following configuration:

frontend http1 127.0.0.10:1080
rspirep ^Location:\ http://(.*):80(.*) Location:\ https://\1:443\2
rspirep ^Location:\ http://(.*) Location:\ https://\1
default_backend ssl1

backend ssl1
server sslserver 192.168.68.100:443 ssl verify required ca-file 
/etc/haproxy/certs/ca.crt crt /etc/haproxy/certs/client.pem

Everything is going great, except the rewriting part. The requests are sended 
to the sslserver with the original http:// location.

Hopefully someone can help me with the rewrite part.

Abdelouahed

Re: [SPAM] jBoss thread count issue while upgrading from 1.5dev21 to 1.5.11

[Willy Tarreau]

Hi Lukas,

On Mon, Mar 30, 2015 at 02:55:32PM +0200, Lukas Tribus wrote:
> Hi Sarvesh,
> 
> 
> > Dear Team, 
> > 
> > We upgraded my haproxy from 1.5dev21 to 1.5.11 stable version with same 
> > configuration. At the backend, we are using jBoss. 
> > As soon as we upgraded, we encountered serious issue regarding jBoss 
> > thread counts. It has been increased tremendously. 
> > After rollback to 1.5dev21, everything works fine. 
> 
> Put "option http-tunnel" in your default section, this will restore pre 
> 1.5dev22
> behavior. Read more about this here:
> http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-tunnel

Hmmm no, there's option forceclose, so the two are supposed to close.
There's something else I guess. Some logs, traces or whatever will
definitely be needed I fear.

Regards,
Willy

RE: [SPAM] jBoss thread count issue while upgrading from 1.5dev21 to 1.5.11

[Lukas Tribus]

Hi Sarvesh,


> Dear Team, 
> 
> We upgraded my haproxy from 1.5dev21 to 1.5.11 stable version with same 
> configuration. At the backend, we are using jBoss. 
> As soon as we upgraded, we encountered serious issue regarding jBoss 
> thread counts. It has been increased tremendously. 
> After rollback to 1.5dev21, everything works fine. 

Put "option http-tunnel" in your default section, this will restore pre 1.5dev22
behavior. Read more about this here:
http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#option%20http-tunnel


Lukas

  

[SPAM] jBoss thread count issue while upgrading from 1.5dev21 to 1.5.11

[Sarvesh padwal]

Dear Team,

We upgraded myhaproxyfrom 1.5dev21 to 1.5.11 stable version with same 
configuration. At the backend, we are using jBoss.
As soon as we upgraded, we encountered serious issue regarding jBoss 
thread counts. It has been increased tremendously.

After rollback to 1.5dev21, everything works fine.
Please find my below configuration file ofhaproxy. Kindly suggest any 
changes required to migrate/upgrade to 1.5.11.


-

global
daemon
maxconn 2

defaults
mode http
timeout connect 15000ms
timeout client 5ms
timeout server 5ms
timeout queue 60s
stats enable
stats refresh 5s

backend backend_http
mode http
cookie JSESSIONID prefix
balance leastconn
option forceclose
option persist
option redispatch
option  forwardfor
server server3192.168.58.211:80 cookie 
server3_cokkie maxconn 1024 check
server server4192.168.58.212:80 cookie 
server4_cookie maxconn 1024 check

acl force_sticky_server3 hdr_sub(server3_cookie) TEST=true
force-persist if force_sticky_server3
acl force_sticky_server4 hdr_sub(server4_cookie) TEST=true
force-persist if force_sticky_server4
rspidel  ^Server:.*
rspidel  ^X-Powered-By:.*
rspidel  ^AMF-Ver:.*

listen frontend_http *:80
   mode http
   maxconn 2
   default_backend backend_http

listen frontend_https
   mode http
   maxconn 2
   bind *:443 ssl crt /opt/haproxy-ssl/conf/ssl/testsite.pem
   reqadd X-Forwarded-Proto:\ https
   reqadd X-Forwarded-Protocol:\ https
   reqadd X-Forwarded-Port:\ 443
   reqadd X-Forwarded-SSL:\ on
   acl valid_domains hdr_end(host) -igateway.testsite.com 
www.testsite.com 
m.testsite.com 

   redirect scheme http  if !valid_domains
   default_backend backend_http if valid_domains


--


NOTE: The jboss thread count went high very fast (as if connections were 
not closed anymore).



Thanks & Regards,
Sarvesh

Disclaimer: This e-mail and any documents, files, or previous e-mail messages 
appended or attached to it may contain confidential and/or privileged 
information. If you are not the intended recipient (or have received this 
e-mail in error) please notify the sender immediately and delete this e-mail. 
Any unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.