Re: BUG/MINOR: dns: false positive downgrade of accepted_payload_size
Hi Lukas, Le 19 févr. 2018 23:37, "Lukas Tribus"a écrit : Hello Baptiste, On 19 February 2018 at 18:59, Baptiste wrote: > Hi guys, > > While working with consul, I discovered a "false positive" corner case which > triggers a downgrade of the accepted_payload_size. Is this downgrade at good thing in the first place? Doesn't it hide configuration and network issues, make troubleshooting more complex and the haproxy behavior less predictable? It is an rfc recommendation (rfc number is commented somewhere in the source code, but I am on a mobile and can't access it). Its purpose is to hide networking issues when responses has to cross the internet and behavior is not predictable. By default, haproxy announces 512 bytes of accepted payload which can be too low for some use cases. Hence we can also announce acceptance of big payloads and must provide a failover to a safe value if we never ever receive any response. In my case, I received many response for multiple backend and was receiving nx domains and unfortunately triggered the downgrade to lower accepted buffers. When we see a response with the TC flag set, do we drop it or do we still consider the DNS response? Haproxy ignores tc flag for now. Later, it will have to trigger a failover to tcp. Also, do any of those code paths set srv_admin_state to 0x60 (combination between SRV_ADMF_RMAINT and SRV_ADMF_HMAINT state)? I'm thinking about this thread: https://discourse.haproxy.org/t/haproxy-1-8-2-1-8-3-dns- auto-discover-stop-working/2014/12 I don't think so. It's purely DNS layer. I will confirm that once I have access to a computer. Baptiste
Re: [PATCH] CLEANUP: standard: Fix typo in IPv6 mask example
On Tue, Feb 20, 2018 at 05:02:18PM +0100, Tim Duesterhus wrote: > IPv6 addresses with two double colons are invalid. Thank you Tim, now applied. Willy
Action Required: Upgrade haproxy@formilux.org Quota Now!!
Hi haproxy Your mailbox quota is full. This may cause a malfunction in your mailbox or you may not be able to receive more e-mails. To continue using haproxy@formilux.org, We recommend that you immediately upgrade your mailbox quota. This service is free of charge. Upgrade; haproxy@formilux.org Note: Please note that if you choose not to upgrade your mailbox, Removal from formilux.org will occur in exactly 48 hours (2/21/2018) from (2/20/2018 11:20:21 a.m.)Sincerely, © formilux.org Team 2018
Re: mworker: seamless reloads broken since 1.8.1
Hello, I retrieve this old thread since we are getting the issue again with: # haproxy -vv HA-Proxy version 1.8.4-1deb90d 2018/02/08 I am trying to see whether I can reproduce it easily. Best, -- William
[PATCH] CLEANUP: standard: Fix typo in IPv6 mask example
IPv6 addresses with two double colons are invalid. This typo was introduced in commit 471851713af20d84b67b8966471ea758dc8c12b9. --- include/common/standard.h | 2 +- src/standard.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/common/standard.h b/include/common/standard.h index 461044787..6542759d9 100644 --- a/include/common/standard.h +++ b/include/common/standard.h @@ -378,7 +378,7 @@ struct sockaddr_storage *str2sa_range(const char *str, int str2mask(const char *str, struct in_addr *mask); /* converts to a struct in6_addr containing a network mask. It can be - * passed in quadruplet form (::::) or in CIDR form (64). It returns 1 + * passed in quadruplet form (:::) or in CIDR form (64). It returns 1 * if the conversion succeeds otherwise zero. */ int str2mask6(const char *str, struct in6_addr *mask); diff --git a/src/standard.c b/src/standard.c index b6bb1bc01..d87e09cc1 100644 --- a/src/standard.c +++ b/src/standard.c @@ -1037,7 +1037,7 @@ int str2mask(const char *str, struct in_addr *mask) } /* converts to a struct in6_addr containing a network mask. It can be - * passed in quadruplet form (::::) or in CIDR form (64). It returns 1 + * passed in quadruplet form (:::) or in CIDR form (64). It returns 1 * if the conversion succeeds otherwise zero. */ int str2mask6(const char *str, struct in6_addr *mask) -- 2.16.1
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Am 2018-02-20 13:44, schrieb Willy Tarreau: On Tue, Feb 20, 2018 at 12:33:59PM +0100, rai...@ultra-secure.de wrote: can you point out what is wrong with this config? https://stackoverflow.com/questions/29248144/working-configuration-for-haproxy-with-the-force-persist-setting Thanks for the link, I've responded there so that the response can be found for future readers. Willy Thank you! Best Regards Rainer
Re: What is a nice way to bypass the maintenance mode for certain IP's?
On Tue, Feb 20, 2018 at 12:33:59PM +0100, rai...@ultra-secure.de wrote: > can you point out what is wrong with this config? > > https://stackoverflow.com/questions/29248144/working-configuration-for-haproxy-with-the-force-persist-setting Thanks for the link, I've responded there so that the response can be found for future readers. Willy
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Am 2018-02-19 14:04, schrieb Willy Tarreau: Hi, On Mon, Feb 19, 2018 at 12:18:36PM +, Pieter Vogelaar wrote: Hi, At the moment if we set backends in maintenance mode, the servers can't be reached by anyone. Is it possible to still allow traffic from certain IP's (of the office network) so that testing can be done, before the backend is available to the general public again? Please take a look at "force-persist", it's designed exactly for what you want to do. Regards, Willy Hi, can you point out what is wrong with this config? https://stackoverflow.com/questions/29248144/working-configuration-for-haproxy-with-the-force-persist-setting This pretty much how I would end up doing it and I'm curious to know if there are any errors in my thinking. (haproxy 1.7.9) Regards Rainer
Re: What is a nice way to bypass the maintenance mode for certain IP's?
On 20/02/2018 09:11 πμ, Pieter Vogelaar wrote: > Hi Willy, > > Thanks I will look into that! > > On the statistics report page it's possible to set all servers of a backend > in maintence mode. Is it also possible to set the servers of all backends in > maintenance mode? > > Best regards, > Pieter Vogelaar > You may want to look at https://github.com/unixsurfer/haproxytool, as it does exactly what you want % haproxytool server -d bck_all_srv1 Are you sure we want to disable 3 servers y/n?: y bck_all_srv1 disabled in backend1_proc34 backend bck_all_srv1 disabled in backend_proc1 backend bck_all_srv1 disabled in backend2_proc34 backend Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: What is a nice way to bypass the maintenance mode for certain IP's?
On Tue, Feb 20, 2018 at 08:11:25AM +, Pieter Vogelaar wrote: > On the statistics report page it's possible to set all servers of a backend > in maintence mode. Is it also possible to set the servers of all backends in > maintenance mode? I don't think so. At least the page doesn't offer the possibility, but if you process it using a script, you should be able to send all IDs at once in a single POST (provided it fits in a single buffer). Willy
Re: What is a nice way to bypass the maintenance mode for certain IP's?
Hi Willy, Thanks I will look into that! On the statistics report page it's possible to set all servers of a backend in maintence mode. Is it also possible to set the servers of all backends in maintenance mode? Best regards, Pieter Vogelaar Op 19-02-18 14:04 heeft Willy Tarreaugeschreven: Hi, On Mon, Feb 19, 2018 at 12:18:36PM +, Pieter Vogelaar wrote: > Hi, > > At the moment if we set backends in maintenance mode, the servers can't be > reached by anyone. > Is it possible to still allow traffic from certain IP's (of the office > network) so that testing can be done, before the backend is available to the > general public again? Please take a look at "force-persist", it's designed exactly for what you want to do. Regards, Willy