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 " 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 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 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
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
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 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 Tue, Oct 19, 2010 at 05:42:51PM +0300, Reinis Rozitis wrote: >> Have you tried Varnish? >> http://www.varnish-cache.org/ >> It's intended as a caching proxy but can do what you're after perfectly >> well. >> >> Also if there's anything it can't do, you can in-line drop in to C in >> the config files and make it do it! > > As far as I know varnish doesnt support SSL (neither as frontend nor in > backends)? > So you would have to implement some extra layers anyways. > > While I havent tried myself (the URL thing (with providing the key/cert > to the balancer)) you could try Pound ( http://www.apsis.ch/pound/ ) > which supports theclient <-- ssl --> balancer (url parsing) <-- ssl > --> backend scheme.. > Yep, I noticed Pound supports ssl to the backend in the latest version (2.5). Another question: Do you guys know if some balancer allows 'http connect' passthrough? I'd like to pass 'http connect' requests 'as is' to the backend server. For example Pound seems to drop that request.. -- Pasi
Re: Haproxy support for HTTPS (SSL) backend servers
On Tue, Oct 19, 2010 at 11:46:23AM +, Simon Green - Centric IT Ltd wrote: > Have you tried Varnish? > http://www.varnish-cache.org/ > It's intended as a caching proxy but can do what you're after perfectly well. > > Also if there's anything it can't do, you can in-line drop in to C in the > config files and make it do it! > Thanks for the tip. I'll take a look at it. -- Pasi > -Original Message- > From: Pasi Kärkkäinen [mailto:pa...@iki.fi] > Sent: 19 October 2010 12:33 > To: Reinis Rozitis > Cc: haproxy@formilux.org > Subject: 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 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 > >
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 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 Sat, Oct 16, 2010 at 06:29:19AM -0700, Nicholas Hadaway wrote: > ACL features work just fine in TCP mode as well as HTTP mode. > 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 > -nick > > On 10/16/2010 3:34 AM, Pasi Kärkkäinen wrote: >> Hello, >> >> I'd like to use haproxy to loadbalance a service >> that uses (only) https in the backend.. service in question >> cannot be changed to provide http, it's https only. >> (I know, it's stupid, but I cannot change that unfortunately..) >> >> I know I could use the haproxy 'raw' mode, but I need some of the >> ACL features of haproxy, so I need to use the http mode instead. >> >> Does someone have a patch that allows using https on the backend? >> >> If there's no such patch, how big changes it would require? >> I might work on it if there's nothing ready yet.. >> >> Thanks! >> >> -- Pasi >> >> > >
Haproxy support for HTTPS (SSL) backend servers
Hello, I'd like to use haproxy to loadbalance a service that uses (only) https in the backend.. service in question cannot be changed to provide http, it's https only. (I know, it's stupid, but I cannot change that unfortunately..) I know I could use the haproxy 'raw' mode, but I need some of the ACL features of haproxy, so I need to use the http mode instead. Does someone have a patch that allows using https on the backend? If there's no such patch, how big changes it would require? I might work on it if there's nothing ready yet.. Thanks! -- Pasi
