[SPAM] Votre Mutuelle à prix minis, 3 mois offerts

2015-04-23 Thread 1mutuelle
Afficher la version web. (http://trk.mix.uneoffredeouf.com/view/5rs-kwV3.php) | 
Me désinscrire. (http://trk.mix.uneoffredeouf.com/usb/5rs-kwV3.php) | Signaler 
comme courrier indésirable. (mailto:ab...@dgcnit.fr)

http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php 
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php 
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php 
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php 
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php 
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php 
http://trk.mix.uneoffredeouf.com/tk/5rs-kwV3-bPE.php

Espaces Promos, 12 rue Camille Desmoulins, 92300 Levallois Perret.
Conformément à l'article 34 de la loi Informatique et Liberté du 6 janvier 
1978, vous disposez d'un droit d'accès, de modification,
de rectification et de suppression des données vous concernant en adressant 
votre demande à quot;rep...@dgcnit.frquot;.
Déclaration CNIL - 1642645



Re: SSL backends stopped working

2015-04-23 Thread Igor Cicimov
On 23/04/2015 6:01 PM, i...@linux-web-development.de wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi!

 I'm having trouble with one of our HAProxy-Servers that uses a backend
with TLS. When starting HAProxy the backend will report all servers as down:

 Server web_remote/apache_rem_1 is DOWN, reason: Layer6 invalid response,
info: SSL handshake failure,

When i see this it is usually issue with the ciphers. Can you try setting
specific cipher in the ssl backend that you know is supported by the
backend servers?

check duration: 41ms. 1 active and 0 backup servers left. 0 sessions
active, 0 requeued, 0 remaining in queue.



 My backend configuration is as follows:

 backend web_remote
 balance leastconn
 option  httpchk HEAD /
 option  redispatch
 retries 3

 default-server  inter 5000 rise 2 fall 5 maxconn 1 maxqueue 5

 server apache_rem_1  1.2.3.4:12345 check maxconn 1000
maxqueue 5000 ssl ca-file /etc/ssl/web.pem
 server apache_rem_2  2001:1:2:3:4:5:6:8:12345  check maxconn 1000
maxqueue 5000 ssl ca-file /etc/ssl/web.pem


 This backend worked just fine until now, a quick wget on the server also
worked and openssl s_client reports the certificate of the backend to be
valid.

 I couldn't find anything on the list except that the error would be due
to SSL_ABORT, but I'm not sure what this is supposed to tell me...

 Is there anything else for HAProxy/TLS that could be configured wrong?
How could I debug this issue when everything else reports the handshake was
successful?
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQIcBAEBCAAGBQJVOKYDAAoJEJGDW18KFrBD7p4P/05tlwkxRUJwVoI3Tl1Q3+xI
 upIcN9MfTHPpA6ilVkT2S43HxyZ7RYgYGRs6LEcipLJOhGSxIHcPgGZKwsMJK8NO
 cldP20A0SoRvkUsro1UWOj/iqAsxg+j6IYNxuBJUb5i2yG6KFlp/PupJJI1QDUov
 NzyfjqIh9iSgRA6j3jJSYUDLg5KM3Frl8O0GQysztxF8fihambx8vYjlEkIyrrtc
 obmRN3hyIHnJC3oTfhEtpyg8ihV8B6XCNCEHXLonEa8QQ4lIluKhDmh+LsydZ/og
 oEFQeBNp8VfRVIx8iT1ixNFAtw85ZcB0X5GpUMxHZ5l4IscD2THCfqge+nbOIoCw
 9gHitbrKEe323DXIAiv/xWiJZNw3DwDyPDIXFLypBH2F6ZRSosBMyFwkj5omj3ey
 FKAL6DLXDylMgbrihSKA381GktPa5Vr/QmlMjr924VVDbQBmgFBiF7MKeSFHoAjT
 AJvWXplp8jIb7c1wo5vOVEa3MqLEW6Me+r2RvbAiDbQbXmVbRGmVgXo0WeZ2xgMq
 yhFAoW4JvgrrAqNdocXxc2DoP7BU51zu4b9qq4aPECUzyODpLYtU/PCDNBuvBcWI
 erGvwQt6iJP5C8NDHz/Q2mEdBgAq5K+qoSDn5CK+pmWDdR26AVRU8bH8Np4JP2ec
 c+qlPjicDRLalAn3jmQa
 =9FK7
 -END PGP SIGNATURE-




Re: SSL backends stopped working

2015-04-23 Thread info
SSLv3 is not allowed anywhere in our infrastructure, it is disabled 
already.


On 2015-04-23 16:09, Baptiste wrote:

maybe the server refuses sslv3...
Can you disable sslv3 on the server side?

Baptiste

On Thu, Apr 23, 2015 at 3:38 PM,  i...@linux-web-development.de 
wrote:

I've checked again, but the time on those servers is correct..

On 2015-04-23 14:16, Daniel Schneller wrote:


Have you checked the time/date on the Haproxy host?
If they are wrong, the certificate might look bad from HAProxy's
point of view.

Daniel

--
Daniel Schneller
Infrastructure Architect / Developer
CenterDevice GmbH


On 23.04.2015, at 10:00, i...@linux-web-development.de wrote:

Hi!

I'm having trouble with one of our HAProxy-Servers that uses a
backend with TLS. When starting HAProxy the backend will report all
servers as down:


Server web_remote/apache_rem_1 is DOWN, reason: Layer6 invalid
response, info: SSL handshake failure, check duration: 41ms. 1
active and 0 backup servers left. 0 sessions active, 0 requeued, 0
remaining in queue.



My backend configuration is as follows:

backend web_remote
balance leastconn
option httpchk HEAD /
option redispatch
retries 3

default-server inter 5000 rise 2 fall 5 maxconn 1 maxqueue
5

server apache_rem_1 1.2.3.4:12345 check maxconn 1000 maxqueue 5000
ssl ca-file /etc/ssl/web.pem
server apache_rem_2 2001:1:2:3:4:5:6:8:12345 check maxconn 1000
maxqueue 5000 ssl ca-file /etc/ssl/web.pem

This backend worked just fine until now, a quick wget on the server
also worked and openssl s_client reports the certificate of the
backend to be valid.

I couldn't find anything on the list except that the error would be
due to SSL_ABORT, but I'm not sure what this is supposed to tell
me...

Is there anything else for HAProxy/TLS that could be configured
wrong? How could I debug this issue when everything else reports the
handshake was successful?









503 when using set-path and mapped backend

2015-04-23 Thread Robert Samuel Newson
Hi All,

I’m playing with the new set-path feature and encountered a bug. I’m using 
1.6-dev1 plus all the patches up to Apr 22nd, I think we’re all clear that 
set-path was not working at all in 1.6-dev1 itself. It does now work but not in 
all situations I’d expect.

My config is below. I do nc -lk 8000 for the backend. For the first three 
cases, I see the right HTTP request printed there. For the fourth, nothing, and 
haproxy generates a 503. This is true if backend.map is empty (and thus the 
default back should be chosen, which does exist) or it can contain valid 
mappings to back and still returns 503 for requests with a matching Host 
header.


global
  nbproc 1

defaults
  mode http
  log global
  balance roundrobin
  option httplog
  option log-health-checks
  option log-separate-errors
  option forwardfor
  option redispatch
  retries 4
  option http-server-close
  timeout client 150s
  timeout server 1h
  timeout connect 5s
  timeout queue 5s

frontend front
  bind :9000

  # comment out as appropriate

  # case 1: works
  use_backend %[hdr(host),map(backend.map,back)]

  # case 2: works
  use_backend back

  # case 3: works
  http-request set-path /foo
  use_backend back

  # case 4: fails (503 response, no request sent to backend)
  # backend.map can be empty or contain a valid mapping
  http-request set-path /foo
  use_backend %[hdr(host),lower,map(backend.map,back)]

backend back
  server server1 127.0.0.1:8000 weight 10 check inter 7s




Re: [PATCH v2 0/4] MEDIUM: Enhancements to reporting of drain in stats

2015-04-23 Thread Simon Horman
On Thu, Apr 23, 2015 at 10:01:19AM +0200, Willy Tarreau wrote:
 Hi Simon,
 
 On Thu, Apr 23, 2015 at 02:51:25PM +0900, Simon Horman wrote:
 (...)
  This series attempts to address that problem by first disentangling the
  state and colour of servers in the first two patches, which are new -
  arguably a worthwhile clean-up in its own right. The remaining two patches
  implement the changes to reporting of the drain state, as described above.
  
  Patches have been lightly tested.
 
 I reviewed the whole series and it looked pretty good, so I've merged it.
 Ran a few tests as well, no problem identified so I'm pretty confident.
 I'm glad you got rid of this correlation between colors and states, now
 it will be easier to extend this if needed.
 
 Thanks for this work!

Great, thanks.



Re: SSL backends stopped working

2015-04-23 Thread Baptiste
maybe the server refuses sslv3...
Can you disable sslv3 on the server side?

Baptiste

On Thu, Apr 23, 2015 at 3:38 PM,  i...@linux-web-development.de wrote:
 I've checked again, but the time on those servers is correct..

 On 2015-04-23 14:16, Daniel Schneller wrote:

 Have you checked the time/date on the Haproxy host?
 If they are wrong, the certificate might look bad from HAProxy's
 point of view.

 Daniel

 --
 Daniel Schneller
 Infrastructure Architect / Developer
 CenterDevice GmbH

 On 23.04.2015, at 10:00, i...@linux-web-development.de wrote:

 Hi!

 I'm having trouble with one of our HAProxy-Servers that uses a
 backend with TLS. When starting HAProxy the backend will report all
 servers as down:

 Server web_remote/apache_rem_1 is DOWN, reason: Layer6 invalid
 response, info: SSL handshake failure, check duration: 41ms. 1
 active and 0 backup servers left. 0 sessions active, 0 requeued, 0
 remaining in queue.


 My backend configuration is as follows:

 backend web_remote
 balance leastconn
 option httpchk HEAD /
 option redispatch
 retries 3

 default-server inter 5000 rise 2 fall 5 maxconn 1 maxqueue
 5

 server apache_rem_1 1.2.3.4:12345 check maxconn 1000 maxqueue 5000
 ssl ca-file /etc/ssl/web.pem
 server apache_rem_2 2001:1:2:3:4:5:6:8:12345 check maxconn 1000
 maxqueue 5000 ssl ca-file /etc/ssl/web.pem

 This backend worked just fine until now, a quick wget on the server
 also worked and openssl s_client reports the certificate of the
 backend to be valid.

 I couldn't find anything on the list except that the error would be
 due to SSL_ABORT, but I'm not sure what this is supposed to tell
 me...

 Is there anything else for HAProxy/TLS that could be configured
 wrong? How could I debug this issue when everything else reports the
 handshake was successful?






SSL backends stopped working

2015-04-23 Thread info

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

I'm having trouble with one of our HAProxy-Servers that uses a backend 
with TLS. When starting HAProxy the backend will report all servers as 
down:


Server web_remote/apache_rem_1 is DOWN, reason: Layer6 invalid 
response, info: SSL handshake failure, check duration: 41ms. 1 active 
and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining 
in queue.



My backend configuration is as follows:

backend web_remote
balance leastconn
option  httpchk HEAD /
option  redispatch
retries 3

default-server  inter 5000 rise 2 fall 5 maxconn 1 maxqueue 
5


server apache_rem_1  1.2.3.4:12345 check maxconn 1000 
maxqueue 5000 ssl ca-file /etc/ssl/web.pem
server apache_rem_2  2001:1:2:3:4:5:6:8:12345  check maxconn 1000 
maxqueue 5000 ssl ca-file /etc/ssl/web.pem



This backend worked just fine until now, a quick wget on the server also 
worked and openssl s_client reports the certificate of the backend to be 
valid.


I couldn't find anything on the list except that the error would be due 
to SSL_ABORT, but I'm not sure what this is supposed to tell me...


Is there anything else for HAProxy/TLS that could be configured wrong? 
How could I debug this issue when everything else reports the handshake 
was successful?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVOKYDAAoJEJGDW18KFrBD7p4P/05tlwkxRUJwVoI3Tl1Q3+xI
upIcN9MfTHPpA6ilVkT2S43HxyZ7RYgYGRs6LEcipLJOhGSxIHcPgGZKwsMJK8NO
cldP20A0SoRvkUsro1UWOj/iqAsxg+j6IYNxuBJUb5i2yG6KFlp/PupJJI1QDUov
NzyfjqIh9iSgRA6j3jJSYUDLg5KM3Frl8O0GQysztxF8fihambx8vYjlEkIyrrtc
obmRN3hyIHnJC3oTfhEtpyg8ihV8B6XCNCEHXLonEa8QQ4lIluKhDmh+LsydZ/og
oEFQeBNp8VfRVIx8iT1ixNFAtw85ZcB0X5GpUMxHZ5l4IscD2THCfqge+nbOIoCw
9gHitbrKEe323DXIAiv/xWiJZNw3DwDyPDIXFLypBH2F6ZRSosBMyFwkj5omj3ey
FKAL6DLXDylMgbrihSKA381GktPa5Vr/QmlMjr924VVDbQBmgFBiF7MKeSFHoAjT
AJvWXplp8jIb7c1wo5vOVEa3MqLEW6Me+r2RvbAiDbQbXmVbRGmVgXo0WeZ2xgMq
yhFAoW4JvgrrAqNdocXxc2DoP7BU51zu4b9qq4aPECUzyODpLYtU/PCDNBuvBcWI
erGvwQt6iJP5C8NDHz/Q2mEdBgAq5K+qoSDn5CK+pmWDdR26AVRU8bH8Np4JP2ec
c+qlPjicDRLalAn3jmQa
=9FK7
-END PGP SIGNATURE-




Re: [PATCH v2 0/4] MEDIUM: Enhancements to reporting of drain in stats

2015-04-23 Thread Willy Tarreau
Hi Simon,

On Thu, Apr 23, 2015 at 02:51:25PM +0900, Simon Horman wrote:
(...)
 This series attempts to address that problem by first disentangling the
 state and colour of servers in the first two patches, which are new -
 arguably a worthwhile clean-up in its own right. The remaining two patches
 implement the changes to reporting of the drain state, as described above.
 
 Patches have been lightly tested.

I reviewed the whole series and it looked pretty good, so I've merged it.
Ran a few tests as well, no problem identified so I'm pretty confident.
I'm glad you got rid of this correlation between colors and states, now
it will be easier to extend this if needed.

Thanks for this work!
Willy




Re: SSL backends stopped working

2015-04-23 Thread Daniel Schneller
Have you checked the time/date on the Haproxy host?
If they are wrong, the certificate might look bad from HAProxy’s point of view.


Daniel
-- 
Daniel Schneller
Infrastructure Architect / Developer
CenterDevice GmbH




 On 23.04.2015, at 10:00, i...@linux-web-development.de wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Hi!
 
 I'm having trouble with one of our HAProxy-Servers that uses a backend with 
 TLS. When starting HAProxy the backend will report all servers as down:
 
 Server web_remote/apache_rem_1 is DOWN, reason: Layer6 invalid response, 
 info: SSL handshake failure, check duration: 41ms. 1 active and 0 backup 
 servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
 
 
 My backend configuration is as follows:
 
 backend web_remote
balance leastconn
option  httpchk HEAD /
option  redispatch
retries 3
 
default-server  inter 5000 rise 2 fall 5 maxconn 1 maxqueue 5
 
server apache_rem_1  1.2.3.4:12345 check maxconn 1000 maxqueue 
 5000 ssl ca-file /etc/ssl/web.pem
server apache_rem_2  2001:1:2:3:4:5:6:8:12345  check maxconn 1000 maxqueue 
 5000 ssl ca-file /etc/ssl/web.pem
 
 
 This backend worked just fine until now, a quick wget on the server also 
 worked and openssl s_client reports the certificate of the backend to be 
 valid.
 
 I couldn't find anything on the list except that the error would be due to 
 SSL_ABORT, but I'm not sure what this is supposed to tell me...
 
 Is there anything else for HAProxy/TLS that could be configured wrong? How 
 could I debug this issue when everything else reports the handshake was 
 successful?
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2
 
 iQIcBAEBCAAGBQJVOKYDAAoJEJGDW18KFrBD7p4P/05tlwkxRUJwVoI3Tl1Q3+xI
 upIcN9MfTHPpA6ilVkT2S43HxyZ7RYgYGRs6LEcipLJOhGSxIHcPgGZKwsMJK8NO
 cldP20A0SoRvkUsro1UWOj/iqAsxg+j6IYNxuBJUb5i2yG6KFlp/PupJJI1QDUov
 NzyfjqIh9iSgRA6j3jJSYUDLg5KM3Frl8O0GQysztxF8fihambx8vYjlEkIyrrtc
 obmRN3hyIHnJC3oTfhEtpyg8ihV8B6XCNCEHXLonEa8QQ4lIluKhDmh+LsydZ/og
 oEFQeBNp8VfRVIx8iT1ixNFAtw85ZcB0X5GpUMxHZ5l4IscD2THCfqge+nbOIoCw
 9gHitbrKEe323DXIAiv/xWiJZNw3DwDyPDIXFLypBH2F6ZRSosBMyFwkj5omj3ey
 FKAL6DLXDylMgbrihSKA381GktPa5Vr/QmlMjr924VVDbQBmgFBiF7MKeSFHoAjT
 AJvWXplp8jIb7c1wo5vOVEa3MqLEW6Me+r2RvbAiDbQbXmVbRGmVgXo0WeZ2xgMq
 yhFAoW4JvgrrAqNdocXxc2DoP7BU51zu4b9qq4aPECUzyODpLYtU/PCDNBuvBcWI
 erGvwQt6iJP5C8NDHz/Q2mEdBgAq5K+qoSDn5CK+pmWDdR26AVRU8bH8Np4JP2ec
 c+qlPjicDRLalAn3jmQa
 =9FK7
 -END PGP SIGNATURE-
 
 



Re: SSL backends stopped working

2015-04-23 Thread info

I've checked again, but the time on those servers is correct..

On 2015-04-23 14:16, Daniel Schneller wrote:

Have you checked the time/date on the Haproxy host?
If they are wrong, the certificate might look bad from HAProxy’s
point of view.

Daniel

--
Daniel Schneller
Infrastructure Architect / Developer
CenterDevice GmbH


On 23.04.2015, at 10:00, i...@linux-web-development.de wrote:

Hi!

I'm having trouble with one of our HAProxy-Servers that uses a
backend with TLS. When starting HAProxy the backend will report all
servers as down:


Server web_remote/apache_rem_1 is DOWN, reason: Layer6 invalid
response, info: SSL handshake failure, check duration: 41ms. 1
active and 0 backup servers left. 0 sessions active, 0 requeued, 0
remaining in queue.


My backend configuration is as follows:

backend web_remote
balance leastconn
option httpchk HEAD /
option redispatch
retries 3

default-server inter 5000 rise 2 fall 5 maxconn 1 maxqueue
5

server apache_rem_1 1.2.3.4:12345 check maxconn 1000 maxqueue 5000
ssl ca-file /etc/ssl/web.pem
server apache_rem_2 2001:1:2:3:4:5:6:8:12345 check maxconn 1000
maxqueue 5000 ssl ca-file /etc/ssl/web.pem

This backend worked just fine until now, a quick wget on the server
also worked and openssl s_client reports the certificate of the
backend to be valid.

I couldn't find anything on the list except that the error would be
due to SSL_ABORT, but I'm not sure what this is supposed to tell
me...

Is there anything else for HAProxy/TLS that could be configured
wrong? How could I debug this issue when everything else reports the
handshake was successful?