RE: TLS Tickets and CPU usage

> Hey Olivier, > > Can you try the attached patch? I need to run some more tests, but I > think this should fix it. It definitely fixes the test case here. thanks, Lukas

RE: TLS Tickets and CPU usage

Hi Nenad, >> Well, its not supposed to look like this, there is clearly something >> wrong. Master key fluctuates between the requests with TLS tickets >> and the reuse collumn shows failure. > > Looks like a haproxy bug, I think I can reproduce it. > > Can you try with EXACTLY 3 keys in

RE: TLS Tickets and CPU usage

Hi Oliver, > 2016-03-24 17:12 GMT+01:00 Lukas Tribus > <luky...@hotmail.com<mailto:luky...@hotmail.com>>: > > If thats not it, and no old haproxy instances are present after the > > reload, could you compile Vincent's rfc5077-client from [1]: > >

RE: TLS Tickets and CPU usage

> If thats not it, and no old haproxy instances are present after the > reload, could you compile Vincent's rfc5077-client from [1]: > Output can be find here > : https://gist.github.com/anonymous/6ec7c863f497cfd849a4 > (HTTP 500 error is normal, as you are using HEAD / HTTP/1.0 and our web >

RE: src_get_gpc0 seems not to work after commit f71f6f6

Hi, >> As below, I use stick-table for temporary acl. >> After commit f71f6f6, src_get_gpc0 seems not to work. >> >> So, I revert commit f71f6f6, and it works!! > > That's not a valid commit in the official haproxy repo, can you please > check the hash again? Its a valid hash in the haproxy-1.6

RE: Weird stick-tables / peers behaviour

> 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. Possibly related to the

RE: TLS Tickets and CPU usage

> Ok, when you say CPU usage double do you mean the CPU usage after  > a reload/restart, or do you mean CPU usage in general (even after not  > reloading haproxy)?  > CPU is at 100% just after reload for more than 30s (was a few seconds  > before) and then CPU usage stays doubled all the time. 

RE: TLS Tickets and CPU usage

Hi Oliver, > 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

RE: listeners remaining after reload

Hi Larry, > Hi,  >  > HA-Proxy version 1.5.14  > Ubuntu 15.10  >  > I have had a look in the archives for this problem and it appears a few  > times, but I have an additional worry:  > When we have a number of sequential reloads happening, some old  > processes are left behind.  Please upgrade

RE: General SSL vs. non-SSL Performance

>> Hm, I haven't tried Apache yet but would that be a huge benefit compared >> to a setup using nbproc> 1? > > I haven't tried it either, but yes, I would assume so. To be more specific: the number of TLS handshakes would probably be similar, especially in a nbproc>1 configuration, but when you

RE: General SSL vs. non-SSL Performance

> The "option httpclose" was on purpose. Also the client could (during a > attack) simply do the same and achieve the same result. I don't think > that will help in such cases. So what you are actually and purposely benchmarking are SSL/TLS handshakes, because thats the bottleneck you are trying

RE: General SSL vs. non-SSL Performance

> Some customers may require 4096 bit keys as it seems to be much more > decent than 2048 nowadays. I've not come across any recommendations pointing in that direction, in fact 2048-bit RSA are supposed to be safe for commercial use until 2030. I don't think this is a real requirement from

RE: HAProxy -st not killing old processes

Hi Bowen, > Hi, > > We are using -p option to save the pid of HAProxy. When a new HAProxy > is received, we use -st pid option to reload HAProxy. > The issue we are having is that -st option sometimes does not kill the > old process.  Please upgrade to 1.5.16 or 1.6.4, there have been

RE: FreeBSD experiences.

> Hi, > > (Disclaimer: I don't mean to start a religious discussion!) > > Does anyone have any comparative experiences in running HAProxy on > Linux and FreeBSD? I'm especially interested in performance - in > particular CPU load. I don't have much experience with FreeBSD, and > have read

RE: SSL test crashing HAProxy

> Hi, > > I'm an admin for a software dev company. We host our software in the > AWS cloud, using HAProxy as an entry point to a private VPC. Our > HAProxy handles SSL. Recently, we've had an issue that we can reproduce > on multiple proxies. > We found that running the following test

RE: HAProxy no longer working on new ubuntu servers, config has not changes.

> I figured out what it was. When I create a DigitalOcean or AWS VM, it > is taking the hostname (I am naming it the same as what I am proxying) > and dumping it into the hosts file, with 127.0.0.1. I know this is out > of the scope of a normal setup, but would be cool to throw a warning. >

RE: HAProxy no longer working on new ubuntu servers, config has not changes.

> HAProxy is suddenly crashing on new Ubuntu (Digital Ocean, AWS - 14.04 > and 15.10) installs. I’ve had the same configuration working for over a > year now. I’ve posted all the logs and details below. Is there a new > bug, or should my configuration be changed to suit the new versions? > >

RE: Haproxy failing to start after VM move (Debian 8 [systemd])

> Hi Lukas, > > We're on 64 bit CPUs. I used: > TARGET=linux2628 CPU=generic USE_PCRE=1 > So, will this have compiled to 32bits (without using the ARCH=x86_64 option)? No, you won't cross-compile by mistake, don't worry. Its just not passing -march=x86-64 to gcc. Actually I'm unsure if its

RE: Client timeout expiring while waiting for server response

Hi, > Hi Cyril, > > I confirm the problem is fixed with the latest 1.5 snapshot. Do you > have an idea when I can expect the next 1.5 minor release to be > available? You could upgrade to 1.6.3 which is stable and contains this fix, but I do agree that we could drop a 1.5.16 (CC'ing Willy):

RE: Haproxy failing to start after VM move (Debian 8 [systemd])

> One last question. Would there be a performance benefit in > using CPU=i686 over CPU=generic? (I think I can be fairly sure that our > host will always expose Intel CPUs) If you are using 32bit CPU's, sure (doesn't have to be an Intel though). If you are using 64bit CPU's, use CPU=generic

RE: Haproxy failing to start after VM move (Debian 8 [systemd])

Hi SL, > ./haproxy -v > Illegal Instruction > > sudo/haproxy -v > [no output] > > Same thing if I try to check the config with -c -f (though I don't > think this is a config issue). > > Here's what I have in kern.log: > > Mar 7 11:41:41 rproxyws1 kernel: traps: haproxy[4031] trap

RE: Client timeout expiring while waiting for server response

Hi Francois, > Hi, > > I'm having an issue with the client timeout expiring unexpectedly. > > I am using haproxy v1.5.14 with the http-keep-alive option. > > In my use case, I have a client maintaining a long-lived connection > through haproxy to a backend server. The backend server sends back a

RE: SNI and haproxy backend selection.

> But can I use the SNI hostname to define which backend will haproxy use > and by that choose also between different protocol? Absolutely! http://blog.haproxy.com/2012/04/13/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/ Lukas

RE: RFC: Statically enable SSL_OP_SINGLE_DH_USE

>> I don't see it. Can you please elaborate what exact commit ID your are >> refering to? > > You are probably refering to the github fork, which is as always outdated, > and where line 2539 points to the local definition of SSL_OP_SINGLE_DH_USE: > #ifndef SSL_OP_SINGLE_ECDH_USE > #define

RE: RFC: Statically enable SSL_OP_SINGLE_DH_USE

>> In HAProxy, this flag is currently statically disabled by default in >> src/ssl_sock.c line 2539. Thus, when used with older OpenSSL versions >> than 1.0.1r or 1.0.2f, users could be vulnerable. > > I don't see it. Can you please elaborate what exact commit ID your are > refering to? You are

RE: RFC: Statically enable SSL_OP_SINGLE_DH_USE

> In HAProxy, this flag is currently statically disabled by default in > src/ssl_sock.c line 2539. Thus, when used with older OpenSSL versions > than 1.0.1r or 1.0.2f, users could be vulnerable. I don't see it. Can you please elaborate what exact commit ID your are refering to? As far as I an

RE: cookie prefix & option httpclose

> Now I did the same setup with version 1.5 and found out that even > without "option httpclose" both requests have the cookie prefixed. > > My dillema - are the docs inconsistent and this section should be > removed or am I missing something ? Docs are inconsistens both 1.5 and 1.6 for this.

[PATCH] DOC: remove old tunnel mode assumptions

Michał Pasierb reported doc inconsistencies regarding the old default HTTP tunnel mode. This patch fixes a few of those inconsistencies and should be backported to both 1.6 and 1.5. --- doc/configuration.txt | 28 1 file changed, 12 insertions(+), 16 deletions(-)

RE: [PATCH] DOC: remove old tunnel mode assumptions

Hi Willy, >> This patch fixes a few of those inconsistencies and should be backported >> to both 1.6 and 1.5. > > Applied to 1.7-dev, thanks! thanks. A minor cosmetic glitch: seems that something broke non-ascii characters, I can see it in this commit here and also in Cyril's latest patch,

RE: opened port twice

> so, i had the 443 port opened "twice". and in a roundrobin fashion, it > redirected me to one listening server or the other. and one of them was > binded to port 443 without any ssl configuration, so from time to time > i received an http plain response over 443 port. > > i already know

RE: SSL acceleration

> Now this is where I probably look stupid but... > > Am I correct in stating that the AES-NI is only really useful for file > encryption... and bugger all use for HTTPS/SSL encryption (which is > what we really want)? No, AES-NI is very useful for the symmetric part of HTTPS/TLS when using AES

RE: Either ACL result is inconsistent or http-server-close isn't working

Hi Gustavo, > Below is my haproxy.cfg:  We will need to know the exact release you are using, because they have different defaults. Regards, Lukas

RE: Either ACL result is inconsistent or http-server-close isn't working

Hi Gustavo, > I compiled 1.6.3 from source with the options: TARGET=custom USE_PCRE=1 > USE_LINUX_SPLICE=1 USE_LINUX_TPROXY=1 USE_OPENSSL=yes Unless you have a kernel older than 2.6.28, just use the linux2628 target: TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 This will enable all current

RE: Force client IP with PROXY protocol

>> If you can't use layer 7 features then you can't access the >> CF-Connecting-IP header in nginx. > > ...HAProxy, not Nginx, no ? Yes, I mixed that up, haproxy was what I meant. > Otherwise that would be nice to be able pass client IP address as an > argument to send-proxy directive. >

RE: Force client IP with PROXY protocol

> Maybe it would be a nice idea to add something like. > > proxy-protocol set-src hdr(CF-Connecting-IP) > > Opinions about this? Doesn't: http-request set-src hdr(CF-Connecting-IP) in combination with a standard proxy-protocol config already do that? Lukas

RE: Force client IP with PROXY protocol

> I use TCP mode, so I can't use layer 7 features. If you can't use layer 7 features then you can't access the CF-Connecting-IP header in nginx. I would suggest: - leave the haproxy configuration as is (using proxy protocol towards    nginx) - configure nginx to respect the CF-Connecting-IP

[PATCH] MINOR: unix: don't mention free ports on EAGAIN

When a connect() to a unix socket returns EAGAIN we talk about "no free ports" in the error/debug message, which only makes sense when using TCP. Explain connect() failure and suggest troubleshooting server backlog size. --- src/proto_uxst.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

RE: [PATCH] Add compatibility with OpenSSL 1.1.x

Hi Remi! > Date: Thu, 23 Jul 2015 16:58:51 +0200 > > Hi, > > A while back, Lukas Tribus mentioned that HAproxy used quite a few > OpenSSL internals that were not going to be usable in the 1.1.x branch, > and that we would better take a look at it. another half year l

RE: [PATCH] Add compatibility with OpenSSL 1.1.x

Hi Remi! (previous mail got messed up be the mailer again, sorry about that) > Date: Thu, 23 Jul 2015 16:58:51 +0200 > > Hi, > > A while back, Lukas Tribus mentioned that HAproxy used quite a few > OpenSSL internals that were not going to be usable in the 1.1.x branch, &

RE: Haproxy cannot return 404

Hi Jayson, > I used haproxy as a http loadbalancer, I want to return a 404 > response from the backend server.But haproxy is always hanging.  Haproxy transparently passes those responses to the client. > My backend server only returns a ASP.NET 5 Httpnotfound when > requests a wrong url.

RE: one line 'and' acl

> Hi, > > I'm matching sslv2 client hello message with these 2 ACL (!= req.ssl_ver 2) > > acl ssl2-1 payload(0,1) -m bin 80 > acl ssl2-2 payload(2,1) -m bin 01 > use_backend bk2 if ssl2-1 ssl2-2 > > Is it possible to do it with 1 ACL ? Shouldn't: acl ssl2 payload(0,2) -m bin 8001 just

RE: HAProxy is not able to bind

>> That fact that epoll() is not here however tells us that haproxy >> was build with the generic build target, instead of linux2628. >> >> You should fix this (append TARGET=linux2628 to make), so that >> haproxy can use epoll() among (a lot of) other important features. > > Ah, thank you! I will

RE: http/2 - missing something ...

> It would let me log in successfully, and the blog itself > still worked, but then it told me I didn't have permission to access the > admin page. There is no specific configuration about /wp-admin/ in neither haproxy nor the backend http server, right? Like a matching ACL, location declaration

RE: http/2 - missing something ...

> There is nothing for the wp-admin path in the config files for haproxy, > wordpress, or Apache. I am not aware of anything special in the > wordpress database either. > > I've always pursued using SSL for the entire site, not just login and > admin. Trying to limit it to part of the site seems

RE: HAProxy is not able to bind

Hi David, > The warning about select() not working is a little strange, but it > seems like it's falling back to poll(), which should be fine. Actually its not "falling back" to poll(), select() is the slowest and least preferred of them all. That fact that epoll() is not here however tells us

RE: http/2 - missing something ...

Hi, > Since 1.6, HAProxy supports sni on the server side, using a fetch. Oh, thanks, that must have slipped through the cracks :) > Folks, > > Sorry for offtopic, but I am observing more or less same situation with > nginx. > My HTTP/2 configuration works when frontend/backend are

RE: http/2 - missing something ...

Hi Marc, > server web2 119.81.152.73:443 weight 1 maxconn 30 check ssl verify none Apache expects that the TLS client negotiates h2 via ALPN, but the TLS client in this case is haproxy, so this won't work. You have to disable TLS on the backend und go unencrypted. nginx and jetty can do

RE: SSL backend with ssl passthrough and client cert

> Hi > > I am trying to set up haproxy with tcp mode for passing through ssl > connection. But i want to check my backend health with http call. > My backend requiers the use of a client key. > > I tried something like this: > option httpchk GET /status HTTP/1.0\r\nHost:\ localhost >

RE: SSL backend with ssl passthrough and client cert

Hi, > In the client.pem file i put the servers certificate and the client > private key, do i need to put the client certificate also in that file? You *don't* put the server certificate in that file at all. Its wrong to do so and it will never work that way. You put: - the client certificate

RE: SSL backend with ssl passthrough and client cert

Hi Idar, > If i put my client-key in client.pem then i get this error: unable to  > load ssl certificate from PEM file  The crt keyword [1] in the backend configuration expects both the client certificate and the corresponding (client-cert) private-key. > When i use my java client i only

RE: question haproxy 1.5

> Hi Lukas, > > We try : > bind :443 ssl crt /etc/ssl/ : it's doesn't work Can you elaborate what it doesn't work mean? Does haproxy refuse to start with an error? If so, please post the exact error message. Also post the output of haproxy -vv and confirm that you are starting haproxy with root

RE: haproxy memory segfault

Hi, > Dec 8 03:06:04 haproxy01 kernel: haproxy[1549]: segfault at > 7f16a96c8012 ip 0046aa8d sp 7fff714c7c30 error 4 in > haproxy[40+aa000] > > Dec 8 04:59:17 haproxy01 kernel: haproxy[1710]: segfault at > 7f154266a012 ip 0046aa8d sp 7fffcf353db0 error 4 in >

RE: problems with TLS offload using HaProxy & TLS VPN (ocserv, ~ Cisco VPN)

Hi Eugene, > Hello, > > we have a problems with TLS offload using HaProxy & TLS VPN (ocserv, ~ Cisco > VPN). > > [...] > > It happens at first connection after ~ 30-50 packets. > Everything is OK if we switch off TLS offload (haproxy TCP mode & server > "localhost:4443"). You are doing 2

RE: SSL handshake failure when using "send-proxy" on HTTPS backend

> Both listen directives on port 8443 uses SSL. > With Nginx, listening options must be specified on only one "listen" > directive for each address:port combination. > > So the "listen 10.0.80.1:8443" directive inherit parameters from > "listen 10.0.80.1:8443 default_server ssl proxy_protocol"

RE: SSL handshake failure when using "send-proxy" on HTTPS backend

> 2015-12-04 16:27 GMT+01:00 Jonathan Leroy - Inikup : >> Hi Luke, >> >> Here's the Nginx config : >> https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt > > Now that I use ULA instead of link-local

RE: Error when using an IPv6 link-local address as backend

> Hi, > > All my backend servers are connected to a private, IPv6-only network. > When I'm trying to use their addresses in "server" directive, HAProxy > fails to connect to them. I would strongly suggest to avoid link-local addresses for any services and applications. If you need to keep this

RE: Get haproxy to listen only on the public IP

Hi Unkown User! > Is there any way to get haproxy to listen only on the public IP, other  > than by specifying the IP?  > I dont want this to listen on the loopback.  Use the interface keyword: http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-interface Regards, Lukas

RE: SSLv2Hello is disabled

Hi, > I'll try to pack again the OpenSSL files (must work with rpm) from > original repository and will let you know. Thanks. Ok, but first try the other proposal (takes less time): >> Should I just add to haproxy.cfg the following? >> force-tlsv10 > > Yes, you can try: > > global >

RE: SEGFAULT in in buffer_insert_line2

Hi Bernd, Willy, > Hello, > > im getting segfault, it happens on 1 of ~500 million requests that are > processed on haproxy 1.6.2-2 on debian wheezy and jessie (systems > updated, crash stayed). > > If you need more informations, let me know. > > Thank You. > > Trace: > (gdb) thread apply all bt

RE: SSLv2Hello is disabled

Hi Galit, > I want to emphasize that the following test succeeded: > > [root@proxy-au51 ~]# openssl s_client -connect 10.106.75.53:50443 -tls1 > > CONNECTED(0003)  Ok. > Built with OpenSSL version : OpenSSL 0.9.8b 04 May 2006 > Running on OpenSSL version : OpenSSL 0.9.8e-fips-rhel5

RE: haproxy doesn't get SIGUSR1

> I'm using service_loadbalancer from kubernetes > (https://github.com/kubernetes/contrib/tree/master/service-loadbalancer ) > . This program would re-spawn haproxy when it found a change of > upstream endpoints. > When service_loadbalancer starts, it runs haproxy -sf $(cat pidfile) > several

RE: SSLv2Hello is disabled

javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled  >>> You need to disable SSLv3 in haproxy  >>  >> We are talking about the SSLv2 hello format. Its not about SSLv2 >> or SSLv3, its about the hello format.  > Which can also be used by sslv3 clients hence my comment.  True, but

RE: SSLv2Hello is disabled

> On 02/12/2015 12:41 AM, "Cohen Galit" > > wrote: > > > > Hello, > > > > > > > > When HAProxy 1.5.9 is trying to sample our servers with this > configuration: tcp-check connect port 50443 ssl > > > > > > > > Our servers returns an

RE: Haproxy stats page returns 503 error

Hi Atul, > Hi, > > > using a browser to query the stats from haproxy, I'm facing a non > consistent behavior where about One time every 2 attempts I get a 503 > error. Please share the configuration so we can take a look. Regards, Lukas

RE: Owncloud through Haproxy makes upload not possible

> I'm not sure now, but it seems that packets routed in Haproxy are > somehow protected from dumping: > root@owncloud:~ # tcpdump -i em1 -vv port 80 > tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size > 10 bytes > ^C > 0 packets captured > 3774 packets received by filter > 0

RE: Owncloud through Haproxy makes upload not possible

> No, I have checked both lo0 and lo1 (I have lo1 set up for jails). Can you try outside of the jail? Somehow it must be possible to tcpdump this traffic. Lukas

RE: Owncloud through Haproxy makes upload not possible

> I'm not sure why, but after doing haproxy -vv I now get kevent() in > truss output. I'm attaching another truss output. Ok, so thats not the problem, good. > While browsing the logs I've notices that besides the usual 200 > output, when uploading was > finished (unsuccessfully) I got the

[PATCH] BUG/MINOR: lua: don't force-sslv3 LUA's SSL socket

Sander Klein reported an error messages about SSLv3 not being supported on Debian 8, although he didn't force-sslv3. Vincent Bernat tracked this down to the LUA initialization, which actually does force-sslv3. This patch removes force-sslv3 from the LUA initialization, so the LUA SSL socket can

RE: ssl parameters ignored

Hi, >> root@debianvm:/home/lukas/haproxy-1.6.2# haproxy -f /home/lukas/ssl.cfg -c >> [ALERT] 328/203304 (9873) : SSLv3 support requested but unavailable. >> Configuration file is valid >> root@debianvm:/home/lukas/haproxy-1.6.2# ./haproxy -f /home/lukas/ssl.cfg -c >> Configuration file is valid

RE: ssl parameters ignored

Hi, >> I don't know. I got pre made packages from "http://haproxy.debian.net >> jessie-backports-1.6 main" maintained by Vincent Bernat if I'm correct. > > I think there's something wrong with that binary. I will try to reproduce > the problem with it. Confirmed. The 1.6.2 binary (haproxy)

RE: ssl parameters ignored

> On 2015-11-23 22:36, Lukas Tribus wrote: >> Are you sure that the executable was cleanly build (first "make clean", >> only then "make ...")? > > I don't know. I got pre made packages from "http://haproxy.debian.net > jessie-backports-1.6 main

Re: ssl parameters ignored

Hi Sander, > When testing this config I get: > > [ALERT] 326/202736 (24201) : SSLv3 support requested but unavailable. > Configuration file is valid > > After testing with ssllabs I also noticed tlsv10 and tlsv11 were still > enabled. Downgrading to haproxy 1.5.14 removes the error when testing

RE: Owncloud through Haproxy makes upload not possible

Hi, >> Still seeing poll() in this trace. Are you sure nokqueue was removed >> in the configuration and haproxy was restarted? > Yes, I definitely did that. > [...] > Total: 3 (3 usable), will use kqueue. I don't get it. The trace doesn't match the configuration. When you start haproxy with

RE: Owncloud through Haproxy makes upload not possible

>> Ok, could you redo this trace with the "-d" option and >> without the nokqueue configuration. > Attached. Still seeing poll() in this trace. Are you sure nokqueue was removed in the configuration and haproxy was restarted? Please also provide the output of "haproxy -vv". Thanks, Lukas

RE: ssl parameters ignored

Hi, > When testing this config I get: > > [ALERT] 326/202736 (24201) : SSLv3 support requested but unavailable. > Configuration file is valid > > After testing with ssllabs I also noticed tlsv10 and tlsv11 were still > enabled. Downgrading to haproxy 1.5.14 removes the error when testing > the

RE: Owncloud through Haproxy makes upload not possible

Hi Piotr, >> - try nokqueue mode [1] > Didn't change anything. >> - try option http-no-delay [2] > Didn't change anything. Ok, please remove both options again. >> - check cpu usage (system and haproxy) while uploading > Load average is about 0.2-0.4 What we have to find out is if haproxy

RE: CPU 100% when waiting for the client timeout

> Hi Willy,  >  >> This one seems to have missed 3 years of bugfixes  > I've just done a "apt-get update && apt-get upgrade" successfully and  > reboot the machine this week. I think the OS is fresh enough, but I'll  > try to upgrade the kernal to a newer one. :-)  When you upgrade Ubuntu precise

RE: [SPAM] Re: CPU 100% when waiting for the client timeout

> I think the right way to upgrade kernel with ubuntu, is: > > apt-get update && apt-get dist-upgrade Exactly, apt may hold back kernel upgrades otherwise. Lukas

RE: CPU 100% when waiting for the client timeout

>> # uname -a >> Linux WD-G0-SRP1 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC >> 2012 x86_64 x86_64 x86_64 GNU/Linux > > This one seems to have missed 3 years of bugfixes but anyway I don't see > how any kernel bug could make haproxy fail, and if it did we'd have to > find a

RE: Connect() failed using unix sockets

Hi Greg, > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. > Connect() failed for backend frontend: no free ports. >

RE: Connect() failed using unix sockets

>> >> So anybody know what resource "free ports" relates to in the unix >> domain socket case? Are there any other debug options to find out >> more about what is happening. > > I suspect the connect() call returns EAGAIN Digging some more, it looks like the kernel returns EAGAIN when the backlog

RE: Owncloud through Haproxy makes upload not possible

Hi Piotr, > Unfortunately, using 1.5.15 didn't change anything. a few things I would suggest to try/troubleshoot: - try nokqueue mode [1] - try option http-no-delay [2] - check cpu usage (system and haproxy) while uploading - truss ([3]) haproxy while uploading - tcpdump the frontend

RE: CPU 100% when waiting for the client timeout

Hello! > Sorry for send it again, I just forgot to provide the attachments. > > Affect verions: at least 1.5.15 and 1.6.2 > > Here is the related part in my configuration: > timeout client 15m # 客户端响应超时 > timeout client-fin 10s # 对客户端连接完成 TCP 4 次挥手超时 > timeout connect 5s # HAProxy 向后端

RE: Haproxy

> Howover, Can you send me some sample haproxy.cfg configuration file for  > Solaris 11. Sample configurations are already bundled with haproxy, check the folder examples/ Of course, the those configurations will not work out of the box for your specific requirements. You will have to understand

RE: Haproxy on solaris 11

Hi Roja, > Hi, > > We need to install Haproxy on Solaris 11 sparc. > > I have downloaded from haproxy.org and taken example of sample > configuration file haproxy.cfg. > > I am getting the error while compiling the code.  You are not compiling the code. You are starting haproxy here.

RE: Haproxy on solaris 11

> Hi Lukas, > > Sorry for that. I am not a operating system engineer. Than I suggest a commercial product with commercial support, like those from haproxy.com. I'm afraid its not possible to provide support for basic operating system tasks on this list (like understanding the presence or absence

RE: Fast reloads leave orphaned processes on systemd based systems

Hi Lukas, > When reloading haproxy too fast on EL7 (RedHat, CentOS) the system is > being filled with orphaned processes. > > I encountered this problem on CentOS 7 with > haproxy-1.5.4-4.el7_1.x86_64 but expect it to exist on all systems > using haproxy-systemd-wrapper not just those based on

RE: Fast reloads leave orphaned processes on systemd based systems

Hi Lukas, > When reloading haproxy too fast on EL7 (RedHat, CentOS) the system is > being filled with orphaned processes. > > I encountered this problem on CentOS 7 with > haproxy-1.5.4-4.el7_1.x86_64 but expect it to exist on all systems > using haproxy-systemd-wrapper not just those based on

RE: Haproxy 1.6 Ldap frontend/backend Segfault

> Hi > > I am testing out the new 1.6 Haproxy and everything works great except > when I try to use it for balancing LDAP traffic in mode tcp. It seems > to segfault after doing an initial connection. Below is the > information, please let me know if I can get you any other information. >

[PATCH v2] BUG/MINOR: acl: don't use record layer in req_ssl_ver

The initial record layer version in a SSL handshake may be set to TLSv1.0 or similar for compatibility reasons, this is allowed as per RFC5246 Appendix E.1 [1]. Some implementations are Openssl [2] and NSS [3]. A related issue has been fixed some time ago in commit 57d229747 ("BUG/MINOR: acl:

RE: [PATCH v2] BUG/MINOR: acl: don't use record layer in req_ssl_ver

>> This should be backported to stable series, the req_ssl_ver keyword was >> first introduced in 1.3.16. > > Thanks Lukas, applied to 1.7, 1.6, 1.5 and 1.4. For 1.3 there might be > other patches pending so this one will get there at the same time. Great. I didn't really expect a 1.3 backport,

[PATCH] BUG/MINOR: acl: don't use record layer in req_ssl_ver

The initial record layer version in a SSL handshake may be set to TLSv1.0 or similar for compatibility reasons, this is allowed as per RFC5246 Appendix E.1 [1]. Some implementations are Openssl [2] and NSS [3]. A related issue has been fixed some time ago in commit 57d229747 ("BUG/MINOR: acl:

RE: [PATCH] BUG/MINOR: acl: don't use record layer in req_ssl_ver

>> @@ -402,7 +402,7 @@ smp_fetch_req_ssl_ver(const struct arg *args, struct >> sample *smp, const char *kw >> if (bleft < 5) >> goto too_short; >> >> - version = (data[1] << 16) + data[2]; /* version: major, minor */ >> + version = (data[9] << 16) + data[10]; /* client hello version: major, >>

RE: Potential Bug

> I believe I may have discovered a bug in HAProxy 1.5.4 on CentOS 7.1, > installed via standard repositories. > > I don't want to go into debugging levels of detail here, but instead > will provide a synopsis in the hopes someone knows of a bug already or > can confirm it warrants further

RE: DNS resolution problem on 1.6.1-1ppa1~trusty

> I sent patches to Willy, and they have been integrated a few minutes ago. > You can git pull ; make clean ; make [...] Unless you use haproxy-1.6, in that case you have to wait for the backport and the git push, which has not happened yet. Lukas

RE: HA Proxy - packet capture functionality

> If Haproxy doesn't terminate the encryption there is nothing you can do in > any case. > If it does, you can listen for the unencrypted traffic going between haproxy > and the > backend using tcpdump with appropriate filtering as well. Also, if you for whatever reason need to decrypt the

RE: Wrong mode for SSL termination in config

> We use HAProxy as our loadbalancer in our private cloud at Symantec. We > spin these HAProxy processes in a separate network namespaces. We had a > bug in our HAProxy config population script which was adding wrong mode > in frontend and backbend sections for SSL termination. The right

RE: Wrong mode for SSL termination in config

>> Can somebody help us get more understanding as to what are the >> implications of adding wrong mode in config file and why this could >> cause a kernel panic if at all. > > There is no reason whatsoever that this should have caused a kernel > panic. zero. nada. None at all. Meaning: if haproxy

RE: no free ports && tcp_timestamps

> Hi, > > I checked kernel log and I can't find anything. How do I procede? Ask kernel folks. Or don't disable tcp_timestamps, a lot of important TCP features rely on it and those "security reasons" are ridiculous anyway. Uptime is not supposed to be a secret, if someone can attack you based on

RE: [PATCH] MEDIUM: dns: Don't use the ANY query type

>> Baptiste, whats the current behavior when an empty response with >> NOERROR is received? >> >> Regards, >> >> Lukas > > > Hi, > > This is already handled when I detect response without NX code and no > response records (DNS_RESP_ANCOUNT_ZERO) or no response record > corresponding to the query

<    3   4   5   6   7   8   9   10   11   12   >