Re: Rpm for Haproxy 2.0
On Wed, Nov 13, 2019 at 12:51:05PM -0500, N Seto wrote: >Hi, >We are looking for the official / reputable RPM for haproxy v 2.0  . > Can you suggest where we can obtain this? > Fedora 31 ships haproxy 2.0.x rpms. https://koji.fedoraproject.org/koji/packageinfo?packageID=5025 -- Pasi
Re: segmentation fault on 1.8.21
Hi, On Sat, Aug 24, 2019 at 06:58:45AM +0200, Willy Tarreau wrote: > On Fri, Aug 23, 2019 at 08:34:02PM -0300, Joao Morais wrote: > > > I've now backported all the pending patches for 1.8. You can git-pull > > > it if it's easier for you. > > > > Hi Willy, current 1.8 code (commit dcb8c97) fixes the issue we found on > > spoe, > > thanks! > > Perfect, thanks for confirming! I'm not going to issue another 1.8 yet with > just some minor issues though, we'll wait a bit for other fixes to accumulate. > ..as that bug in 1.8.21 causes segfault(s) with SPOE, it would indeed be nice to have 1.8.22 soon.. Thanks, -- Pasi > Cheers, > Willy >
Re: Connect to SNI-only server (haproxy as a client)
On Fri, Oct 10, 2014 at 07:21:04AM +0200, Willy Tarreau wrote: Hello Eugene, On Fri, Oct 10, 2014 at 08:13:43AM +0300, Eugene Istomin wrote: Hello, yesterday we are looking for the client-side SNI custom string for one of our clients and choose stunnel (as outbound TLS termination) for two reasons: 1) ability to send client certificate (client mode) 2) ability to send custom SNI header in client mode We use haproxy as main L7 routers for years with a little bit of stunnel for client cert auth. Do you have any plans to add this features in 1.6? It is already possible to send the client certificate, you just have to specify crt cert on the server line. There are some ongoing discussions about SNI. We all want to have it but want to ensure we're doing it correctly. Most users want to have a dynamic one, at least being able to retrieve the one from the other side, and possibly extract it from a Host header. And of course also from a static string. We're just trying to find the best way to configure this so that it's easy for all users. I personally think that a sample expression would be appropriate, just as for the usesrc keyword (which is currently limited). I'd rather avoid the ugly logformat string at this point since I don't think we need this complexity. If you have any opinion on the subject, please voice in! Hey, As long as the client side SNI is dynamic/configurable, I'm happy. All the scenarios you described above are valid (retrieve from the other side, extract from Host header, static string). Best regards, Willy Thanks, -- Pasi
Re: Connect to SNI-only server (haproxy as a client)
On Mon, Aug 18, 2014 at 05:46:14PM +0200, Baptiste wrote: On Mon, Aug 18, 2014 at 2:40 PM, Willy Tarreau w...@1wt.eu wrote: Hi Benedikt, On Mon, Aug 18, 2014 at 10:17:02AM +0200, Benedikt Fraunhofer wrote: Hello List, I'm trying to help an java6-app that can't connect to a server which seems to support SNI-only. I thought I could just add some frontend and backend stancas and include the sni-only server as a server in the backend-section like so: server a 1.2.3.4:443 ssl verify none force-tlsv12 (I had verify set, just removed it to keep it simple and rule it out) But it seems the server in question insists on SNI, whatever force-* I use and the connection is tcp-reset by the server (a) right after the Client-Hello from haproxy. Is there a way to specify the TLS SNI field haproxy should use for these outgoing connections? Not yet. We identified multiple needs for this field which a single constant in the configuration will not solve. While some users will only need a constant value (which seems to be your case), others need to forward the SNI they got on the other side, or to build one from a Host header field. So it's likely that we'll end up with a sample expression instead of a constant. Additionally that means that for health checks we need an extra setting (likely a constant this time). But for now, the whole solution is not designed yet, let alone implented. Btw is this something you're actively looking at, to design/implement? People on the list should be able to provide feedback about the planned expression to set the SNI field for client connections.. regards, Willy Hi, Microsoft Lync seems to have the same requirement for SNI... We need it in both traffic and health checks. OK, good to know. Thanks, -- Pasi Baptiste
Re: Haproxy support for passing HTTP CONNECT requests directly to the backend
On Tue, Apr 23, 2013 at 07:50:56AM +0200, Willy Tarreau wrote: Hi, On Tue, Apr 23, 2013 at 05:29:26AM +0300, Pasi Kärkkäinen wrote: Hello, Is it currently possible to pass HTTP CONNECT requests directly to the backend server? So haproxy itself shouldn't try to connect anywhere, but instead directly pass the request to the backend, and let backend handle it. Not only it is possible, but it is the only thing it can do :-) Keep in mind that haproxy is a reverse-proxy and not a proxy, so it will not try to resolve a host to connect to a specific location for example. Thus, if it receives a request such as CONNECT foo:443 HTTP/1.1, it will not try to resolved foo, it will send it to one of the servers declared in the backend. And it is the same for all methods, there is nothing specific to CONNECT. Hmm, I remember trying it earlier (a couple of years ago), and then it didn't work.. I'll have to try it again! Thanks a lot, -- Pasi
Re: Haproxy support for passing HTTP CONNECT requests directly to the backend
On Tue, Apr 23, 2013 at 04:10:55PM +0200, Willy Tarreau wrote: On Tue, Apr 23, 2013 at 04:30:12PM +0300, Pasi Kärkkäinen wrote: On Tue, Apr 23, 2013 at 07:50:56AM +0200, Willy Tarreau wrote: Hi, On Tue, Apr 23, 2013 at 05:29:26AM +0300, Pasi Kärkkäinen wrote: Hello, Is it currently possible to pass HTTP CONNECT requests directly to the backend server? So haproxy itself shouldn't try to connect anywhere, but instead directly pass the request to the backend, and let backend handle it. Not only it is possible, but it is the only thing it can do :-) Keep in mind that haproxy is a reverse-proxy and not a proxy, so it will not try to resolve a host to connect to a specific location for example. Thus, if it receives a request such as CONNECT foo:443 HTTP/1.1, it will not try to resolved foo, it will send it to one of the servers declared in the backend. And it is the same for all methods, there is nothing specific to CONNECT. Hmm, I remember trying it earlier (a couple of years ago), and then it didn't work.. There is no reason. It's been used since maybe version 1.1 (10 years ago) in front of proxies where this was already working. So if you see any failure, please report ! Ok, will do. -- Pasi
Haproxy support for passing HTTP CONNECT requests directly to the backend
Hello, Is it currently possible to pass HTTP CONNECT requests directly to the backend server? So haproxy itself shouldn't try to connect anywhere, but instead directly pass the request to the backend, and let backend handle it. I know this can be achieved in TCP/raw mode (obviously), but sometimes you'd also need it in http mode.. Thanks, -- Pasi
Re: [PATCH] Add OpenSSL engine support
On Thu, Jan 10, 2013 at 01:11:15AM +0100, Willy Tarreau wrote: On Thu, Jan 10, 2013 at 12:49:19AM +0100, Lukas Tribus wrote: Interesting. Are these implementations still in use ? This seems more like early experimentations than definitive releases to me. I don't know if such versions were shipped in any LTS distro, so most likely they'll quickly disappear. Am I wrong ? Looks like you are correct. In openssl 1.0.1 there is no aesni engine (needed) anymore. See: [1] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1001424 [2] http://cvs.openssl.org/chngview?cn=21519 Oh I'm certain about this one because this is the one we use in the Aloha and we achieve 5 Gbps of HTTPS per CPU core in AES256 :-) What I don't know is if the older versions are still in use nor for how long. EL6 has OpenSSL 1.0.0, but dunno if a minor version difference has any change in behaviour. -- Pasi
Re: nginx alone performs x2 than haproxy-nginx
On Mon, Apr 30, 2012 at 12:19:26PM +0200, Sebastien Estienne wrote: Hi Pasi, Do you know if ubuntu 12.04 has these optimized drivers or not? I think Canonical developers are going to add the drivers later in some update to Ubuntu 12.04 packages. The drivers are not yet in 12.04. I saw some discussion from Canonical guys on xen-devel about that. -- Pasi thanx -- Sebastien E. Le 30 avr. 2012 à 11:06, Pasi Kärkkäinen pa...@iki.fi a écrit : On Sun, Apr 29, 2012 at 06:18:52PM +0200, Willy Tarreau wrote: I'm using VPS machines from Linode.com, they are quite powerful. They're based on Xen. I don't see the network card saturated. OK I see now. There's no point searching anywhere else. Once again you're a victim of the high overhead of virtualization that vendors like to pretend is almost unnoticeable :-( As for nf_conntrack, I have iptables enabled with rules as a firewall on each machine, I stopped it on all involved machines and I still get those results. nf_conntrack is compiled to the kernel (it's a kernel provided by Linode) so I don't think I can disable it completely. Just not use it (and not use any firewall between them). It's having the module loaded with default settings which is harmful, so even unloading the rules will not change anything. Anyway, now I'm pretty sure that the overhead caused by the default conntrack settings is nothing compared with the overhead of Xen. Even if 6-7K is very low (for nginx directly), why is haproxy doing half than that? That's quite simple : it has two sides so it must process twice the number of packets. Since you're virtualized, you're packet-bound. Most of the time is spent communicating with the host and with the network, so the more the packets and the less performance you get. That's why you're seeing a 2x increase even with nginx when enabling keep-alive. I'd say that your numbers are more or less in line with a recent benchmark we conducted at Exceliance and which is summarized below (each time the hardware was running a single VM) : http://blog.exceliance.fr/2012/04/24/hypervisors-virtual-network-performance-comparison-from-a-virtualized-load-balancer-point-of-view/ (BTW you'll note that Xen was the worst performer here with 80% loss compared to native performance). Note that Ubuntu 11.10 kernel is lacking important drivers such as the Xen ACPI power management / cpufreq drivers so it's not able to use the better performing CPU states. That driver is merged to recent upstream Linux 3.4 (-rc). Also the xen-netback dom0 driver is still unoptimized in the upstream Linux kernel. Using RHEL5/CentOS5 as Xen host/dom0, or SLES11 or OpenSuse is a better idea today for benchmarking because those have the fully optimized kernel/drivers. Upstream Linux will get the optimizations in small steps (per the Linux development model). Citrix XenServer 6 is using the optimized kernel/drivers so that explains the difference in the benchmark compared to Ubuntu Xen4.1. I just wanted to hilight that. -- Pasi
Re: nginx alone performs x2 than haproxy-nginx
On Sun, Apr 29, 2012 at 06:18:52PM +0200, Willy Tarreau wrote: I'm using VPS machines from Linode.com, they are quite powerful. They're based on Xen. I don't see the network card saturated. OK I see now. There's no point searching anywhere else. Once again you're a victim of the high overhead of virtualization that vendors like to pretend is almost unnoticeable :-( As for nf_conntrack, I have iptables enabled with rules as a firewall on each machine, I stopped it on all involved machines and I still get those results. nf_conntrack is compiled to the kernel (it's a kernel provided by Linode) so I don't think I can disable it completely. Just not use it (and not use any firewall between them). It's having the module loaded with default settings which is harmful, so even unloading the rules will not change anything. Anyway, now I'm pretty sure that the overhead caused by the default conntrack settings is nothing compared with the overhead of Xen. Even if 6-7K is very low (for nginx directly), why is haproxy doing half than that? That's quite simple : it has two sides so it must process twice the number of packets. Since you're virtualized, you're packet-bound. Most of the time is spent communicating with the host and with the network, so the more the packets and the less performance you get. That's why you're seeing a 2x increase even with nginx when enabling keep-alive. I'd say that your numbers are more or less in line with a recent benchmark we conducted at Exceliance and which is summarized below (each time the hardware was running a single VM) : http://blog.exceliance.fr/2012/04/24/hypervisors-virtual-network-performance-comparison-from-a-virtualized-load-balancer-point-of-view/ (BTW you'll note that Xen was the worst performer here with 80% loss compared to native performance). Note that Ubuntu 11.10 kernel is lacking important drivers such as the Xen ACPI power management / cpufreq drivers so it's not able to use the better performing CPU states. That driver is merged to recent upstream Linux 3.4 (-rc). Also the xen-netback dom0 driver is still unoptimized in the upstream Linux kernel. Using RHEL5/CentOS5 as Xen host/dom0, or SLES11 or OpenSuse is a better idea today for benchmarking because those have the fully optimized kernel/drivers. Upstream Linux will get the optimizations in small steps (per the Linux development model). Citrix XenServer 6 is using the optimized kernel/drivers so that explains the difference in the benchmark compared to Ubuntu Xen4.1. I just wanted to hilight that. -- Pasi
Re: rpms for rhel5?
On Mon, Oct 25, 2010 at 10:02:43AM +0200, Angelo Höngens wrote: On 24-10-2010 21:44, Willy Tarreau wrote: On Sun, Oct 24, 2010 at 02:05:38PM +, Angelo Höngens wrote: Hey, does anyone know a place I can find rhel5 rpm's for the latest 1.4 releases? The popular repositories all seem to have only 1.3.. I'm not aware of any, and since the original package was 1.3, it seems logical that updates for the same package remain in the same branch. However, 1.4.8 is packaged for RHEL6. Maybe you can simply perform an rpmbuild on the .src ? That works like a charm! I've put my own built rpm here, in case someone else needs a quick fix: http://files.netmatch.nl/RPMS/haproxy-1.4.8-1.x86_64.rpm (although of course no one should trust binaries untrusted people precompile) You might want to add: --define 'dist .el5' to your rpmbuild command :) -- Pasi
Re: Haproxy support for HTTPS (SSL) backend servers
On Mon, Oct 18, 2010 at 07:00:37PM +0300, Reinis Rozitis wrote: I meant the features that need to parse the HTTP request and do things based on it.. So tcp/raw mode won't work.. Thanks for the reply though! -- Pasi I think you are better in this case using 'nginx' for example - http://wiki.nginx.org/HttpProxyModule (can do ACL / rewrites / header change and balancing on its own). Yeah, I've tried nginx aswell. It supports SSL on both the frontend and backend, which is good, but the problem with nginx is that it doesn't support http/1.1 on the backend side.. I have some application that also requires http/1.1 and refuses to serve http/1.0 requests.. this is not easy :) -- Pasi
Re: Haproxy support for HTTPS (SSL) backend servers
On Mon, Oct 18, 2010 at 03:02:26PM +, Soren Hansen wrote: Terminate the ssl using apache+mod_ssl as a proxy to your HAproxy Do your ACL stuff in HAproxy Then have HAproxy send the request to a local stunnel client. stunnel will then forward the request as ssl to a backend server. You will need to define one stunnel client per backend server. In HAproxy, you will have the local stunnels defined as servers. I tried this earlier.. and I got some problems with sessions timing out, and I could figure out what was causing it. It's kind of difficult when you have separate frontend (stunnel/pound), middleware (haproxy), and then also separate backend (stunnel). Replacing all that with nginx worked much better (no timeout problems), but then I have the problem where nginx doesn't support http/1.1 on the backend.. -- Pasi
Re: Haproxy support for HTTPS (SSL) backend servers
On Tue, Oct 19, 2010 at 02:35:01PM +0300, Pasi Kärkkäinen wrote: On Mon, Oct 18, 2010 at 03:02:26PM +, Soren Hansen wrote: Terminate the ssl using apache+mod_ssl as a proxy to your HAproxy Do your ACL stuff in HAproxy Then have HAproxy send the request to a local stunnel client. stunnel will then forward the request as ssl to a backend server. You will need to define one stunnel client per backend server. In HAproxy, you will have the local stunnels defined as servers. I tried this earlier.. and I got some problems with sessions timing out, and I could figure out what was causing it. I was supposed to write couldn't .. -- Pasi It's kind of difficult when you have separate frontend (stunnel/pound), middleware (haproxy), and then also separate backend (stunnel). Replacing all that with nginx worked much better (no timeout problems), but then I have the problem where nginx doesn't support http/1.1 on the backend.. -- Pasi
