Re: [PATCH v2] MINOR: http: Log warning if (add|set)-header fails

[Willy Tarreau]

On Mon, May 28, 2018 at 09:19:11PM +0200, Tim Düsterhus wrote:
> Willy,
> 
> Am 28.05.2018 um 14:59 schrieb Willy Tarreau:
> > OK this was fine. I noticed that you also emitted the value for the servers
> > but that this one was not filled in the code, and that there was almost
> > nothing to do to get it, for the response case, which is useful because if
> > you see that one server has many more errors than the other ones, you know
> > it emits some different contents (eg: looping cookies).  I just had to add
> > the following lines for this :
> > 
> >   if (objt_server(s->target))
> >
> > HA_ATOMIC_ADD(_server(s->target)->counters.failed_rewrites, 1);
> 
> Understood. I just grepped through the code to find references of other
> counters and copied some good-looking code over. Maybe all those counter
> incrementing locations should be unified into an (inlined?) function
> which automatically does the right thing?

Not that much (it was already done a bit in fact). At most places,
the test only needs to be done once, and there are very few places
with more than one test, so there's very little to gain, and it will
add some abstraction adding useless efforts to read the code later.

> As I did not note anything in the commit message: It should be discussed
> whether this patch(es) should be backported. It looks fairly safe too me
> and could be helpful for people running 1.8 (or even older).

Oh that's the part I wanted to ask and I forgot. I'd like to wait a bit
to see if anyone complains about spams in their logs or not. We cannot
yet rule out the possibility that certain valid actions (for users) fail
half of the time for pretty valid reasons and suddenly become a burden.
I remember having seen a conf a very long time ago where request headers
were added in order of importance so that it was considered acceptable
not to be able to set them all. It was mostly some pre-qualification
done by haproxy to save the application from having to do it again so
failure to add was considered safe. I just don't know if this case is
the exception or more commonly found.

Cheers,
Willy

Re: [PATCH v2] MINOR: http: Log warning if (add|set)-header fails

[Tim Düsterhus]

Willy,

Am 28.05.2018 um 14:59 schrieb Willy Tarreau:
> OK this was fine. I noticed that you also emitted the value for the servers
> but that this one was not filled in the code, and that there was almost
> nothing to do to get it, for the response case, which is useful because if
> you see that one server has many more errors than the other ones, you know
> it emits some different contents (eg: looping cookies).  I just had to add
> the following lines for this :
> 
>   if (objt_server(s->target))
>
> HA_ATOMIC_ADD(_server(s->target)->counters.failed_rewrites, 1);

Understood. I just grepped through the code to find references of other
counters and copied some good-looking code over. Maybe all those counter
incrementing locations should be unified into an (inlined?) function
which automatically does the right thing?

> Also I found that the #%u with the request ID was missing for the request
> log, it was only for the response, so I fixed it. It works well and seems
> pretty useful. I'll check how to fit it into the stats page. It'll probably
> be OK in the tooltip which already contains the distribution by status code.
> 

The joys of copy and paste. Thank you. I also noticed that you adapted
the stats page already.

As I did not note anything in the commit message: It should be discussed
whether this patch(es) should be backported. It looks fairly safe too me
and could be helpful for people running 1.8 (or even older).

Best regards
Tim Düsterhus

Re: JWT payloads break b64dec convertor

[Benoît GARNIER]

Le 28/05/2018 à 10:19, Adis Nezirovic a écrit :
> On 05/26/2018 04:27 PM, Jonathan Matthews wrote:
>> Hello folks,
>>
>> The payload (and other parts) of a JSON Web Token (JWT, a popular and
>> growing auth standard: https://tools.ietf.org/html/rfc7519) is base64
>> encoded.
>>
>> Unfortunately, the payload encoding (specified in
>> https://tools.ietf.org/html/rfc7515) is defined as the "URL safe"
>> variant. This variant allows for the lossless omission of base64
>> padding ("=" or "=="), which the haproxy b64dec convertor doesn't
>> appear to be able cope with. The result of
> Jonathan,
>
> It's not just padding, urlsafe base64 replaces '+' with '-', and '/'
> with '_'. For now, I guess the easiest way would be to write a simple
> converter in Lua, which just returns the original string, and send
> payload somewhere for further processing.
For those who like "standards", these are all base64 variants :
https://en.wikipedia.org/wiki/Base64#Variants_summary_table

Oh, and don't forget to develop a new standard if those don't cover
yours needs: https://xkcd.com/927/

> Best regards,
> Adis

Bunch


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: JWT payloads break b64dec convertor

[Aleksandar Lazic]

On 28/05/2018 17:42, Norman Branitsky wrote:

https://en.wikipedia.org/wiki/The_C_Programming_Language


Oh, of course *clap on head* how embarrassing 8-O.

I haven't thought to THIS Book, sorry.

Best regards
Aleks


-Original Message-
From: Aleksandar Lazic 
Sent: Monday, May 28, 2018 12:34 PM
To: Jonathan Matthews 
Cc: Willy Tarreau ; haproxy 
Subject: Re: JWT payloads break b64dec convertor

On 28/05/2018 15:10, Jonathan Matthews wrote:

On Mon, 28 May 2018 at 14:26, Willy Tarreau  wrote:


On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
> Improvements and suggestions welcome; flames and horror ->
> /dev/null ;-)

Would anyone be interested in adding two new converters for this,
working exactly like base64/b64dec but with the URL-compatible
base64 encoding instead ? We could call them :

  u64dec
  u64enc



I like that idea, and have already retrieved my K from the loft :-)


Sorry for my ignorance but what's K ?


J


--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

RE: JWT payloads break b64dec convertor

[Norman Branitsky]

https://en.wikipedia.org/wiki/The_C_Programming_Language

-Original Message-
From: Aleksandar Lazic  
Sent: Monday, May 28, 2018 12:34 PM
To: Jonathan Matthews 
Cc: Willy Tarreau ; haproxy 
Subject: Re: JWT payloads break b64dec convertor

On 28/05/2018 15:10, Jonathan Matthews wrote:
>On Mon, 28 May 2018 at 14:26, Willy Tarreau  wrote:
>
>> On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
>> > Improvements and suggestions welcome; flames and horror -> 
>> > /dev/null ;-)
>>
>> Would anyone be interested in adding two new converters for this, 
>> working exactly like base64/b64dec but with the URL-compatible
>> base64 encoding instead ? We could call them :
>>
>>   u64dec
>>   u64enc
>
>
>I like that idea, and have already retrieved my K from the loft :-)

Sorry for my ignorance but what's K ?

>J
>
>> --
>Jonathan Matthews
>London, UK
>http://www.jpluscplusm.com/contact.html

Re: JWT payloads break b64dec convertor

[Aleksandar Lazic]

On 28/05/2018 15:10, Jonathan Matthews wrote:

On Mon, 28 May 2018 at 14:26, Willy Tarreau  wrote:


On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
> Improvements and suggestions welcome; flames and horror -> /dev/null ;-)

Would anyone be interested in adding two new converters for this,
working exactly like base64/b64dec but with the URL-compatible
base64 encoding instead ? We could call them :

  u64dec
  u64enc



I like that idea, and have already retrieved my K from the loft :-)


Sorry for my ignorance but what's K ?


J


--

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

Re: remaining process after (seamless) reload

[William Lallemand]

On Thu, May 24, 2018 at 11:00:29PM +0200, William Dauchy wrote:
> On Thu, May 24, 2018 at 12:01:38PM +0200, William Lallemand wrote:
> > I managed to reproduce something similar with the 1.8.8 version. It looks 
> > like
> > letting a socat connected to the socket helps.
> >
> > I'm looking into the code to see what's happening.
> 
> Indeed, after some more hours, I got the same issue on v1.8.8. However it 
> seems to
> be easier to reproduce in v1.8.9, but I might be wrong.
> So now I bet on either thread issue, or bind with reuseport.
> I'll try to do some more tests.
> 
> Best,

Hi,

I don't think I reproduced the same problem, so I have a few questions for you 
:-)

Are the problematical workers leaving when you reload a second time?

Did you try to kill -USR1 the worker ? It should exits with "Former worker $PID
exited with code 0" on stderr.

If not, could you check the Sig* lines in /proc/$PID/status for this worker?

Do you know how much time take haproxy to load its configuration, and do you
think you tried a reload before it finished to parse and load the config?
Type=notify in your systemd unit file should help for this case. If I remember
well it checks that the service is 'ready' before trying to reload.

I suspect the SIGUSR1 signal is not received by the worker, but I'm not sure
either if it's the master that didn't send it or if the worker blocked it.

Thanks!

-- 
William Lallemand

Re: JWT payloads break b64dec convertor

[Willy Tarreau]

On Mon, May 28, 2018 at 03:10:01PM +0100, Jonathan Matthews wrote:
> On Mon, 28 May 2018 at 14:26, Willy Tarreau  wrote:
> 
> > On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
> > > Improvements and suggestions welcome; flames and horror -> /dev/null ;-)
> >
> > Would anyone be interested in adding two new converters for this,
> > working exactly like base64/b64dec but with the URL-compatible
> > base64 encoding instead ? We could call them :
> >
> >   u64dec
> >   u64enc
> 
> 
> I like that idea, and have already retrieved my K from the loft :-)

By the way, another approach (cleaner?) could be to add an argument to
the existing b64dec()/base64() to indicate how it should work. I think
it's the utf8 or json or something like this which already does exactly
this.

Willy

Re: JWT payloads break b64dec convertor

[Jonathan Matthews]

On Mon, 28 May 2018 at 14:26, Willy Tarreau  wrote:

> On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
> > Improvements and suggestions welcome; flames and horror -> /dev/null ;-)
>
> Would anyone be interested in adding two new converters for this,
> working exactly like base64/b64dec but with the URL-compatible
> base64 encoding instead ? We could call them :
>
>   u64dec
>   u64enc


I like that idea, and have already retrieved my K from the loft :-)

J

> --
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html

Re: haproxy and solarflare onload

[Elias Abacioglu]

Hi Willy and HAproxy folks!

Sorry for bumping this old thread. But Solarflare recently released a new
Onload version.
http://www.openonload.org/download/openonload-201805-ReleaseNotes.txt

Here is a small excerpt from the Release Notes:
"

 A major overhaul to clustering and scalable filters enables new data
 center use cases.

 Scalable filters direct all traffic for a given VI to Onload so that
 the filter table size is not a constraint on the number of concurrent
 connections supported efficiently. This release allows scalable filters
 to be combined for both passive and active open connections and with RSS,
 enabling very high transaction rates for use cases such as a reverse web
 proxy.

"

So this NIC with Onload features requires tuning and perhaps a better
understanding of the Linux network stack than what I got to get working in
a high volume/frequency setup.
I am willing to gift one SFN8522(2x10Gbit/s SFP+) to the HAproxy
team(within EU there should be no toll) if you want to test the card and
it's capabilities.
I don't have any hard requirements for gifting this card, just that you got
the will to give it a fair shot. The only thing I want in return is that
you share your insights, good or bad. Perhaps we can get a working Onload
profile for HAproxy. They ship a example profile for nginx in
onload-201805. I am still very curious if Onload actually can offload the
CPU more than regular a NIC.

I don't have an EnterpriseOnload license. But this card should get a free
ScaleoutOnload license(basically it's included in the card, but Dell
forgot, so I had to reach out to Solarflare support to get a free License).
And ScaleoutOnload is their OpenOnload.
I could help out with that if needed.

So HAproxy team, you want this card to play with?

/Elias

Re: JWT payloads break b64dec convertor

[Willy Tarreau]

On Mon, May 28, 2018 at 01:43:41PM +0100, Jonathan Matthews wrote:
> Improvements and suggestions welcome; flames and horror -> /dev/null ;-)

Would anyone be interested in adding two new converters for this,
working exactly like base64/b64dec but with the URL-compatible
base64 encoding instead ? We could call them :

  u64dec
  u64enc

Note that it can be a nice and useful exercise for a first-time contribution,
don't be ashamed guys!

Willy

Re: [PATCHES] Fix bugs in the new scheduler

[Willy Tarreau]

On Mon, May 28, 2018 at 03:16:19PM +0200, Olivier Houchard wrote:
> Hi,
> 
> Unsurprisingly, the scheduler revamp that was committed last week has bugs.

:-)

> The main issue is that threads could sleep while there are still tasks to
> run, there are also fairness issues between the global runqueue and the local
> one.
> The attached patches should fix that.

Now applied, thank you!
Willy

[PATCHES] Fix bugs in the new scheduler

[Olivier Houchard]

Hi,

Unsurprisingly, the scheduler revamp that was committed last week has bugs.
The main issue is that threads could sleep while there are still tasks to
run, there are also fairness issues between the global runqueue and the local
one.
The attached patches should fix that.

Regards,

Olivier
>From f47ca20747c1cfc7b9e6413afe9c8819a84e485a Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Mon, 28 May 2018 13:51:06 +0200
Subject: [PATCH 1/3] BUG/MEDIUM: tasks: Don't forget to increase/decrease
 tasks_run_queue.

Don't forget to increase tasks_run_queue when we're adding a task to the
tasklet list, and to decrease it when we remove a task from a runqueue,
or its value won't be accurate, and could lead to tasks not being executed
when put in the global run queue.
---
 include/proto/task.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/proto/task.h b/include/proto/task.h
index c8004143b..ef296f6e9 100644
--- a/include/proto/task.h
+++ b/include/proto/task.h
@@ -177,6 +177,7 @@ static inline struct task *task_unlink_wq(struct task *t)
  */
 static inline struct task *__task_unlink_rq(struct task *t)
 {
+   HA_ATOMIC_SUB(_run_queue, 1);
eb32sc_delete(>rq);
if (likely(t->nice))
HA_ATOMIC_SUB(_tasks, 1);
@@ -219,6 +220,7 @@ static inline void task_insert_into_tasklet_list(struct 
task *t)
 */
if (unlikely(!HA_ATOMIC_CAS(>rq.node.leaf_p, , 0x1)))
return;
+   HA_ATOMIC_ADD(_run_queue, 1);
task_list_size[tid]++;
tl = (struct tasklet *)t;
LIST_ADDQ(_list[tid], >list);
-- 
2.14.3

>From 4f28192f2cf16920fbe69e4077a8b948c3bd8f4b Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Mon, 28 May 2018 14:53:08 +0200
Subject: [PATCH 2/3] MINOR: task: Also consider the task list size when
 getting global tasks.

We're taking tasks from the global runqueue based on the number of tasks
the thread already have in its local runqueue, but now that we have a task
list, we also have to take that into account.
---
 src/task.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/task.c b/src/task.c
index 327518896..f6bf9156d 100644
--- a/src/task.c
+++ b/src/task.c
@@ -260,7 +260,7 @@ void process_runnable_tasks()
 * much elements from the global list as to have a bigger local 
queue
 * than the average.
 */
-   while (rqueue_size[tid] <= average) {
+   while ((task_list_size[tid] + rqueue_size[tid]) <= average) {
 
/* we have to restart looking up after every batch */
rq_next = eb32sc_lookup_ge(, rqueue_ticks - 
TIMER_LOOK_BACK, tid_bit);
-- 
2.14.3

>From beff1e28af2c1b7529dd94586f881ac81a04c797 Mon Sep 17 00:00:00 2001
From: Olivier Houchard 
Date: Mon, 28 May 2018 14:54:49 +0200
Subject: [PATCH 3/3] BUG/MEDIUM: task: Don't forget to decrement max_processed
 after each task.

When the task list was introduced, we bogusly lost max_processed--, that means
we would execute as much tasks as present in the list, and we would never
set active_tasks_mask, so the thread would go to sleep even if more tasks were
to be executed.
---
 src/task.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/task.c b/src/task.c
index f6bf9156d..fb4840738 100644
--- a/src/task.c
+++ b/src/task.c
@@ -367,6 +367,7 @@ void process_runnable_tasks()
task_queue(t);
}
 
+   max_processed--;
if (max_processed <= 0) {
active_tasks_mask |= tid_bit;
activity[tid].long_rq++;
-- 
2.14.3

Re: [PATCH v2] MINOR: http: Log warning if (add|set)-header fails

[Willy Tarreau]

Hi again Tim,

On Mon, May 28, 2018 at 10:57:59AM +0200, Willy Tarreau wrote:
> > I added a counter and verified that it works using the stats socket. I 
> > copied
> > it from elsewhere in proto_http. Please check whether I did correctly (not
> > overcounting and such things). Also check whether all of the
> > stats_fill_*_stats functions should actually be modified.
> 
> Thanks for the info, I'll take a look.

OK this was fine. I noticed that you also emitted the value for the servers
but that this one was not filled in the code, and that there was almost
nothing to do to get it, for the response case, which is useful because if
you see that one server has many more errors than the other ones, you know
it emits some different contents (eg: looping cookies).  I just had to add
the following lines for this :

  if (objt_server(s->target))
   
HA_ATOMIC_ADD(_server(s->target)->counters.failed_rewrites, 1);

Also I found that the #%u with the request ID was missing for the request
log, it was only for the response, so I fixed it. It works well and seems
pretty useful. I'll check how to fit it into the stats page. It'll probably
be OK in the tooltip which already contains the distribution by status code.

Thus I've just merged it now. Thanks!
willy

Re: JWT payloads break b64dec convertor

[Jonathan Matthews]

On 28 May 2018 at 12:32, Jonathan Matthews  wrote:
> I think with your points and ccripy's sneaky (kudos!) padding
> insertion, I can do something which suffices for my current audit
> needs.

For the list, here's my working v1 that I ended up with. I'm sure
various things can be improved! :-)

I couldn't get ccripy's concat() and length() converters to work, but
I've stolen the basic idea - many thanks!

  acl ACL_jwt_payload_4x_chars_long var(txn.jwtpayload) -m reg ^(.{4})+$

  http-request set-var(txn.jwtpayload) req.hdr(jwt)
  http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub($,=)
if !ACL_jwt_payload_4x_chars_long
  http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub($,=)
if !ACL_jwt_payload_4x_chars_long
  http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub(-,+,g)
  http-request set-var(txn.jwtpayload) var(txn.jwtpayload),regsub(_,/,g)

  log-format " jwt-payload:%[var(txn.jwtpayload),b64dec]"

Improvements and suggestions welcome; flames and horror -> /dev/null ;-)

Jonathan

Re: JWT payloads break b64dec convertor

[Jonathan Matthews]

On 28 May 2018 at 09:19, Adis Nezirovic  wrote:
> On 05/26/2018 04:27 PM, Jonathan Matthews wrote:
>> Hello folks,
>>
>> The payload (and other parts) of a JSON Web Token (JWT, a popular and
>> growing auth standard: https://tools.ietf.org/html/rfc7519) is base64
>> encoded.
>>
>> Unfortunately, the payload encoding (specified in
>> https://tools.ietf.org/html/rfc7515) is defined as the "URL safe"
>> variant. This variant allows for the lossless omission of base64
>> padding ("=" or "=="), which the haproxy b64dec convertor doesn't
>> appear to be able cope with. The result of
>
> Jonathan,
>
> It's not just padding, urlsafe base64 replaces '+' with '-', and '/'
> with '_'.

You're right. I'd noticed those extra substitutions but, for some
reason I'd assumed they were applied after decoding. Brain fart!

> For now, I guess the easiest way would be to write a simple
> converter in Lua, which just returns the original string, and send
> payload somewhere for further processing.

One nice thing about the JWT format is that it's unambiguously
formatted as "header.payload.signature", so the payload can be
trivially parsed out of a sacrificial header with a

  http-request replace-header copy-of-jwt [^.]+\.([^.]+)\..+ \1

... or some such manipulation. Here, for clarity, I'm double-passing
it through an abns@ frontend-backend-listen chain, hence the
additional header and not a variable, as per your example.

I think with your points and ccripy's sneaky (kudos!) padding
insertion, I can do something which suffices for my current audit
needs.

I suspect you're right that a Lua convertor is probably the more
supportable way forwards, however.

Many thanks, both!
J

Re: [PATCH] BUG/MEDIUM: stick-tables: Decrement ref_cnt in table_* converters

[Willy Tarreau]

Hi Daniel,

On Sun, May 27, 2018 at 12:31:54PM -0400, Daniel Corbett wrote:
> I have attached the latest patch with these changes.

Now merged, thank you!

willy

Re: JWT payloads break b64dec convertor

[Adis Nezirovic]

On 05/26/2018 04:27 PM, Jonathan Matthews wrote:
> Hello folks,
> 
> The payload (and other parts) of a JSON Web Token (JWT, a popular and
> growing auth standard: https://tools.ietf.org/html/rfc7519) is base64
> encoded.
> 
> Unfortunately, the payload encoding (specified in
> https://tools.ietf.org/html/rfc7515) is defined as the "URL safe"
> variant. This variant allows for the lossless omission of base64
> padding ("=" or "=="), which the haproxy b64dec convertor doesn't
> appear to be able cope with. The result of

Jonathan,

It's not just padding, urlsafe base64 replaces '+' with '-', and '/'
with '_'. For now, I guess the easiest way would be to write a simple
converter in Lua, which just returns the original string, and send
payload somewhere for further processing.

Best regards,
Adis

Re: haproxy 1.9 status update

[Frederic Lecaille]

On 05/25/2018 06:10 PM, Willy Tarreau wrote:

Hi all,


[sniped]


   - peers over SSL [Fred] : the purpose is to allow all bind options with
 peers so that peers can exchange information securely. I think I've
 seen it posted somewhere, I'll have to dig through the archives.


Here are the rebased patches for this feature.

Fred.

>From e41942d0c85dd4270a685e5db5bf8523e87ef287 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 28 May 2018 08:47:52 +0200
Subject: [PATCH 10/10] DOC: peers: Update "peers" section SSL/TLS support
 documentation.

---
 doc/configuration.txt | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index e27d666..544b697 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -1833,6 +1833,12 @@ peers 
   Creates a new peer list with name . It is an independent section,
   which is referenced by one or more stick-tables.
 
+bind [param*]
+  Defines the binding parameters of the local peer of this "peers" section.
+  To avoid some redundancy, and as the  and  parameters
+  are already provided on "peer" (or "server") lines, they are not supported
+  by "bind" keyword in "peers" sections.
+
 disabled
   Disables a peers section. It disables both listening and any synchronization
   related to this section. This is provided to disable synchronization of stick
@@ -1841,7 +1847,7 @@ disabled
 enable
   This re-enables a disabled peers section which was previously disabled.
 
-peer  :
+peer  : [param*]
   Defines a peer inside a peers section.
   If  is set to the local peer name (by default hostname, or forced
   using "-L" command line option), haproxy will listen for incoming remote peer
@@ -1860,6 +1866,15 @@ peer  :
   You may want to reference some environment variables in the address
   parameter, see section 2.3 about environment variables.
 
+  Note: "peer" keyword may transparently be replaced by "server" keyword (see
+  "server" keyword explanation below).
+
+server  : [param*]
+  As previously mentionned, "peer" keyword may be replaced by "server" keyword
+  with a support for all "server" parameters found in 5.2 paragraph.
+  Some of these parameters are irrelevant for "peers" sections.
+
+
   Example:
 peers mypeers
 peer haproxy1 192.168.0.1:1024
-- 
2.1.4

>From a546f38d9e6fe980c477b91df0681ac6fa0289a9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 27 Apr 2018 13:56:13 +0200
Subject: [PATCH 09/10] MINOR: peers: Make incoming connections to SSL/TLS
 local peer work.

This patch makes "bind" work in "peers" sections. All "bind" settings
are supported, excepted ip:port parameters which are provided on
"peer" (or server) line matching the local peer.
After having parsed the configuration files ->prepare_bind_conf is run
to initialize all SSL/TLS stuff for the local peer.
---
 src/cfgparse.c | 95 ++
 1 file changed, 90 insertions(+), 5 deletions(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 96ccc9f..90735e6 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -1992,6 +1992,31 @@ static int init_peers_frontend(const char *file, int linenum,
 	return 0;
 }
 
+/* Only change ->file, ->line and ->arg struct bind_conf member values
+ * if already present.
+ */
+static struct bind_conf *bind_conf_uniq_alloc(struct proxy *p,
+  const char *file, int line,
+  const char *arg, struct xprt_ops *xprt)
+{
+	struct bind_conf *bind_conf;
+
+	if (!LIST_ISEMPTY(>conf.bind)) {
+		bind_conf = LIST_ELEM((>conf.bind)->n, typeof(bind_conf), by_fe);
+		free(bind_conf->file);
+		bind_conf->file = strdup(file);
+		bind_conf->line = line;
+		if (arg) {
+			free(bind_conf->arg);
+			bind_conf->arg = strdup(arg);
+		}
+	}
+	else {
+		bind_conf = bind_conf_alloc(p, file, line, arg, xprt);
+	}
+
+	return bind_conf;
+}
 /*
  * Parse a line in a ,  or  section.
  * Returns the error code, 0 if OK, or any combination of :
@@ -2012,7 +2037,56 @@ int cfg_parse_peers(const char *file, int linenum, char **args, int kwm)
 	int err_code = 0;
 	char *errmsg = NULL;
 
-	if (strcmp(args[0], "default-server") == 0) {
+	if (strcmp(args[0], "bind") == 0) {
+		int cur_arg;
+		static int kws_dumped;
+		struct bind_conf *bind_conf;
+		struct bind_kw *kw;
+		char *kws;
+
+		cur_arg = 1;
+
+		if (init_peers_frontend(file, linenum, NULL, curpeers) != 0) {
+			err_code |= ERR_ALERT | ERR_ABORT;
+			goto out;
+		}
+
+		bind_conf = bind_conf_uniq_alloc(curpeers->peers_fe, file, linenum,
+		 NULL, xprt_get(XPRT_RAW));
+		while (*args[cur_arg] && (kw = bind_find_kw(args[cur_arg]))) {
+			int ret;
+
+			ret = kw->parse(args, cur_arg, curpeers->peers_fe, bind_conf, );
+			err_code |= ret;
+			if (ret) {
+if (errmsg