Quantcast
Channel: Serverphorums.com - HAProxy
Viewing all 5112 articles
Browse latest View live

CLEANUP: chunk (1 reply)

0
0
Hi all,

Here a cleanup patch for the chunk_dup function.
hope it can be useful.

Regards.

Pour les jours Scottage, 50% de remise sur une selection d'articles ! Faites vite! (no replies)

CLEANUP: connection (3 replies)

0
0
Hi again,

This is tiny one, this one I just spotted when I tried a build on FreeBSD
with clang.

clang detected unused functions as well but I did not dare to delete them,
they might but just here "on hold" for future purposes (ie
init_comp_ctx/deinit_comp_ctx and had_fd_isset in src/ev_poll.c).

Kind regards.

TLS Tickets and CPU usage (5 replies)

0
0
Hello guys,

I'm having troubles with HAProxy 1.6.3 and TLS ticket, so let me explain
here my case.

I'm running HAProxy 1.6.3 (since december) and all was running fine. TLS
ticket was explicitely disabled. The only downside of this setup is that
after each reload, I have a CPU spike for a few seconds. I thought this was
due to session renegociation (right ?)

A few days ago, I decided to activate TLS-Ticket and use option
tls-ticket-keys on bind lines. My hope was to remove this CPU spike, as
session renegociation should be faster.
But CPU usage doubled ! I disabled it by adding again
"ssl-default-bind-options no-tls-tickets" and CPU usage returned to normal.

From the doc, I read that activating TLS ticket may use "slightly" more
CPU, but I hoped that using tickets file could help in this case.
Apparently I'm wrong.

Any detailed explanation and feedback would be really useful here.

Snippet of my config (I know I'm using old syntax for listen/bind) :

global
tune.ssl.default-dh-param 2048
tune.ssl.lifetime 100800
tune.ssl.cachesize 1000000
#ssl-default-bind-options no-tls-tickets
ssl-default-bind-ciphers
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384
:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-D
ES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!
DES:!MD5:!PSK:!RC4

listen xxxx:443
bind xxx:443 ssl crt /etc/ssl/ssl_xxx.pem no-sslv3 tls-ticket-keys
/tmp/tls_ticket_keys
server s107 xxx:80 check weight 5 fall 60

*******************
HAProxy version :

HA-Proxy version 1.6.3 2015/12/25
Copyright 2000-2015 Willy Tarreau <willy@haproxy.org>

Build options :
TARGET = linux2628
CPU = native
CC = gcc
CFLAGS = -O2 -march=native -g -fno-strict-aliasing
-Wdeclaration-after-statement
OPTIONS = USE_OPENSSL=1 USE_PCRE=1 USE_TFO=1

Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built without compression support (neither USE_ZLIB nor USE_SLZ are set)
Compression algorithms supported : identity("identity")
Built with OpenSSL version : OpenSSL 1.0.2f 28 Jan 2016
Running on OpenSSL version : OpenSSL 1.0.2f 28 Jan 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 7.2 2007-06-19
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built without Lua support
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND


*************************
And /tmp/tls_ticket_keys generated with "openssl rand -base64 48" called 3x
+ appended at each reload.


Olivier

Exchange 2013 / NTLM Connections (1 reply)

0
0
Hi,

I'm hoping someone can help with an Exchange 2013 / NTLM Authentication question.

(My background is more on the networking side, so I'm finding my way a bit with HTTP related challenges...)

We're currently running HA Proxy v1.6.4 and trying to use it in-front of an Exchange 2013 CAS set-up.

The challenge that we're having is whilst everything appears to be working, we're having connectivity 'issues' when trying to migrate users to Office 365.

I've been trying to read-up on this and understand what might be happening.

- Our Frontend is running in HTTP mode, terminating the HTTPS connections to the outside world.
- Our Backend is also running in HTTP mode, connecting back to the CAS Servers over HTTPS.

The migration to Office 365 process connects to:

https://mail.ourcompany.com/EWS/mrsproxy.svc

From the HA Proxy Logs, we can see that this works successfully for a number of requests like this:

Mar 23 09:12:19 ae-lb01.ourcompany.org haproxy[18151]: 132.245.40.245:56136 [23/Mar/2016:09:12:19.478] ft_exchange~ bk_exch_2013/ae-exch02 353/0/0/42/+395 200 +721 - - ---- 289/289/1/1/0 0/0 {mail.ourcompany.com||1504} {715506} "POST /EWS/mrsproxy.svc HTTP/1.1"

Mar 23 09:12:19 ae-lb01. ourcompany.org haproxy[18151]: 132.245.40.245:56136 [23/Mar/2016:09:12:18.726] ft_exchange~ bk_exch_2013/ae-exch02 15/0/0/401/+416 200 +722 - - ---- 286/286/1/1/0 0/0 {mail.ourcompany.com||2435} {5620718} "POST /EWS/mrsproxy.svc HTTP/1.1"

This works fine for about 500 log entries (in this instance; it appears to be random). Then we get a few 401 errors:

Mar 23 09:12:19 ae-lb01.ourcompany.org haproxy[18151]: 132.245.40.245:61593 [23/Mar/2016:09:12:19.179] ft_exchange~ bk_exch_2013/ae-exch02 12/0/2/2/+16 401 +477 - - ---- 288/288/2/2/0 0/0 {mail.ourcompany.com||2435} {0} "POST /EWS/mrsproxy.svc HTTP/1.1"

Mar 23 09:12:19 ae-lb01.ourcompany.org haproxy[18151]: 132.245.40.245:61593 [23/Mar/2016:09:12:19.207] ft_exchange~ bk_exch_2013/ae-exch02 6/0/0/1/+7 401 +693 - - ---- 288/288/2/2/0 0/0 {mail.ourcompany.com||0} {0} "POST /EWS/mrsproxy.svc HTTP/1.1"

Interestingly, although the source IP is the same, the source tcp port changes. This is not unexpected; tcp connections will come to an end and new ones will start.

The problem that we're having is that as soon as this new connection starts, we just then see a series of 401 errors from the same source IP, but different source tcp port.

After doing some reading, as best as I can tell, this may be down to the NTLM / Windows Authentication that is used in the process.

To understand this more, I've added some capture lines to my Frontend configuration:

capture request header Host len 50
capture request header User-Agent len 500
capture request header Content-Length len 50
capture request header Authorization len 500

capture response header Content-Length len 50
capture response header WWW-Authenticate len 500
capture response header Authentication-Info len 500

After doing this and re-starting some bits, I can now see some more of the Authentication information is the logs:

Mar 23 18:13:05 ae-lb01.ourcompany.org haproxy[3443]: 132.245.47.13:20099 [23/Mar/2016:18:13:05.660] ft_exchange~ bk_exch_2013/ae-exch02 8/0/1/2/+11 401 +693 - - ---- 192/192/1/1/0 0/0 {mail.ourcompany.com||0|Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAvAjAAAADw==} {0|NTLM|} "POST /EWS/mrsproxy.svc HTTP/1.1"

Mar 23 18:13:26 ae-lb01.ourcompany.org haproxy[3443]: 132.245.47.13:20099 [23/Mar/2016:18:13:05.671] ft_exchange~ bk_exch_2013/ae-exch02 7/0/0/21029/+21036 503 +482 - - ---- 194/194/1/1/0 0/0 {mail.ourcompany.com||663|Negotiate TlRMTVNTUAADAAAAGAAYAJYAAABsAWwBrgAAABIAEgBYAAAAEgASAGoAAAAaABoAfAAAABAAEAAaAgAAFYKI4gYC8CMAAAAPZvo1ootKOIM3n52pgdGLYm8AZgBmAGkAYwBlAG8AcgBnAG0AZgBhAGIAYQBkAG0AaQBuAEEATQAzAFAAUgAwADUATQBCAD} {0||} "POST /EWS/mrsproxy.svc HTTP/1.1"

This was a useful insight into how Microsoft's NTLM / Windows Authentication uses the HTTP headers and 401 responses:

http://www.innovation.ch/personal/ronald/ntlm.html

As was:

https://www.ietf.org/rfc/rfc4559.txt

My conclusion is that because HA Proxy is re-using the backend to Exchange connection, the overall conversation between Office 365 and Exchange is no longer authenticated.

My next step was to was to do some more reading about HA Proxy's HTTP 'connection modes'. This section in the documentation was great:

http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#4

As was this reference from ALOHA:

https://www.haproxy.com/static/media/uploads/eng/resources/aloha_load_balancer_http_connection_mode_memo2.pdf

So (finally), I'm down to my real question:

- What HA Proxy HTTP 'connection' mode should I be using with a Backend that is providing an NTLM Authenticated Service?
- My understand is that it should be 'tunnel mode'.
- This can be configured on the backend with, 'option tunnel-mode'.
- This is needed, because in v1.6 and above, the default connection mode is now 'keep alive'.

Is anyone able to confirm that my understanding is correct?

The reason that I'm slightly confused, as in ALOHA's guide (top of page 27), it looks like they've recommended using the 'option http-keep-alive' and 'no option tunnel-mode'. This would put the connection mode to 'keep alive'..

https://www.haproxy.com/static/media/uploads/eng/resources/aloha_load_balancer_appnotes_0065_exchange_2013_deployment_guide_en.pdf
So if anyone has had a similar experience, or can confirm the correct HTTP 'connection mode', that would be great.

Many thanks,

Graham.

Weird stick-tables / peers behaviour (1 reply)

0
0
Hi all,

I've just upgraded some hosts to 1.6.4 (from 1.5) and immediately got a
bunch of SMS because we're using stick-tables to track the connections
and monitor http_req_rate. The stick-tables data will be synced to the
other peers using the "peers" section.
So I setup a test case using two HAProxy instances with e.g.:
global
user haproxy
group haproxy
maxconn 10000
stats socket /var/run/haproxy.stat user haproxy gid haproxy mode
600 level admin

# aus der anti-dos config
defaults
timeout client 60s
timeout server 60s
timeout queue 60s
timeout connect 3s
timeout http-request 10s


frontend test
bind 0.0.0.0:8080
mode http

tcp-request inspect-delay 7s
tcp-request content track-sc1 src table backend_sourceip

tcp-request content reject if {
sc1_http_req_rate(backend_sourceip) gt 15 }

http-request deny if { sc1_http_req_rate(backend_sourceip) gt 15
}


peers foo_peers
peer host1 172.16.0.128:8024
peer host2 172.16.0.16:8024

backend backend_sourceip
# 1mio IPs, 8hrs TTL per entry for several stats per IP in 10s
stick-table type ip size 1m expire 8h store
gpc0,conn_cnt,conn_cur,conn_rate(10s),http_req_cnt,http_req_rate(10s),http_err_cnt,http_err_rate(10s)
peers foo_peers


I then have 4 terminals, two for doing a:
watch "echo 'show table backend_sourceip' | socat stdio
/var/run/haproxy.stat"

and two for doing some "curl -Lvs http://127.0.0.1:8080&quot; by hand.
If you do some on the first and some on the second host you'll notice
different values on one side. Also the counter may e.g. double while the
other side has the correct/actual value. This results into several
thousands of requests on our prod. systems but according to the logs it
can't be correct.
Does anybody else have similar weirdness or can you guys confirm false
values?
The *_cnt values seem to be ok but the *_rate ones seem to be false in
some cases.

--
Regards,
Christian Ruppert

Haproxy and FastCGI sockets (1 reply)

0
0
Hello,

we're using Haproxy 1.5.5-1 to load balance traffic between frontentds
running Lighttpd with mod_FastCGI and backends running a custom Perl
app, based on FastCGI. Traffic between front and backends is not http -
frontends open a socket to the VIP, and thus communicate to the backends.

The problem occurs when we restart haproxy due to config changes, as the
frontend doesn't know the socket has closed, and starts throwing errors.
After restarting Lighty on the frontends, everything works fine again.

The question is - can Haproxy handle such restarts in a better way, or
is this the only way?

Below is the relevant haproxy config:

listen CI_2001 1.2.3.4:5000
mode tcp
balance leastconn
server xx 192.168.0.100:5000 check inter 2000 rise 2 fall 5
server yy 192.168.0.200:5000 check inter 2000 rise 2 fall 5

thanks, Stojan

some lighting fixtures required for one large project (no replies)

0
0
&£36889;&£26159;&£199=68;&£20491;&£22312;&£39321;&£28207;&£20197;&£21450;&£26481;&£21335;&£2=0126;&£30340;&£38917;&£30446;&£65292;&£35531;&£30475;&£38468;&£20214;&=£12290;&£35531;&£21839;&£652=92;&£33021;&£22312;3&£26376;26&£34399;&£65292;&£19979;&£21320;2&£40670=;&£20043;&£21069;&£22577;&£20729;&£21966;&£65311; VincentShum= ProjectsManager VK&amp;SCO.,LTDUNIT04,7/F,BRIGHTWAYTOWER,NO.33MONGKOKROAD,KOWLOON,HKEmail:Shum.Vincent@outlook.co=m

Re:LED Tri Proof Light (no replies)

0
0
Hello! Howareyou? ThisiswestonformLEDMASUSlimited,NowourhotsellingLED=TriProofLight,Thishavethebestpriceandquality,productwarran=ty:3years. Ifyouhaveinterestpleasecontactus. Thankyou.

[PATCH] BUG/MEDIUM: Fix RFC5077 resumption when more than TLS_TICKETS_NO are present (no replies)

0
0
Olivier Doucet reported the issue on the ML and tested that when using
more than TLS_TICKETS_NO keys in the file, the CPU usage is much higeher
than expected.

Lukas Tribus then provided a test case which showed that resumption doesn't
work at all in that case.

This fix needs to be backported to 1.6.

Signed-off-by: Nenad Merdanovic <nmerdan@anine.io>
---
src/ssl_sock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 1017388..994cdcc 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -5406,8 +5406,8 @@ static int bind_parse_tls_ticket_keys(char **args, int cur_arg, struct proxy *px
fclose(f);

/* Use penultimate key for encryption, handle when TLS_TICKETS_NO = 1 */
- i-=2;
- keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i;
+ i -= 2;
+ keys_ref->tls_ticket_enc_index = i < 0 ? 0 : i % TLS_TICKETS_NO;
keys_ref->unique_id = -1;
conf->keys_ref = keys_ref;

--
2.7.0

unsubscrib (no replies)

0
0
unsubscrib



*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

unsubscribe (no replies)

0
0
unsubscribe



*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

unsubscribe (no replies)

Pour les jours Scottage, 50% de remise sur une selection d'articles ! Faites vite! (no replies)

Re: "Bus error" in dns_build_query on SPARC/Solaris 10 (1 reply)

0
0
On Sat, Mar 26, 2016 at 7:44 AM, Александр Лебедев
<alexander.yu.lebedev@gmail.com> wrote:
> Hello!
>
> When I use resolvers check in 1.6.3 haproxy, it is crashed with "Bus error".
> pstack with core file shows me:
>
> 000a6d1c dns_build_query (11f921, 1c, 16a650, 21, 11f8f0, 1238f0) + a8
> 000a6d58 dns_send_query (16a698, 10be18, 0, 13ac90, 0, 8f1b) + 24
> 00048f28 trigger_resolution (169db8, 16a698, 13acc8, 65, 8f1b, 8f1b) + c0
> 0004d4bc process_chk (12f8a8, 80000003, 116800, 10c000, 1, 16a1a8) + 28c
> 00022dbc process_runnable_tasks (10c0d4, 92ffc, 10c000, 10c000, 10c0e4, 0) +
> 174
> 00019354 run_poll_loop (10c000, 116800, 10c000, 10be2c, 11cbf0, 116968) + c8
> 000159d0 main (4, ffbffba4, ffffffff, 106704, 10bc00, 10bc00) + 618
> 00016468 _start (4, ffbffba4, ffbffbb8, ffbffcbb, ffffffff, 1e) + 5c

Hi

Can't you provide more information?
I have no access to sparc machines, so it will be complicated to
reproduce the problem.

Could it be related to an endianess mismatch ?

Baptiste

Il est nouveau et vous allez l’adorer ! (no replies)

0
0
Le nouveau site Carrefour : vous allez l’adorer !


body {
min-width: 320px;
}

.header-logo-mini {
display: none;
}

.caddies .mobile {
display: none;
}

@media only screen and (max-device-width: 640px) {
.header-logo {
display: none;
}

.header-logo-mini {
display: block;
}
.col33 {
display: block;
padding: 15px 0 !important;
text-align: center !important;
float: none !important;
width: 100% !important;
border: none !important;
}
.col50-mrg {
display: block;
padding: 10px 0;

text-align: center !important;
float: none !important;
width: 50% !important;
}
}

@media only screen and (max-width: 640px) {
.header-logo {
display: none;
}

.header-logo-mini {
display: block;
}
.col33 {
display: block;
padding: 15px 0 !important;
text-align: center !important;
float: none !important;
width: 50% !important;
border: none !important;
}
.col50-mrg {
display: block;
padding: 10px 0;

text-align: center !important;
float: none !important;
width: 100% !important;
}
}




&#x1F38A; &nbsp;Un petit nouveau qui va vous surprendre...

Si vous ne visualisez pas correctement le contenu, consulter la version en ligne






































365 bonnes raisons de se faire plaisir avec le nouveau site Carrefour

































De super avantages chaque jour !








Deal du jour









Bon plan promo









Courses au quotidien









Loisirs en tout genres









Guides et conseils









Tous les services







































































Application mobile


Vos listes de courses, votre cagnotte, vos coupons o&ugrave; que vous soyez.

























&bull; Pour vous assurer de recevoir notre newsletter, nous vous recommandons d’ajouter l'adresse 
carrefour-service-clients@emailing.carrefour.fr dans votre carnet d'adresses.
&bull; Pour vous abonner, vous désabonner et gérer vos données personnelles, suivez ce lien.



CARREFOUR HYPERMARCHES SAS au capital de 6 922 200&euro;. BP 60075 - 91002 Evry Cedex.
RCS Evry 451 321 335 APE 521 F



Droit d'accès aux données personnelles : Conformément à la Loi Informatique et Libertés
du 6 janvier 1978, vous disposez d'un droit d'accès et de rectification des données vous
concernant. Pour exercer ce droit, ne répondez pas à cet email mais utilisez notre formulaire
de contact accessible sur notre site 
www.carrefour.fr 
(pour en savoir plus, consultez les mentions légales sur le site 
Carrefour.fr).



Crédit photos : Gettyimages

[SPAM] Non Réception de paiement (no replies)

0
0
Cher(e) EDF Client(e) :

Votre paiement a

"Bus error" in dns_build_query on SPARC/Solaris 10 (no replies)

0
0
Hello!

When I use resolvers check in 1.6.3 haproxy, it is crashed with "Bus error".
pstack with core file shows me:

000a6d1c dns_build_query (11f921, 1c, 16a650, 21, 11f8f0, 1238f0) + a8
000a6d58 dns_send_query (16a698, 10be18, 0, 13ac90, 0, 8f1b) + 24
00048f28 trigger_resolution (169db8, 16a698, 13acc8, 65, 8f1b, 8f1b) + c0
0004d4bc process_chk (12f8a8, 80000003, 116800, 10c000, 1, 16a1a8) + 28c
00022dbc process_runnable_tasks (10c0d4, 92ffc, 10c000, 10c000, 10c0e4, 0) + 174
00019354 run_poll_loop (10c000, 116800, 10c000, 10be2c, 11cbf0, 116968) + c8
000159d0 main (4, ffbffba4, ffffffff, 106704, 10bc00, 10bc00) + 618
00016468 _start (4, ffbffba4, ffbffbb8, ffbffcbb, ffffffff, 1e) + 5c

蝸同时构成工伤的,,如果劳动者已获得侵权赔偿, (no replies)

0
0
16029933915296374708449057944730079566269939461254485962553604137918803829037243745916756573643723848825902436740612386461100252919429958054111736623057914152063784417049852691267123254459871609255427705844649805835381409166635572125848749307281869359047302377046019385713398873030107256878113694528361266360173137884961368034634769262489140269622289562006836008629076213667295738469911854909295971009167344









aUdnuJiv



rCt



279

Dernière génération de protection d'écran Réf 66187 (no replies)

0
0
Bonjour,


Cordialement, Morgane DUPONT
Viewing all 5112 articles
Browse latest View live


Latest Images