Signed-off-by: Adam Spiers aspi...@suse.com
---
examples/haproxy.init | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/examples/haproxy.init b/examples/haproxy.init
index ae3ac0f..938721c 100644
--- a/examples/haproxy.init
+++ b/examples/haproxy.init
@@ -32,20
Hi all! I'm new to the haproxy developer community so this is my
first patch series - hope it fits the format you need.
This is a very simple set of changes to the init script: mostly
refactoring, but one minor fix.
Regards,
Adam
P.S. Hi again Willy ;-) We met at the last OpenStack summit in
Signed-off-by: Adam Spiers aspi...@suse.com
---
examples/haproxy.init | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/examples/haproxy.init b/examples/haproxy.init
index 938721c..2bed3eb 100644
--- a/examples/haproxy.init
+++ b/examples/haproxy.init
@@ -37,6 +37,8 @@
Signed-off-by: Adam Spiers aspi...@suse.com
---
examples/haproxy.init | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/examples/haproxy.init b/examples/haproxy.init
index 942d959..ae3ac0f 100644
--- a/examples/haproxy.init
+++ b/examples/haproxy.init
@@ -32,19
Signed-off-by: Adam Spiers aspi...@suse.com
---
examples/haproxy.init | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/examples/haproxy.init b/examples/haproxy.init
index 67268eb..bf13b15 100644
--- a/examples/haproxy.init
+++ b/examples/haproxy.init
@@ -43,7 +43,7
If haproxy is not already running, reload should not start it.
Unfortunately the LSB spec does not explicitly cover this case:
http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
but it seems like the more correct behaviour, and actually fixes a
Signed-off-by: Adam Spiers aspi...@suse.com
---
examples/haproxy.init | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/examples/haproxy.init b/examples/haproxy.init
index 2bed3eb..67268eb 100644
--- a/examples/haproxy.init
+++ b/examples/haproxy.init
@@ -38,6 +38,7 @@
I'm not currently sure on the JRE version. These are Android clients
written with a old Android SDK. All new clients are C++ / OpenSSL
based.
I have set the DH param size to 1024 with the same results.
Additionally, I set up a bind statement that reflects that of the
backward compatibility link
Hi Adam!
On Mon, Feb 23, 2015 at 03:28:35PM +, Adam Spiers wrote:
Hi all! I'm new to the haproxy developer community so this is my
first patch series - hope it fits the format you need.
This is a very simple set of changes to the init script: mostly
refactoring, but one minor fix.
Alexandre Turpault
Pour être sûr(e) de recevoir toutes nos invitations, ajoutez
l'adresse suivante : newslet...@alexandre-turpault.com
Si ce message ne s'affiche pas correctement, rendez-vous à
cette adresse :
I have since set DH to 1024 in my configuration. Here is the results
from cipherscan:
Target: 10.3.2.74:443
prio ciphersuite protocols pfs_keysize
1 AES128-SHA TLSv1,TLSv1.1,TLSv1.2
2 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,1024bits
Certificate:
Thanks for updating the subject -- this does seem to be SSL/handshake
related. I'm pretty confident that these are just bad clients that
were getting away with whatever they're doing on the old Mochiweb SSL
setup. As a last resort we're coming up with a backup plan on routing
them to the old setup
Attached is a pcap with the bind line cut+paste from your link.
In this case I see Encrypted Alert, but I'm struggling to decrypt it
in WS with this setup.
Ok, so as expected, this didn't really change anything, but at least
we have a config/capture consistency.
Now, it looks like the client
The TLS handshake is working fine. The issue is that HAProxy is trying
to speak SPDY
with your clients, and they most likely don't support it.
In the Haproxy_1 capture, look at packet #61 send by haproxy to the
client. The application
data protocol is set to SPDY. Is this the expected behavior
We do not expect SPDY to be used, no. The expected behavior is HTTP on
TLS with JSON-RPC payloads (POST/response body).
Perhaps I'm not reading something right here: Looking at #61 in
Wireshark, I see the following:
61 16.127749 10.3.2.74 10.1.1.93 TLSv1 279 Application Data
TLSv1 Record Layer:
Hi,
I'm not currently sure on the JRE version. These are Android clients
written with a old Android SDK. All new clients are C++ / OpenSSL
based.
I have set the DH param size to 1024 with the same results.
Additionally, I set up a bind statement that reflects that of the
backward
Do you use any reqrep/resprep rules? I'm asking because I had the same kind
of problem, also with java apps.
First I changed the global section to:
tune.ssl.default-dh-param 1024
ssl-default-bind-ciphers
EECDH+aRSA+AES:kRSA+AES:+AES256:RC4-SHA:!kEDH:!LOW:!EXP:!MD5:!aNULL:!eNULL
Attached is a pcap with the bind line cut+paste from your link.
In this case I see Encrypted Alert, but I'm struggling to decrypt it
in WS with this setup.
On Mon, Feb 23, 2015 at 11:36 AM, Lukas Tribus luky...@hotmail.com wrote:
There's some confusion here.
For the sake of clarity, please,
A bit late to this discussion but the issues sound familiar.
I've seen this type of issue in the past between openssl and java's ssl
implementation, primarily in java 6 and java 7. I don't remember the
full details but from what I recall avoiding the EC based ciphers from
the supported list
On 23/02/2015 10:55 μμ, NuSkooler wrote:
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a successful connection + POST to the
original Mochiweb server. Note that here the port is 8443 not 443
(IP=10.3.3.3)
* ha_self_signed.pcap:
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a successful connection + POST to the
original Mochiweb server. Note that here the port is 8443 not 443
(IP=10.3.3.3)
* ha_self_signed.pcap: Failed attempt against HAProxy with a self
Title: Aquality-201501-special2015
Cliquez ici pour lire cet e-mail dans votre navigateur.
Hi, I have found that the problem only occurs when you use a CMS like
Drupal and Wordpress, I found the solution force both to use https, in
the case of Drupal editing sites/default/settings.php uncomment the line:
$base_url = 'https://domain_name_blablabla';
In the case of Wordpress it's
Hi all,
I'm only reposting below Lukas' mail without mixed text/plain
Content-Type and html inside, in case someone couldn't read it ;-)
Le 24/02/2015 01:04, Lukas Tribus a écrit :
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a
gt; Attached is the information you requested -- and hopefully
performedbrgt; correctly :)brgt;brgt; * no_haproxy.pcap: This is a
successful connection + POST to thebrgt; original Mochiweb server. Note that
here the port is 8443 not 443brgt; (IP=10.3.3.3)brgt; *
ha_self_signed.pcap: Failed
I apologize, the email was destroyed by the mailer...
Attached is the information you requested -- and hopefully performed
correctly :)
* no_haproxy.pcap: This is a successful connection + POST to the
original Mochiweb server. Note that here the port is 8443 not 443
(IP=10.3.3.3)
*
Hi guys,
A colleague just found an issue last night, where this acl:
acl is_kk-dk hdr_end(host) -i kkdk3.testkkdk.kk.dk hdr(host) -i
readonly.kk.dk hdr(host) -i readonly.testkkdk.kk.dk hdr(host) -i
www.testkkdk.kk.dk hdr(host) -i kktest.kk.dk hdr(host) -i www.kk.dk
hdr(host) -i kk.dk
27 matches
Mail list logo