On Fri, Dec 23, 2016 at 10:35:13PM +0100, thierry.fourn...@arpalert.org wrote:
> I return true if the largest network contains the smaller. The order of
> networks are not important.
>
> I wrote this code a long time ago, I'm not remember exactly. Maybe I
> wrote bullshit.
>
> I write this code
On Fri, 23 Dec 2016 22:04:57 +0100
Willy Tarreau wrote:
> On Fri, Dec 23, 2016 at 09:50:53PM +0100, thierry.fourn...@arpalert.org wrote:
> > On Fri, 23 Dec 2016 18:07:07 +0100
> > Willy Tarreau wrote:
> >
> > > On Fri, Dec 23, 2016 at 05:54:47PM +0100,
On Fri, Dec 23, 2016 at 09:50:53PM +0100, thierry.fourn...@arpalert.org wrote:
> On Fri, 23 Dec 2016 18:07:07 +0100
> Willy Tarreau wrote:
>
> > On Fri, Dec 23, 2016 at 05:54:47PM +0100, thierry.fourn...@arpalert.org
> > wrote:
> > > Thanks ! Willy, can you apply the patch ?
> >
>
On Fri, Dec 23, 2016 at 05:54:47PM +0100, thierry.fourn...@arpalert.org wrote:
> Thanks ! Willy, can you apply the patch ?
Done, thanks guys.
However Thierry my previous question still stands : what *real* type of test
is this supposed to validate ? Because in my opinion this test consisting in
Thanks ! Willy, can you apply the patch ?
On Fri, 23 Dec 2016 19:47:10 +0300
Dmitry Sivachenko wrote:
>
> > On 23 Dec 2016, at 19:07, thierry.fourn...@arpalert.org wrote:
> >
> > Ok, thanks Willy.
> >
> > The news path in attachment. David, can you test the FreeBSD
> On 23 Dec 2016, at 19:07, thierry.fourn...@arpalert.org wrote:
>
> Ok, thanks Willy.
>
> The news path in attachment. David, can you test the FreeBSD build ?
> The patch is tested and validated for Linux.
Yes, it does fix FreeBSD build.
>
> Thierry
>
>
> On Fri, 23 Dec 2016 14:50:38
On Fri, Dec 23, 2016 at 05:21:57PM +0100, Willy Tarreau wrote:
> Hi Baptiste,
>
>
> On Fri, Dec 23, 2016 at 04:57:36PM +0100, Willy Tarreau wrote:
> (...)
> > The problem is that in order not
> > to lose the port which was already parsed, we temporarily set the family to
> > AF_INET and store
Hi Baptiste,
On Fri, Dec 23, 2016 at 04:57:36PM +0100, Willy Tarreau wrote:
(...)
> The problem is that in order not
> to lose the port which was already parsed, we temporarily set the family to
> AF_INET and store the port in the sockaddr. The problem is that by doing so
> we lose the initial
Ok, thanks Willy.
The news path in attachment. David, can you test the FreeBSD build ?
The patch is tested and validated for Linux.
Thierry
On Fri, 23 Dec 2016 14:50:38 +0100
Willy Tarreau wrote:
> On Fri, Dec 23, 2016 at 02:37:13PM +0100, thierry.fourn...@arpalert.org wrote:
>
Hi Maksim,
On Fri, Dec 23, 2016 at 12:59:05PM +0300, ?? wrote:
> Hi!
>
> Since I've installed 1.7.1 version of haproxy over 1.6.10 ??? it stopped
> working with ipv6-only backends (no A-record in DNS at all, only ),
> even with USE_GETADDRINFO=1 set. Haproxy
On Fri, Dec 23, 2016 at 03:44:15PM +0100, William Lallemand wrote:
> In systemd mode (-Ds), the master haproxy process is waiting for each
> child to exit in a specific order. If a process die when it's not his
> turn, it will become a zombie process until every processes exit.
(...)
Applied,
Hi everyone,
i'm using a nbproc > 1 configuration for ssl offloading :
listen web_tls
mode http
bind *:443 ssl crt whatever.pem process 2
bind *:443 ssl crt whatever.pem process 3
../..
server web_plain u...@plain.sock send-proxy-v2-ssl
frontend web_plain
bind*:80
On Fri, Dec 23, 2016 at 02:37:13PM +0100, thierry.fourn...@arpalert.org wrote:
> thanks Willy for the idea. I will write a patch ASAP, but. why a 32bits
> cast and not a 64 bit cast ?
First because existing code uses this already and it works. Second because
the 64-bit check might be more
On Wed, 21 Dec 2016 15:44:49 +0100
Willy Tarreau wrote:
> Hi guys,
>
> so I've looked a little bit at this and can propose something different.
>
> On Wed, Dec 14, 2016 at 02:59:50PM +, David CARLIER wrote:
> > Hi,
> >
> > On 14 December 2016 at 14:48,
Hi!
Since I've installed 1.7.1 version of haproxy over 1.6.10 – it stopped
working with ipv6-only backends (no A-record in DNS at all, only ),
even with USE_GETADDRINFO=1 set. Haproxy says, that it 'could not resolve
address' and exits on a parsing phase.
The problem is in fuction
Hi Willy,
On 12/23/2016 12:10 AM, Willy Tarreau wrote:
>
> Hmmm I think that makes sense indeed. Just out of curiosity in what
> situation did you encounter this condition ? A reload maybe ?
We have some business logic which tries to detect if there are any
usable members in the backend before
16 matches
Mail list logo