Hey guys,
Actually when you get an NXDOMAIN reply you can just stop resolving that
domain. Basically there are 2 types of "negative" replies in DNS:
NODATA: basically this is when you don't get an error (NOERROR in dig),
but not the actual data you are looking for. You might have gotten some
Dear Willy,
Thank you for your additional guidance. Here is the information you
requested:
1) 1.6.1 starts up smoothly and remains stable.
2) To be responsive to your previous query about 1.6.0 with your
fixns.diff patch, it still gives listening socket for ‘listen
haproxystats’ block canno
Oh wonderful - something's come up that would have blocked me from
working on this until next week, so thank you very much for updating
it for me!
On Tue, Oct 20, 2015 at 3:07 PM, Baptiste wrote:
> Hi Andrew,
>
> I've updated your patch quickly so Willy can integrate it.
> I've also updated the c
Hi all,
we've got rid of all the reported bugs since 1.6.0 so it's the right
timing for a new release so that those who got burnt by these bugs
can play with fire again... just kidding, it should be much better now.
The changelog is very small, which is a very good thing for one week
after a dot-
On Tue, Oct 20, 2015 at 10:07:16PM +0200, Baptiste wrote:
> Hi Andrew,
>
> I've updated your patch quickly so Willy can integrate it.
> I've also updated the commit message to follow Lukas recommendations.
Thanks Baptiste, I've merged it and backported it to 1.6.
I'm tempted to issue 1.6.1 right
Hi Susheel,
On Wed, Oct 21, 2015 at 01:29:33AM +0530, Susheel Jalali wrote:
> Dear Willy and Lukas,
>
> Thank you for your guidance. Upon implementing your insights, here is
> the summed up result:
>
> (1) With Willy?s patch HAProxy starts
OK thanks for confirming this.
> (2) But we have to r
On Tue, Oct 20, 2015 at 10:20:50PM +0200, Baptiste wrote:
> On Tue, Oct 20, 2015 at 9:09 PM, Lukas Tribus wrote:
> >> I don't know. I'm always only focused on the combination of user-visible
> >> changes and risks of bugs (which are user-visible changes btw). So if we
> >> can do it without breaki
On Tue, Oct 20, 2015 at 9:09 PM, Lukas Tribus wrote:
>> I don't know. I'm always only focused on the combination of user-visible
>> changes and risks of bugs (which are user-visible changes btw). So if we
>> can do it without breaking too much code, then it can be backported. What
>> we have now i
Hi Andrew,
I've updated your patch quickly so Willy can integrate it.
I've also updated the commit message to follow Lukas recommendations.
Baptiste
On Tue, Oct 20, 2015 at 2:26 PM, Baptiste wrote:
> Hi Andrew,
>
> There is a bug repeated twice in your code.
> In both dns_reset_resolution() and
Dear Willy and Lukas,
Thank you for your guidance. Upon implementing your insights, here is
the summed up result:
(1) With Willy’s patch HAProxy starts
(2) But we have to remove listen haproxystats block, as it still cannot
create listening socket for this listen proxy.
Detailed information y
> I don't know. I'm always only focused on the combination of user-visible
> changes and risks of bugs (which are user-visible changes btw). So if we
> can do it without breaking too much code, then it can be backported. What
> we have now is something which is apparently insufficient to some users
Welcome to Abbexa
We are very excited to welcome you to the Abbexa customer community. We’d
like to let you know that our professional support team is here to help you
anytime via email or phone. They can help you to explore and select the
correct products for your research. We are here to answer e
On Tue, Oct 20, 2015 at 07:36:20PM +0200, Lukas Tribus wrote:
> Hi,
>
>
> >> A simple option in the resolvers section to instruct HAPoxy to not
> >> forgive on NX and failover to next family:
> >> option on-nx-try-next-family
> >
> > I personally find this confusing from the user's point of view.
Hi,
>> A simple option in the resolvers section to instruct HAPoxy to not
>> forgive on NX and failover to next family:
>> option on-nx-try-next-family
>
> I personally find this confusing from the user's point of view.
Agreed, we should have good and safe defaults, and address corner
cases with
On Tue, Oct 20, 2015 at 06:26:38PM +0200, Baptiste wrote:
> > Also, we will have to address the issue that a server may just use
> > a single address-family, therefor we have to fallback between A
> > and , because a NX on a query doesn't mean there are no
> > A records.
>
> Hi Lukas,
>
> Also, we will have to address the issue that a server may just use
> a single address-family, therefor we have to fallback between A
> and , because a NX on a query doesn't mean there are no
> A records.
Hi Lukas,
I do agree on this point.
A simple option in the resolvers section to in
Hi,
On Tue, Oct 20, 2015 at 06:39:17PM +0300, Tufan Gürsu wrote:
> Hi,
>
> We want to use zlib to compress/uncompress tcp data between tcp session.
> There is only compression code for http but not for tcp.I did some
> research and I encountered problem of the lack of chunk size.
> Is there any
Hi,
We want to use zlib to compress/uncompress tcp data between tcp session.
There is only compression code for http but not for tcp.I did some
research and I encountered problem of the lack of chunk size.
Is there any sample or development for this scenario?
We are using stunnel currently. I
Hi,
> Hi Andrew,
>
> There is a bug repeated twice in your code.
> In both dns_reset_resolution() and trigger_resolution(), you use
> "resolution->resolver_family_priority" before it is positioned. This
> may lead to using the last resolution->resolver_family_priority, which
> may be different tha
So I can confirm with your reproducer that it's OK now. I've merged
the proposed fix with copies of your long detailed analysis. Thanks
for being so patient to explain me :-)
We'll have to wait for the last pending DNS fixes and I'll emit 1.6.1
so that we get rid of these annoying early bugs.
See
On Tue, Oct 20, 2015 at 03:00:42PM +0200, Christopher Faulet wrote:
> Le 20/10/2015 14:41, Willy Tarreau a écrit :
> >On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote:
> >>Le 20/10/2015 14:07, Willy Tarreau a écrit :
> >>>On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wro
Le 20/10/2015 14:41, Willy Tarreau a écrit :
On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote:
Le 20/10/2015 14:07, Willy Tarreau a écrit :
On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
Then my understanding is that we should instead proceed differently :
On Tue, Oct 20, 2015 at 02:14:37PM +0200, Christopher Faulet wrote:
> Le 20/10/2015 14:07, Willy Tarreau a écrit :
> >On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
> >>Then my understanding is that we should instead proceed differently :
> >> - the cert is generated. It gets a re
Hi Andrew,
There is a bug repeated twice in your code.
In both dns_reset_resolution() and trigger_resolution(), you use
"resolution->resolver_family_priority" before it is positioned. This
may lead to using the last resolution->resolver_family_priority, which
may be different than the server one.
Le 20/10/2015 14:07, Willy Tarreau a écrit :
On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
Then my understanding is that we should instead proceed differently :
- the cert is generated. It gets a refcount = 1.
- we assign it to the SSL. Its refcount becomes two.
- we tr
On Tue, Oct 20, 2015 at 01:59:52PM +0200, Willy Tarreau wrote:
> Then my understanding is that we should instead proceed differently :
> - the cert is generated. It gets a refcount = 1.
> - we assign it to the SSL. Its refcount becomes two.
> - we try to insert it into the tree. The tree will
Hi Christopher,
On Tue, Oct 20, 2015 at 01:32:57PM +0200, Christopher Faulet wrote:
> >But then how do we know that an SSL_CTX is still in use when we want to
> >evict it from the cache and that we must not free it ? Is it just the
> >fact that between the moment it's picked from the cache using
>
Le 19/10/2015 17:01, Willy Tarreau a écrit :
On Mon, Oct 19, 2015 at 03:06:44PM +0200, Christopher Faulet wrote:
OK so the unused objects in the tree have a refcount of 1 while the used
ones have 2 or more, thus the refcount is always valid. Good that also
means we must not test if the tree is n
On 20/10/2015 12:49 μμ, SL wrote:
> Hi,
>
> New 1.6 features look interesting from the news item. Is there a
> comprehensive description of the new features anywhere?
>
> Thanks
>
> S
There is this:
http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy-1-6/
Cheers,
Pavlos
signature.asc
Hi,
New 1.6 features look interesting from the news item. Is there a
comprehensive description of the new features anywhere?
Thanks
S
Hi Robin,
[merging your reply and Lukas']
On Tue, Oct 20, 2015 at 08:59:27AM +0200, Robin Geuze wrote:
> Hey Willy,
>
> Recursors are not required to recurse when serving an ANY query. ANY
> query means that you ask a server (either recursor or auth) for
> everything it has on label x. If it has
On Tue, Oct 20, 2015 at 11:20:12AM +0200, Willy Tarreau wrote:
> On Tue, Oct 20, 2015 at 10:54:58AM +0200, Lukas Tribus wrote:
> > > Dear Willy,
> > >
> > > Thank you for your insights. As you advised, below is the output of
> > > haproxy -f ?cfg -db -V.
> >
> > Can you run this through strace (st
On Tue, Oct 20, 2015 at 10:54:58AM +0200, Lukas Tribus wrote:
> > Dear Willy,
> >
> > Thank you for your insights. As you advised, below is the output of
> > haproxy -f ?cfg -db -V.
>
> Can you run this through strace (strace haproxy -f ?cfg -db -V) and
> provide the output.
>
> Also, if you have
Hi Rémi,
On Tue, Oct 20, 2015 at 10:39:16AM +0200, Remi Gacogne wrote:
> Hi,
>
> On 10/19/2015 05:01 PM, Willy Tarreau wrote:
> >> [1] https://www.mail-archive.com/haproxy@formilux.org/msg19962.html
> >> [2] https://www.mail-archive.com/haproxy@formilux.org/msg19995.html
> >
> > Regarding the se
> Dear Willy,
>
> Thank you for your insights. As you advised, below is the output of
> haproxy -f …cfg -db -V.
Can you run this through strace (strace haproxy -f …cfg -db -V) and
provide the output.
Also, if you have the strace output of a successful startup of 1.5.14 for
comparison, that would
Hi,
On 10/19/2015 05:01 PM, Willy Tarreau wrote:
>> [1] https://www.mail-archive.com/haproxy@formilux.org/msg19962.html
>> [2] https://www.mail-archive.com/haproxy@formilux.org/msg19995.html
>
> Regarding the second one, maybe Rémi's review could help. I noticed that
> you used gen_ssl_ctx_ptr_in
Dear Willy,
Thank you for your insights. As you advised, below is the output of
haproxy -f …cfg -db -V.
We are starting HAProxy as root. There is no other application running
on this server dedicated for load balancer. ‘netstat -apon’ suggests
that these ports are not used by any other syste
Hi all,
Thanks a lot for your feedbacks. Really valuable.
I'll discuss with Willy the best approach for the change.
Baptiste
On Mon, Oct 19, 2015 at 11:50 PM, Andrew Hayworth
wrote:
> Hi all -
>
> Just to chime in, we just got bit by this in production. Our dns
> resolver (unbound) does not fo
> Hi Andrew,
>
> On Mon, Oct 19, 2015 at 05:39:58PM -0500, Andrew Hayworth wrote:
>> The ANY query type is weird, and some resolvers don't 'do the legwork'
>> of resolving useful things like CNAMEs. Given that upstream resolver
>> behavior is not always under the control of the HAProxy administrato
Hey Willy,
Recursors are not required to recurse when serving an ANY query. ANY
query means that you ask a server (either recursor or auth) for
everything it has on label x. If it has a CNAME on that label just
returning that is a valid response (just like would happen if you
queried for the
On Tue, Oct 20, 2015 at 12:54:48AM +0530, Susheel Jalali wrote:
> Dear HAProxy Developers:
>
> The following error message appears with HAProxy 1.6.0 after start and
> then the load balancer stops. No haproxy.pid is getting created. The
> same configuration works seamlessly with HAProxy 1.5.14 o
41 matches
Mail list logo
