Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

[Willy Tarreau]

with the attachment it's better :-)

On Fri, May 20, 2016 at 06:37:05AM +0200, Willy Tarreau wrote:
> Hi Jonathan,
> 
> On Wed, May 18, 2016 at 01:52:01PM -0400, Jonathan Fisher wrote:
> > Nice here's the complication output:
> > 
> > 
> > http://pastebin.com/iS2JKXED
> > 
> > Now I just have to figure out how to add openssl, zlib, and libpcre which
> > don't seem to be available on Oracle Solaris.
> 
> Normally it should also work with the attached patch which I'd prefer to
> merge for long-term safety.
> 
> Regarding the other packages you need above, when I was working on Solaris
> I used to pick them from sunfreeware.com, they used to work out of the box.
> 
> Regards,
> Willy
>From 594e0f0083b67c6bc130bf54211246c734f229ed Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Fri, 20 May 2016 06:29:59 +0200
Subject: BUILD: fix build on Solaris 11

htonll()/ntohll() already exist on Solaris 11 with a different declaration,
causing a build error as reported by Jonathan Fisher. They used to exist on
OSX with a #define which allowed us to detect them. It was a bad idea to give
these functions a name subject to conflicts like this. Simply rename them
my_htonll()/my_ntohll() to definitely get rid of the conflict.

This patch must be backported to 1.6.
---
 include/common/standard.h | 10 +++---
 src/sample.c  |  2 +-
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/include/common/standard.h b/include/common/standard.h
index f123f1a..8711ede 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -1048,8 +1048,7 @@ static inline unsigned char utf8_return_length(unsigned 
char code)
  * the whole code is optimized out. In little endian, with a decent compiler,
  * a few bswap and 2 shifts are left, which is the minimum acceptable.
  */
-#ifndef htonll
-static inline unsigned long long htonll(unsigned long long a)
+static inline unsigned long long my_htonll(unsigned long long a)
 {
union {
struct {
@@ -1060,15 +1059,12 @@ static inline unsigned long long htonll(unsigned long 
long a)
} w = { .by64 = a };
return ((unsigned long long)htonl(w.by32.w1) << 32) | htonl(w.by32.w2);
 }
-#endif
 
 /* Turns 64-bit value  from network byte order to host byte order. */
-#ifndef ntohll
-static inline unsigned long long ntohll(unsigned long long a)
+static inline unsigned long long my_ntohll(unsigned long long a)
 {
-   return htonll(a);
+   return my_htonll(a);
 }
-#endif
 
 /* returns a 64-bit a timestamp with the finest resolution available. The
  * unit is intentionally not specified. It's mostly used to compare dates.
diff --git a/src/sample.c b/src/sample.c
index 4f89bab..9e6baa8 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -765,7 +765,7 @@ static int c_int2bin(struct sample *smp)
 {
struct chunk *chk = get_trash_chunk();
 
-   *(unsigned long long int *)chk->str = htonll(smp->data.u.sint);
+   *(unsigned long long int *)chk->str = my_htonll(smp->data.u.sint);
chk->len = 8;
 
smp->data.u.str = *chk;
-- 
2.8.0.rc2.1.gbe9624a

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

[Willy Tarreau]

Hi Jonathan,

On Wed, May 18, 2016 at 01:52:01PM -0400, Jonathan Fisher wrote:
> Nice here's the complication output:
> 
> 
> http://pastebin.com/iS2JKXED
> 
> Now I just have to figure out how to add openssl, zlib, and libpcre which
> don't seem to be available on Oracle Solaris.

Normally it should also work with the attached patch which I'd prefer to
merge for long-term safety.

Regarding the other packages you need above, when I was working on Solaris
I used to pick them from sunfreeware.com, they used to work out of the box.

Regards,
Willy

[no subject]

[promotion]

Hi Customer,If you can not see the description below, please click here. 如無法閱讀以下的內容，請按此.To learn more, please visit www.printing100.com. 想了解多D請到www.printing100.com   Pull Up Banner   噴畫 | 印刷 | 安裝 | 設計一站式服務   易拉架7折優惠！機會難得，唔好錯過。 Easy pull glue 膠易拉架 Aluminum easy pull   鋁易拉架   Easy pull glue  膠易拉架  尺寸：60x160cm 80x200cm  架身主要由膠製造，經濟實惠，方便易用，安裝簡單，拉起即可。配合三節桿或伸縮桿拉起即用，拆卸後畫面自動縮回底座內，收藏及攜帶方便，多款型號，畫面及尺寸選擇。  Aluminum easy pull鋁易拉架尺寸：60x160cm   80x200cm架身主要由鋁製造，架身輕便，攜帶方便，最廣泛使用即最受歡迎，安裝簡單，配合三節桿或伸縮桿拉起即用，拆卸後畫面自動縮回底座內，收藏及攜帶方便，多款型號，畫面及尺寸選擇。     Hot Line ：82007559Email：sa...@printing100.com  If our promotional email  have causing you any disturbance, please email(promot...@printing100.com)  and acknowledge us for cancelation of the mailing list. 如此郵件對閣下帶來騷擾, 請以EMAIL(promot...@printing100.com) 通知我們  >

Reset your LinkedIn password

[LinkedIn Security]

Hi Shaoquan,

To make sure you continue having the best experience possible on LinkedIn, 
we're regularly monitoring our site and the Internet to keep your account 
information safe.

We've recently noticed a potential risk to your LinkedIn account coming from 
outside LinkedIn and we have taken actions to protect your account. You'll need 
to reset your password the next time you sign in.

If you would like to change your password now, follow these steps:

1. Visit LinkedIn's website or mobile app.
2. If you are currently logged in, please log out.
3. Sign in and follow the instructions to choose a new password.

Thanks for helping us keep your account safe,
The LinkedIn Team

.



This email was intended for Shaoquan Wang (Software expert at Alibaba.com).
Learn why we included this: 
https://www.linkedin.com/e/v2?e=2xoni3-ioexs7y8-7o=customerServiceUrl=AQHSHASBzF7Oqw=email_password_invalidated_01=4788

© LinkedIn. Mailing address: Room 817, 18F, Building 18, #1 DiSheng Bei Road, 
Bejing Yizhuang Development Area, China. LinkedIn and the LinkedIn logo are 
registered trademarks of LinkedIn.

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

[Vincent Bernat]

 ❦ 19 mai 2016 22:09 +0200, Willy Tarreau  :

> If you're interested in updating your patch for this I'll happily apply
> it. Otherwise I can do it myself to learn my lesson :-)

I'll let you do it yourself. :)
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)

Re: httpchk with: http-send-name-header & related...

[Willy Tarreau]

On Sat, May 14, 2016 at 02:24:21PM +0200, Mehdi Ahmadi wrote:
> When specifying:
> ```
> option httpchk
> ```
> As default or specific to a back-end - other properties are not passed or
> set as part of the health check request.
> 
> For example:
> - http-send-name-header
> - forwardfor
> Are not preserved or included in the health-check request.
> 
> At present it is possible to simply include required headers manually such
> as:
> ```
> backend TEST
>  option httpchk HEAD / HTTP/1.1\r\nHost: fqnd.tld.org
>  http-check expect status 200
> ```
> However in the case of different / differing ID by server that'd correspond
> to the expected Host value to be passed with each request - one would need
> to result to multiple backends with varying checks or have multiple checks
> per server in each back-end which may not be possible?
> 
> IMO it would be beneficial to include all related headers and options with
> health checks by default with an added flag or property to disable this
> behavior reverting back to what is the current behavior.
> 
> Is this a rational request & can it be anticipated in a future release?

This request is perfectly rational. In the past we wanted to reimplement
HTTP checks in a cleaner way to make them more configurable (hence the
"http-check" directive). But it seems that in practice the checks are
"good enough" for most use cases resulting in nobody being really
interested to dig into this complex plate of spaghetti. Also it's
important not to break existing setups and not to make things harder for
users in the future. At minima I'd like that we can pass :
  - extra headers using a fixed value (typically Host)
  - honnor the http-send-name-header option
  - send a small body where the content-length is automatically computed
(eg: login+passwd, JSON or XML parameters)

But some people are also interested in sequences equivalent to tcp-checks
where we could for example send a login+passwd, retrieve a cookie and send
a new request with the cookie. This is quite rare but it helps get the whole
figure. I don't know if you're interested in investigating such changes.

Regards,
Willy

Re: [PATCH] DOC: Fix typo so fetch is properly parsed by Cyril's converter

[Willy Tarreau]

applied, thanks Nenad.
willy

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

[Willy Tarreau]

On Thu, May 19, 2016 at 07:33:50AM +0200, Vincent Bernat wrote:
>  ??? 18 mai 2016 22:56 +0200, Pavlos Parissis  :
> 
> >> Also, where is the bugtracker for haproxy? I can file a report if you
> >> want to save time.
> >
> > As far as I know there isn't any bugtracker. Posting problems in this
> > ML is enough to kick the investigation. So far this model works quite
> > well
> 
> Yes, Willy will notice the patch at some point and maybe merge it if
> he's OK with it.

Exact and here 1000 persons can read the discussions, while bug trackers
generally tend to be limited to a few interested readers. I like bug trackers
for complex bugs that take months or years to be fixed though.

Vincent, I was the one introducing htonll() and I did a mistake. I thought
nobody would have it and as you saw, OSX proved me wrong, just like Solaris
11 now. Other OSes will follow and we'll get annoyed again once a libc
decides to define _htonll() for its own use.

Usually when there's a risk of symbol conflict, we prefix the offending
functions by "my_" to clearly state that they are our own implementation
and that while we try to have the same API there's no guarantee for this.
Here I should have done this as well. I'd rather just rename the function,
its two call places and get rid of the #ifndef.

If you're interested in updating your patch for this I'll happily apply
it. Otherwise I can do it myself to learn my lesson :-)

Cheers,
Willy

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Willy Tarreau]

On Thu, May 19, 2016 at 11:15:51AM +0200, Vincent Bernat wrote:
(...)
> This is a backport for 1.5 of 3baab74e32ceec987e7ff3db1627b760bbac3027.

Thank you Vincent. I merged the BUG/MINOR patch into 1.7 and 1.6, merged
this one into 1.5 after fixing the commit ID above and adding a reference
to the new one (since it's included).

Cheers,
Willy

Re: [PATCH] BUG/MEDIUM: init: don't use environment locale

[Cyril Bonté]

Hi,

Le 19/05/2016 03:11, Maciej Katafiasz a écrit :

On 18 May 2016 at 16:18, Cyril Bonté  wrote:

Le 19/05/2016 00:34, Maciej Katafiasz a écrit :

While potentially
confusing, forcing it to C is also confusing and prevents people from
actually exploiting locale should they want to, and traditionally the
Unix approach was to let the administrator get the locale right, so
it's also more consistent with how other software does it.



Which ones ? As previously said, nor apache httpd and nginx do that with
their respective "include" directive, at least. Why would we want to make it
differently ?


Postgresql for example [...]


Sorry but no, it doesn't. The "include_dir" directive in PosgreSQL uses 
readdir() which doesn't have any sorting guarantee, fills an array with 
the filenames, then calls qsort() on the arrray with strcmp() as the 
comparator function.


They also document this in their documentation :
"Multiple files within an include directory are processed in file name 
order (according to C locale rules, i.e. numbers before letters, and 
uppercase letters before lowercase ones)."
and they have the good idea to provide some good practices about naming 
convention.


--
Cyril Bonté

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

[Vincent Bernat]

 ❦ 19 mai 2016 09:30 -0400, Jonathan Fisher  :

> Where is the git repo for haproxy? having trouble finding the official
> one, all I can find is a mirror on github.

On http://haproxy.org, you have the links in the main table.
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

[Daniel Schneller]

On the http://www.haproxy.org  homepage there is a 
link to each version’s repo.


Cheers,
Daniel



> On 19.05.2016, at 15:30, Jonathan Fisher  wrote:
> 
> Cool, thanks! 
> 
> Where is the git repo for haproxy? having trouble finding the official one, 
> all I can find is a mirror on github.
> 
> On Thu, May 19, 2016 at 1:33 AM, Vincent Bernat  > wrote:
>  ❦ 18 mai 2016 22:56 +0200, Pavlos Parissis  > :
> 
> >> Also, where is the bugtracker for haproxy? I can file a report if you
> >> want to save time.
> >
> > As far as I know there isn't any bugtracker. Posting problems in this
> > ML is enough to kick the investigation. So far this model works quite
> > well
> 
> Yes, Willy will notice the patch at some point and maybe merge it if
> he's OK with it.
> --
> Habit is habit, and not to be flung out of the window by any man, but coaxed
> down-stairs a step at a time.
> -- Mark Twain, "Pudd'nhead Wilson's Calendar
> 
> 
> 
> -- 
> 
> Jonathan S. Fisher
> Senior Software Engineer
> https://twitter.com/exabrial 
> http://www.tomitribe.com 
> https://www.tomitribe.io 

Re: Compilation problem: haproxy 1.6.5 (latest) on Solaris 11

[Jonathan Fisher]

Cool, thanks!

Where is the git repo for haproxy? having trouble finding the official one,
all I can find is a mirror on github.

On Thu, May 19, 2016 at 1:33 AM, Vincent Bernat  wrote:

>  ❦ 18 mai 2016 22:56 +0200, Pavlos Parissis  :
>
> >> Also, where is the bugtracker for haproxy? I can file a report if you
> >> want to save time.
> >
> > As far as I know there isn't any bugtracker. Posting problems in this
> > ML is enough to kick the investigation. So far this model works quite
> > well
>
> Yes, Willy will notice the patch at some point and maybe merge it if
> he's OK with it.
> --
> Habit is habit, and not to be flung out of the window by any man, but
> coaxed
> down-stairs a step at a time.
> -- Mark Twain, "Pudd'nhead Wilson's Calendar
>



-- 

*Jonathan S. Fisher*
Senior Software Engineer
https://twitter.com/exabrial
http://www.tomitribe.com
https://www.tomitribe.io

[PATCH] BUG/MINOR: fix listening IP address storage for frontends (cont)

[Vincent Bernat]

From: Vincent Bernat 

Commit 6e6158 was incomplete. There was an additional aggregate copy
that may trigger a similar case in the future.
---
 src/cfgparse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 48e584cf73e7..9b7646523de9 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -298,7 +298,7 @@ int str2listener(char *str, struct proxy *curproxy, struct 
bind_conf *bind_conf,
l->bind_conf = bind_conf;
 
l->fd = fd;
-   l->addr = ss;
+   memcpy(>addr, , sizeof(ss));
l->xprt = _sock;
l->state = LI_INIT;
 
-- 
2.8.1

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Vincent Bernat]

 ❦ 19 mai 2016 11:23 +0200, Cyril Bonté  :

>> De: "Vincent Bernat" 
>>  for (; port <= end; port++) {
>>  l = (struct listener *)calloc(1, sizeof(struct 
>> listener));
>> @@ -291,7 +291,7 @@ int str2listener(char *str, struct proxy
>> *curproxy, struct bind_conf *bind_conf,
>>  l->bind_conf = bind_conf;
>>  
>>  l->fd = fd;
>> -l->addr = ss;
>> +memcpy(>addr, , sizeof(ss));
>>  l->xprt = _sock;
>>  l->state = LI_INIT;
>
> This one was not present in the patch for haproxy 1.6/1.7 ! Maybe it
> should ?

Yes, I just noticed it too. Sending a patch.
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Vincent Bernat]

 ❦ 19 mai 2016 11:15 +0200, Vincent Bernat  :

> This is a backport for 1.5 of
> 3baab74e32ceec987e7ff3db1627b760bbac3027.

Wrong commit number. This should be 6e6158.
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Cyril Bonté]

Hi Vincent,

> De: "Vincent Bernat" 
>   for (; port <= end; port++) {
>   l = (struct listener *)calloc(1, sizeof(struct 
> listener));
> @@ -291,7 +291,7 @@ int str2listener(char *str, struct proxy
> *curproxy, struct bind_conf *bind_conf,
>   l->bind_conf = bind_conf;
>  
>   l->fd = fd;
> - l->addr = ss;
> + memcpy(>addr, , sizeof(ss));
>   l->xprt = _sock;
>   l->state = LI_INIT;

This one was not present in the patch for haproxy 1.6/1.7 ! Maybe it should ?

Cheers,
Cyril

[PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Vincent Bernat]

From: Vincent Bernat 

When compiled with GCC 6, the IP address specified for a frontend was
ignored and HAProxy was listening on all addresses instead. This is
caused by an incomplete copy of a "struct sockaddr_storage".

With the GNU Libc, "struct sockaddr_storage" is defined as this:

struct sockaddr_storage
  {
sa_family_t ss_family;
unsigned long int __ss_align;
char __ss_padding[(128 - (2 * sizeof (unsigned long int)))];
  };

Doing an aggregate copy (ss1 = ss2) is different than using memcpy():
only members of the aggregate have to be copied. Notably, padding can be
or not be copied. In GCC 6, some optimizations use this fact and if a
"struct sockaddr_storage" contains a "struct sockaddr_in", the port and
the address are part of the padding (between sa_family and __ss_align)
and can be not copied over.

Therefore, we replace any aggregate copy by a memcpy(). There is another
place using the same pattern. We also fix a function receiving a "struct
sockaddr_storage" by copy instead of by reference. Since it only needs a
read-only copy, the function is converted to request a reference.

This is a backport for 1.5 of 3baab74e32ceec987e7ff3db1627b760bbac3027.
---
 src/cfgparse.c   |  4 ++--
 src/connection.c |  2 +-
 src/proto_http.c | 12 ++--
 src/proto_tcp.c  |  2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/cfgparse.c b/src/cfgparse.c
index 39abf6b40429..9331415e12b3 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -280,7 +280,7 @@ int str2listener(char *str, struct proxy *curproxy, struct 
bind_conf *bind_conf,
}
 
/* OK the address looks correct */
-   ss = *ss2;
+   memcpy(, ss2, sizeof(ss));
 
for (; port <= end; port++) {
l = (struct listener *)calloc(1, sizeof(struct 
listener));
@@ -291,7 +291,7 @@ int str2listener(char *str, struct proxy *curproxy, struct 
bind_conf *bind_conf,
l->bind_conf = bind_conf;
 
l->fd = fd;
-   l->addr = ss;
+   memcpy(>addr, , sizeof(ss));
l->xprt = _sock;
l->state = LI_INIT;
 
diff --git a/src/connection.c b/src/connection.c
index dab1c9076166..09fd04e5286a 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -620,7 +620,7 @@ int make_proxy_line_v2(char *buf, int buf_len, struct 
server *srv, struct connec
const char pp2_signature[] = PP2_SIGNATURE;
int ret = 0;
struct proxy_hdr_v2 *hdr = (struct proxy_hdr_v2 *)buf;
-   struct sockaddr_storage null_addr = {0};
+   struct sockaddr_storage null_addr = { .ss_family = 0 };
struct sockaddr_storage *src = _addr;
struct sockaddr_storage *dst = _addr;
 #ifdef USE_OPENSSL
diff --git a/src/proto_http.c b/src/proto_http.c
index b3aa4d83308f..0b13c5ebc2cf 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -3220,15 +3220,15 @@ int http_handle_stats(struct session *s, struct channel 
*req)
 /* Sets the TOS header in IPv4 and the traffic class header in IPv6 packets
  * (as per RFC3260 #4 and BCP37 #4.2 and #5.2).
  */
-static inline void inet_set_tos(int fd, struct sockaddr_storage from, int tos)
+static inline void inet_set_tos(int fd, struct sockaddr_storage *from, int tos)
 {
 #ifdef IP_TOS
-   if (from.ss_family == AF_INET)
+   if (from->ss_family == AF_INET)
setsockopt(fd, IPPROTO_IP, IP_TOS, , sizeof(tos));
 #endif
 #ifdef IPV6_TCLASS
-   if (from.ss_family == AF_INET6) {
-   if (IN6_IS_ADDR_V4MAPPED(&((struct sockaddr_in6 
*))->sin6_addr))
+   if (from->ss_family == AF_INET6) {
+   if (IN6_IS_ADDR_V4MAPPED(&((struct sockaddr_in6 
*)from)->sin6_addr))
/* v4-mapped addresses need IP_TOS */
setsockopt(fd, IPPROTO_IP, IP_TOS, , sizeof(tos));
else
@@ -3366,7 +3366,7 @@ http_req_get_intercept_rule(struct proxy *px, struct list 
*rules, struct session
 
case HTTP_REQ_ACT_SET_TOS:
if ((cli_conn = objt_conn(s->req->prod->end)) && 
conn_ctrl_ready(cli_conn))
-   inet_set_tos(cli_conn->t.sock.fd, 
cli_conn->addr.from, rule->arg.tos);
+   inet_set_tos(cli_conn->t.sock.fd, 
_conn->addr.from, rule->arg.tos);
break;
 
case HTTP_REQ_ACT_SET_MARK:
@@ -3563,7 +3563,7 @@ http_res_get_intercept_rule(struct proxy *px, struct list 
*rules, struct session
 
case HTTP_RES_ACT_SET_TOS:
if ((cli_conn = objt_conn(s->req->prod->end)) && 
conn_ctrl_ready(cli_conn))
-   inet_set_tos(cli_conn->t.sock.fd, 
cli_conn->addr.from, rule->arg.tos);
+   inet_set_tos(cli_conn->t.sock.fd, 
_conn->addr.from, rule->arg.tos);
   

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Willy Tarreau]

On Thu, May 19, 2016 at 11:10:09AM +0200, Vincent Bernat wrote:
>  ??? 19 mai 2016 10:54 +0200, Willy Tarreau  :
> 
> >> >> When compiled with GCC 6, the IP address specified for a frontend was
> >> >> ignored and HAProxy was listening on all addresses instead. This is
> >> >> caused by an incomplete copy of a "struct sockaddr_storage".
> >> >
> >> > Patch applied to both 1.7-dev and 1.6. I haven't checked yet if/what 
> >> > needs
> >> > to be adjusted for 1.5.
> >> 
> >> Do you want me to do that?
> >
> > As you like. I can't hide the fact that it will significantly help me
> > considering you've already done the job for 1.6/1.7. But if you don't
> > have time I'll do it as part of my next backport session.
> 
> I'll do it. Should I keep BUG/MAJOR? HAProxy 1.5 is far less likely to
> be compiled with GCC 6.

I think it's fine to keep the same tag given the impact. Most MAJOR bugs
are very unlikely to hit but when they hit you'd rather not be there :-)

Thanks Vincent!
willy

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Vincent Bernat]

 ❦ 19 mai 2016 10:54 +0200, Willy Tarreau  :

>> >> When compiled with GCC 6, the IP address specified for a frontend was
>> >> ignored and HAProxy was listening on all addresses instead. This is
>> >> caused by an incomplete copy of a "struct sockaddr_storage".
>> >
>> > Patch applied to both 1.7-dev and 1.6. I haven't checked yet if/what needs
>> > to be adjusted for 1.5.
>> 
>> Do you want me to do that?
>
> As you like. I can't hide the fact that it will significantly help me
> considering you've already done the job for 1.6/1.7. But if you don't
> have time I'll do it as part of my next backport session.

I'll do it. Should I keep BUG/MAJOR? HAProxy 1.5 is far less likely to
be compiled with GCC 6.
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Willy Tarreau]

On Thu, May 19, 2016 at 10:49:46AM +0200, Vincent Bernat wrote:
>  ??? 19 mai 2016 10:46 +0200, Willy Tarreau  :
> 
> >> When compiled with GCC 6, the IP address specified for a frontend was
> >> ignored and HAProxy was listening on all addresses instead. This is
> >> caused by an incomplete copy of a "struct sockaddr_storage".
> >
> > Patch applied to both 1.7-dev and 1.6. I haven't checked yet if/what needs
> > to be adjusted for 1.5.
> 
> Do you want me to do that?

As you like. I can't hide the fact that it will significantly help me
considering you've already done the job for 1.6/1.7. But if you don't
have time I'll do it as part of my next backport session.

Thanks,
Willy

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Vincent Bernat]

 ❦ 19 mai 2016 10:46 +0200, Willy Tarreau  :

>> When compiled with GCC 6, the IP address specified for a frontend was
>> ignored and HAProxy was listening on all addresses instead. This is
>> caused by an incomplete copy of a "struct sockaddr_storage".
>
> Patch applied to both 1.7-dev and 1.6. I haven't checked yet if/what needs
> to be adjusted for 1.5.

Do you want me to do that?
-- 
Use debugging compilers.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Willy Tarreau]

On Wed, May 18, 2016 at 04:17:44PM +0200, Vincent Bernat wrote:
> When compiled with GCC 6, the IP address specified for a frontend was
> ignored and HAProxy was listening on all addresses instead. This is
> caused by an incomplete copy of a "struct sockaddr_storage".
(...)

Patch applied to both 1.7-dev and 1.6. I haven't checked yet if/what needs
to be adjusted for 1.5.

thanks!
Willy

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Willy Tarreau]

Hi Arthur,

On Thu, May 19, 2016 at 11:06:06AM +0300, Arthur ??i??eic?? wrote:
> I tried again this morning with fresh eyes so this time a was able to 
> discover 
> the horror of web interfaces [1] that make "helpful" transformations like 
>  
> for @ together with random spaces around.

Wow I didn't notice this, that's indeed horribly crippled!

> And of course the patch utility will happily just say "patching file include/
> proto/proto_http.h" when in fact the patch is flawed and it's not changing 
> anything.

Of course since it found no hunk in it.

> Finally being aware and able to overcome these unexpected obstacles I can 
> indeed confirm that the issue seems fixed with haproxy 1.6.5 and gcc 6. 
> Haproxy 
> listens only on configured IPv4 addresses.

Thanks! I'm applying it now.

Willy

Re: [PATCH] BUG/MAJOR: fix listening IP address storage for frontends

[Arthur Țițeică]

Hi,

În ziua de miercuri, 18 mai 2016, la 22:58:06 EEST, Cyril Bonté a scris:
> Le 18/05/2016 22:52, Arthur Țițeică a écrit :
> > În ziua de miercuri, 18 mai 2016, la 22:38:45 EEST, Cyril Bonté a scris:
> >> It looks like you didn't recompile with USE_OPENSSL=1
> >> haproxy -vv should give some hints.
> > 
> > Indeed, sorry about that. And error on my build script.
> > 
> > I fixed that, haproxy starts successfully but the issue remains, it still
> > listens on the wildcard IPv4 addresses.
> 
> Are you sure to run the binary with the patch applied ?
> 
>  From my quick test, Vincent's patch is working well with gcc 6 (and
> that's already what I saw during my diagnostics about memcpy).


I tried again this morning with fresh eyes so this time a was able to discover 
the horror of web interfaces [1] that make "helpful" transformations like  
for @ together with random spaces around.

And of course the patch utility will happily just say "patching file include/
proto/proto_http.h" when in fact the patch is flawed and it's not changing 
anything.


Finally being aware and able to overcome these unexpected obstacles I can 
indeed confirm that the issue seems fixed with haproxy 1.6.5 and gcc 6. Haproxy 
listens only on configured IPv4 addresses.

Thank you all

[1] http://article.gmane.org/gmane.comp.web.haproxy/27986