HAProxy Healthcheck issue using Virtual hostname

Hi I have an app deployed in Pivotal Cloudfoundry (PCF) and to route traffic to an app in PCF, we have to use application route name (virtual hostname). We have PCF in two different datacenters and I need to load balance the traffic to these DCs , but I'm having the challenge in checking the

Re: Use SNI with healthchecks

On Fri, Apr 27, 2018 at 06:39:07AM +0200, Willy Tarreau wrote: > I think that a few operators like strcmp() and concat() should be > implemented to cover the short-term needs. I forgot that I finally implemented concat() after talking about it for about a year :-) It is a good starting point to

Re: Use SNI with healthchecks

Hi Tim, On Fri, Apr 27, 2018 at 12:16:15AM +0200, Tim Düsterhus wrote: > The solution I got from "Holger Just" was: > > > http-request set-header X-CHECKSNI %[req.hdr(host)]==%[ssl_fc_sni] if > > { ssl_fc_has_sni } > > http-request deny if { ssl_fc_has_sni } ! { >

Re: Use SNI with healthchecks

Hi Lukas, On Fri, Apr 27, 2018 at 01:56:42AM +0200, Lukas Tribus wrote: > Hello Willy, > > > On 25 April 2018 at 12:16, Willy Tarreau wrote: > >> I'm not even sure that differentiate "Host" header from SNI values is > >> possible on softwares like Nginx or Apache. > > > > It

Re: Use SNI with healthchecks

Hello Willy, On 25 April 2018 at 12:16, Willy Tarreau wrote: >> I'm not even sure that differentiate "Host" header from SNI values is >> possible on softwares like Nginx or Apache. > > It should not, that would be a violation of HTTP over TLS. I think I disagree. This is very

Re: 1.9dev LUA shows partial results from print_r(core.get_info()) after adding headers ?

Hi Thierry, Op 26-4-2018 om 12:25 schreef thierry.fourn...@arpalert.org: Your trace shows a corrupted tree. Maybe it is due to the freebsd architecture and the corruption is no reproductible on Linux ? I do not have freebsd for testing. Regards, Thierry My 'best' reproduction scenario

http healthcheck on backend with multiple servers not working

I need to perform HTTP healthcheck on individual backend servers and load balance among active backend servers.This works fine with single backend server when we mention host name in httpchk (option httpchk GET  /info HTTP/1.1 Host:\  abc.mysrv1.com)  However i am unable to successfully

Re: Use SNI with healthchecks

Willy, Am 25.04.2018 um 12:16 schrieb Willy Tarreau: > On Wed, Apr 25, 2018 at 09:48:13AM +, GALLISSOT VINCENT wrote: >> I don't see a case were one would define a different check-sni or sni values >> from the "Host" header. > > It definitely must match in HTTP. *snip* > >> I'm not even

Question on Caching.

Hello Haproxy mailing list I have been looking at caching technology and have found this https://github.com/jiangwenyuan/nuster/ It claims to be a v1.7 / v1.8 branch fully compatible with haproxy and indeed based on haproxy with the added capibility of having a really fast cache as described

Re: [PATCH] BUG/MINOR: lua/threads: Make lua's tasks sticky to the current thread

On Thu, Apr 26, 2018 at 02:42:46PM +0200, Christopher Faulet wrote: > Willy, > > Here is a patch to fix a bug recently reported by Pieter in the lua part (in > the thread ".1.9dev LUA core.tcp() cannot be used from different threads"). Applied, thanks! Willy

http-response set-header is unreliable

Hi I have got a frontend in mode http that sets various headers unconditionally: > http-response set-headerExpect-CT > "max-age=3600; report-uri=\"https://xxx.report-uri.com/r/d/ct/reportOnly\"; > http-response set-headerExpect-Staple >

Truly seamless reloads

Hi, According to https://www.haproxy.com/blog/truly-seamless-reloads-with-haproxy-no-more-hacks/ : "The patchset has already been merged into the HAProxy 1.8 development branch and will soon be backported to HAProxy Enterprise Edition 1.7r1 and possibly 1.6r2." Has it been backported to

[PATCH] BUG/MINOR: lua/threads: Make lua's tasks sticky to the current thread

Willy, Here is a patch to fix a bug recently reported by Pieter in the lua part (in the thread ".1.9dev LUA core.tcp() cannot be used from different threads"). Thanks, -- Christopher Faulet >From b38e9bdf727073a6063f1c56f173a247969c6f9e Mon Sep 17 00:00:00 2001 From: Christopher Faulet

Re: 1.9dev LUA core.tcp() cannot be used from different threads

Le 26/04/2018 à 12:01, Thierry Fournier a écrit : On 26 Apr 2018, at 11:49, Christopher Faulet wrote: Le 25/04/2018 à 20:51, PiBa-NL a écrit : Hi Christopher, Thierry, Op 25-4-2018 om 11:30 schreef Christopher Faulet: Oh, these tasks can be created before the threads

Re: [PATCH] MEDIUM: cli: Add multi-line mode support

On Thu, Apr 26, 2018 at 01:48:27PM +0200, Aurélien Nephtali wrote: > Willy, > > On Thu, Apr 26, 2018 at 12:32 PM, Willy Tarreau wrote: > > Thanks for this. All of this looks OK to me. Please just let me know if > > you want me to merge them now or if you expect other adjustments. >

[bug] http-reuse and TCP mode warning when using PROXY protocol

Hello, I set a global http-reuse safe. HAProxy displays a warning for http-reuse and send-proxy combinaison on TCP mode backends, but http-reuse is active only on HTTP mode backends. [WARNING] 115/135122 (26529) : config : proxy ' SMTPS_SUBMISSION' : connections to server 'f1' will have a

Re: [PATCH] MEDIUM: cli: Add multi-line mode support

Willy, On Thu, Apr 26, 2018 at 12:32 PM, Willy Tarreau wrote: > Thanks for this. All of this looks OK to me. Please just let me know if > you want me to merge them now or if you expect other adjustments. I think it's OK for me. Thanks ! -- Aurélien Nephtali

Re: [PATCH] MEDIUM: cli: Add multi-line mode support

Hi Aurélien, On Thu, Apr 26, 2018 at 09:52:59AM +0200, Aurélien Nephtali wrote: > Hello Willy, > > Sorry for the delay. no problem. > Here are the three amended patches. > > Changes: > - update the documentation > - add some comments regarding the detection of the payload pattern >

Re: 1.9dev LUA shows partial results from print_r(core.get_info()) after adding headers ?

On Wed, 25 Apr 2018 22:13:46 +0200 PiBa-NL wrote: > Hi Thierry, > > Op 25-4-2018 om 11:19 schreef Thierry Fournier: > > I extracted the part which dumps the ‘core.get_info()’, and I can’t > > reproduce > > the segfault. I attach the extracted code. I use le lastest

Re: Persisting stick tables on reload on 1.8

Hi, Thanks, it's working now. I saw peers mentioned elsewhere, but disregarded that section since i was testing on a single instance. On Thu, Apr 26, 2018 at 11:22 AM, Lukas Tribus wrote: > Hello Christian, > > > On 26 April 2018 at 09:45, Christian Greger

Re: 1.9dev LUA core.tcp() cannot be used from different threads

> On 26 Apr 2018, at 11:49, Christopher Faulet wrote: > > Le 25/04/2018 à 20:51, PiBa-NL a écrit : >> Hi Christopher, Thierry, >> Op 25-4-2018 om 11:30 schreef Christopher Faulet: >>> Oh, these tasks can be created before the threads creation... Ok, so >>> maybe the right

Re: 1.9dev LUA core.tcp() cannot be used from different threads

Le 25/04/2018 à 20:51, PiBa-NL a écrit : Hi Christopher, Thierry, Op 25-4-2018 om 11:30 schreef Christopher Faulet: Oh, these tasks can be created before the threads creation... Ok, so maybe the right way to fix the bug is to registered these tasks without specific affinity and set it on the

Re: Persisting stick tables on reload on 1.8

Hello Christian, On 26 April 2018 at 09:45, Christian Greger wrote: > Hi, > > I was hoping the seamless reload in 1.8 would retain stick tables, but I'm > having no luck. Is it possible? > Stick tables can be transferred from the old to the new process while reloading by

Re: multithreading issuse in haproxy 1.8.5

On Thu, Apr 26, 2018 at 10:58:07AM +0300, Slawa Olhovchenkov wrote: > > > I am mean in case of dedicated listen socket pooler also can be > > > dedicated, for load planing. For example: > > > > > > frontend tcp1 > > > bind x.x.x.206:443 > > > bind-process 1/9-1/16 > > >

Re: multithreading issuse in haproxy 1.8.5

On Thu, Apr 26, 2018 at 09:49:53AM +0200, Willy Tarreau wrote: > On Thu, Apr 26, 2018 at 10:35:51AM +0300, Slawa Olhovchenkov wrote: > > On Thu, Apr 26, 2018 at 09:25:59AM +0200, Willy Tarreau wrote: > > > > > On Thu, Apr 26, 2018 at 10:21:27AM +0300, Slawa Olhovchenkov wrote: > > > > > >

Re: [PATCH] MEDIUM: cli: Add multi-line mode support

Hello Willy, Sorry for the delay. Here are the three amended patches. Changes: - update the documentation - add some comments regarding the detection of the payload pattern and the input that is zero terminated - use appctx->chunk to gather data without using the trash -

Re: multithreading issuse in haproxy 1.8.5

On Thu, Apr 26, 2018 at 10:35:51AM +0300, Slawa Olhovchenkov wrote: > On Thu, Apr 26, 2018 at 09:25:59AM +0200, Willy Tarreau wrote: > > > On Thu, Apr 26, 2018 at 10:21:27AM +0300, Slawa Olhovchenkov wrote: > > > > > Pollers distinct from frontend? > > > > > Can I bind pollers to CPU? > > > > >

Persisting stick tables on reload on 1.8

Hi, I was hoping the seamless reload in 1.8 would retain stick tables, but I'm having no luck. Is it possible? I'm testing this with: haproxy: 1.8.8, single master, single thread, nbproc 1 OS: CentOS 7.4.1708 socket: stats socket /var/run/haproxy.sock level admin expose-fd listeners Systemctl

Re: multithreading issuse in haproxy 1.8.5

On Thu, Apr 26, 2018 at 09:25:59AM +0200, Willy Tarreau wrote: > On Thu, Apr 26, 2018 at 10:21:27AM +0300, Slawa Olhovchenkov wrote: > > > > Pollers distinct from frontend? > > > > Can I bind pollers to CPU? > > > > > > Each thread has its own poller. Since you map threads to CPUs you indeed > >

Re: multithreading issuse in haproxy 1.8.5

On Thu, Apr 26, 2018 at 10:21:27AM +0300, Slawa Olhovchenkov wrote: > > > Pollers distinct from frontend? > > > Can I bind pollers to CPU? > > > > Each thread has its own poller. Since you map threads to CPUs you indeed > > have one poller per CPU. > > Each pooler pool all sockets or only

Re: multithreading issuse in haproxy 1.8.5

On Wed, Apr 25, 2018 at 03:49:09PM +0200, Willy Tarreau wrote: > On Wed, Apr 25, 2018 at 04:24:42PM +0300, Slawa Olhovchenkov wrote: > > > > TCP load rise CPU use on all core (0-15), I am expect rise CPU use > > > > only on 8-15 core. What I am miss? > > > > > > It's unrelated to the frontend's