Re: Bug: DNS changes in 1.7.3+ break UNIX socket stats in daemon mode with resolvers on FreeBSD
On Thu, May 18, 2017 at 10:22:17AM -0400, Jim Pingle wrote: > On 05/12/2017 09:50 AM, Willy Tarreau wrote: > > On Fri, May 12, 2017 at 10:20:56AM +0200, Frederic Lecaille wrote: > >> Here is a more well-formed patch. > >> Feel free to amend the commit message if not enough clear ;) > > > > It was clear enough, thanks. I added the mention of the faulty commit, > > that helps tracking backports and credited Jim and Lukas for the > > investigations. > > Thanks for getting this in! Everything still appears to be good here > running with that patch applied. > > I don't see it in the 1.7 tree yet, will it be backported there? Yes, all fixes are backported, but since it takes time, I generally do that in batches. > Is there an ETA on 1.7.6? Not particularly, but *maybe* next week (I probably said this last week already). Willy
Re: SOLVEDRe: haproxy + RDP
Hi Antonio Trujillo Carmona. cool thanks for sharing. Regards Aleks Antonio Trujillo Carmona have written on Wed, 24 May 2017 09:01:16 +0200: > El 16/05/17 a las 23:17, Aleksandar Lazic escribió: > Hi Antonio Trujillo Carmona. > > > > Antonio Trujillo Carmona have written on Mon, 15 May 2017 08:40:16 > > +0200: > > > > El 12/05/17 a las 11:55, Aleksandar Lazic escribió: > >> Hi Antonio Trujillo Carmona. > >>> > >>> Antonio Trujillo Carmona have written on Fri, 12 May 2017 10:23:59 > >>> +0200: > >>> > >>> El 11/05/17 a las 15:06, Aleksandar Lazic escribió: > .../ > > How about to activate the 'option tcp-check' as mentioned in the > > Warning? > > In the config below is it's commented, any reason why? > > > > It's also active in the doc which you maybe know. > > > > https://www.haproxy.com/doc/aloha/7.0/deployment_guides/microsoft_remote_desktop_services.html > > > > Does this changes anything? > > ok cleaing up a liter I try: > frontend RDP > mode tcp > bind *:3389 > timeout client 1h > tcp-request inspect-delay 5s > tcp-request content accept if RDP_COOKIE > default_backend bk_rdp > # > backend bk_rdp > mode tcp > balance leastconn > #balance rdp_coockie > timeout server 1h > timeout connect 4s > log global > option tcplog > stick-table type string len 32 size 10k expire 1h peers > pares stick on rdp_cookie(msthash) > # persist rdp-cookie > option tcp-check > # option ssl-hello-chk > # option tcpka > tcp-check connect port 3389 ssl > > # server gr43sterminal01 10.104.22.142:3389 weight 1 check > verify none inter 2000 rise 2 fall 3 > # server gr43sterminal02 10.104.23.141:3389 weight 1 check > verify none inter 2000 rise 2 fall 3 > # > default-server inter 3s rise 2 fall 3 > server gr43sterminal01 10.104.22.142:3389 weight 1 check > server gr43sterminal02 10.104.23.141:3389 weight 1 check > > And I got: > [ALERT] 131/100222 (8564) : Proxy 'bk_rdp', server > 'gr43sterminal01' [/etc/haproxy/haproxy.cfg:189] verify is > enabled by default but no CA file specified. If you're running > on a LAN where you're certain to trust the server's certificate, > please set an explicit 'verify none' statement on the 'server' > line, or use 'ssl-server-verify none' in the global section to > disable server-side verifications by default. [ALERT] 131/100222 > (8564) : Proxy 'bk_rdp', server > 'gr43sterminal02' [/etc/haproxy/haproxy.cfg:190] verify is > enabled by default but no CA file specified. If you're running > on a LAN where you're certain to trust the server's certificate, > please set an explicit 'verify none' statement on the 'server' > line, or use 'ssl-server-verify none' in the global section to > disable server-side verifications by default. [ALERT] 131/100222 > (8564) : Fatal errors found in configuration. > > So I try adding verify none in server line > > and haproxy see both server up (but one is down). > I try withou ssl: > > tcp-check connect port 3389 > server gr43sterminal01 10.104.22.142:3389 weight 1 check > server gr43sterminal02 10.104.23.141:3389 weight 1 check > > but the result is the same haproxy see both server up (but one is > down) > > only if I leve only option tcp-check (or none) it seem work > > > # > # persist rdp-cookie > option tcp-check > # option ssl-hello-chk > # option tcpka > # tcp-check connect port 3389 ssl > # tcp-check connect port 3389 > > # server gr43sterminal01 10.104.22.142:3389 weight 1 check > verify none inter 2000 rise 2 fall 3 > # server gr43sterminal02 10.104.23.141:3389 weight 1 check > verify none inter 2000 rise 2 fall 3 > # > default-server inter 3s rise 2 fall 3 > server gr43sterminal01 10.104.22.142:3389 weight 1 check > server gr43sterminal02 10.104.23.141:3389 weight 1 check > ## > > > output: > > [WARNING] 131/102105 (8773) : Server bk_rdp/gr43sterminal01 is > DOWN, reason: Layer4 timeout, info: " at initial connection step > of tcp-check", check duration: 3001ms. 1 active and 0 backup > servers left. 0 sessions active, 0 requeued, 0 remaining in > queue. So finally it works. > >>> > >>> Regards > >>> Aleks > >>> But in that mode it check server available,
Re: Is it possible to disable SSL if not certificates are found?
Hi Simos Xenitellis. Simos Xenitellis have written on Mon, 22 May 2017 11:28:41 +0300: > Hi All, > > I am trying to automate some tasks with adding multiple https > (LetsEncrypt) websites, > and using HAProxy as a TLS Termination Proxy. > > The problem is that when you start off with an empty server, there are > no certificates yet, > and it is not possible to have "bind *:443 ssl crt > /etc/haproxy/certs/..." in haproxy.cfg. > > LetsEncrypt can work with http, so it could easily use the "bind *:80" > front-end in the beginning. > > Is there a way to express "If no certificates are found in > /etc/haproxy/certs/, then do not bind *:443"? I don't know such a 'lazy read' option in haproxy, but this feature sounds interesting. Do you have any patches available yet or are you willing to provide one? > Simos Regards Aleks
Re: New feature proposal: Add support for decompressing proxyed gziped requests
Hi Vasileios Kyrillidis. Vasileios Kyrillidis have written on Tue, 23 May 2017 18:23:07 +0200: > Hello, > > We would like to add support for decompressing proxyed gziped > requests (i.e. those with "Content-Encoding: gzip") to HAProxy. Would > there be interest in such a feature? i.e. is it likely it could be > accepted into the main repo? Is anyone else already working on such a > feature? > > Currently HAProxy supports compressing outgoing responses where the > client has indicated it supports receiving them. It does not yet > support receiving requests that are compressed and decompressing them > before sending them to a backend. This is not something commonly seen > with browsers but is not uncommon when dealing with web service > calls, which is our use case. > > It is envisioned that this feature would be off by default and > require explicit enabling. Sounds interesting. Do you have any patches available yet or are you willing to provide one? > Regards, > Vasilis Regards Aleks
Re: [PATCHES] Major DNS changes
Hi Baptiste. Baptiste have written on Wed, 24 May 2017 11:34:31 +0200: > Hi all, > > Over the last few weeks, I entirely reworked the internal resolver of > HAProxy to make it more flexible. > The main driver for this is to add more features related to DNS > use-cases (SRV records, scale in / scale out a backend, DNS > converter, etc...) and also to make it more efficient internaly and > more friendly with DNS servers ;) > > With this in mind, I performed the following changes: > - DNS tasks are now autonomous, they are not triggered by the health > check any more, this means we can enable DNS resolution without > enabling health monitoring on a server > - DNS responses are now kept in memory, when they are not an error... > so many servers using the same hostname resolution will use a > response in the cache if it is fresh enough > - full "anonymisation" of the requesters. Up to now, DNS code was > though for servers only (well layers were pretty well defined). I > added an abstraction layer between the resolution and the requester, > so the requester could be of any HAProxy internal type (backend, > bind, ...). > - management of requester through queues: 2 queues are available: the > run queue and the wait queue. If a requester needs a resolution, he > will register himself to the run queue, and if he is the first one, > then the resolution is triggered > - a pool of resolution is now linked to a resolvers section. Memory is > allocated at configuration parsing time. If the pool is too small for > your configuration, an error is returned. > > I still have a few minor things to work on, but since HAProxy Tech > guys needs my code to move forward on their contribution, I'm > publishing it right now. Wow great work. I have take a look into the code and have just some questions about calloc in [PATCH 03/11] & [PATCH 07/11] In the function dns_alloc_resolution is calloc used, would the use of haproxy pools bring any benefit? [PATCH 08/11] +static int dns_cache_size = 1024; /* arbitrary DNS cache size */ For the future maybe there could be a glolbal.tune.dns-cache-size or something similar. Do I have understand the code right that you have per resolver a cache and this resolver belongs to a backend/frontend. So in case several backends have the same server names all resolver requests this server individual. There is no 'global dns cache' for all or I missed something. > Please give it a try and report any issues you may spot :) > > Baptiste Regards Aleks
Re: HAProxy won't shut down
Hi Patrick, On Tue, May 23, 2017 at 01:49:42PM -0400, Patrick Hemmer wrote: (...) > haproxy 28856 root1u IPv4 420797940 0t0TCP > 10.0.33.145:35754->10.0.33.147:1029 (CLOSE_WAIT) > haproxy 28856 root2u IPv4 420266351 0t0TCP > 10.0.33.145:52898->10.0.33.147:1029 (CLOSE_WAIT) > haproxy 28856 root3r REG0,30 4026531956 net > haproxy 28856 root4u IPv4 422150834 0t0TCP > 10.0.33.145:38874->10.0.33.147:1029 (CLOSE_WAIT) These ones are very interesting. > All those sockets have been sitting there like that for a long time. > The :1029 sockets are "peer" sync connections. That's what I was about to suspect. Fred has started investigating a similar report, but these ones are rare so it's possible that combined with your report it can help spot the root cause. I'm pretty sure we have a bug somewhere in the state machine where we forget to re-enable polling for reads in the peers, but we haven't found it yet :-/ At least your analysis tends to confirm this direction. I'll let Fred contact you if he estimates he needs more info. thanks! Willy
SOLVEDRe: haproxy + RDP
El 16/05/17 a las 23:17, Aleksandar Lazic escribió: Hi Antonio Trujillo Carmona. Antonio Trujillo Carmona have written on Mon, 15 May 2017 08:40:16 +0200: El 12/05/17 a las 11:55, Aleksandar Lazic escribió: Hi Antonio Trujillo Carmona. Antonio Trujillo Carmona have written on Fri, 12 May 2017 10:23:59 +0200: El 11/05/17 a las 15:06, Aleksandar Lazic escribió: .../ How about to activate the 'option tcp-check' as mentioned in the Warning? In the config below is it's commented, any reason why? It's also active in the doc which you maybe know. https://www.haproxy.com/doc/aloha/7.0/deployment_guides/microsoft_remote_desktop_services.html Does this changes anything? ok cleaing up a liter I try: frontend RDP mode tcp bind *:3389 timeout client 1h tcp-request inspect-delay 5s tcp-request content accept if RDP_COOKIE default_backend bk_rdp # backend bk_rdp mode tcp balance leastconn #balance rdp_coockie timeout server 1h timeout connect 4s log global option tcplog stick-table type string len 32 size 10k expire 1h peers pares stick on rdp_cookie(msthash) # persist rdp-cookie option tcp-check # option ssl-hello-chk # option tcpka tcp-check connect port 3389 ssl # server gr43sterminal01 10.104.22.142:3389 weight 1 check verify none inter 2000 rise 2 fall 3 # server gr43sterminal02 10.104.23.141:3389 weight 1 check verify none inter 2000 rise 2 fall 3 # default-server inter 3s rise 2 fall 3 server gr43sterminal01 10.104.22.142:3389 weight 1 check server gr43sterminal02 10.104.23.141:3389 weight 1 check And I got: [ALERT] 131/100222 (8564) : Proxy 'bk_rdp', server 'gr43sterminal01' [/etc/haproxy/haproxy.cfg:189] verify is enabled by default but no CA file specified. If you're running on a LAN where you're certain to trust the server's certificate, please set an explicit 'verify none' statement on the 'server' line, or use 'ssl-server-verify none' in the global section to disable server-side verifications by default. [ALERT] 131/100222 (8564) : Proxy 'bk_rdp', server 'gr43sterminal02' [/etc/haproxy/haproxy.cfg:190] verify is enabled by default but no CA file specified. If you're running on a LAN where you're certain to trust the server's certificate, please set an explicit 'verify none' statement on the 'server' line, or use 'ssl-server-verify none' in the global section to disable server-side verifications by default. [ALERT] 131/100222 (8564) : Fatal errors found in configuration. So I try adding verify none in server line and haproxy see both server up (but one is down). I try withou ssl: tcp-check connect port 3389 server gr43sterminal01 10.104.22.142:3389 weight 1 check server gr43sterminal02 10.104.23.141:3389 weight 1 check but the result is the same haproxy see both server up (but one is down) only if I leve only option tcp-check (or none) it seem work # # persist rdp-cookie option tcp-check # option ssl-hello-chk # option tcpka # tcp-check connect port 3389 ssl # tcp-check connect port 3389 # server gr43sterminal01 10.104.22.142:3389 weight 1 check verify none inter 2000 rise 2 fall 3 # server gr43sterminal02 10.104.23.141:3389 weight 1 check verify none inter 2000 rise 2 fall 3 # default-server inter 3s rise 2 fall 3 server gr43sterminal01 10.104.22.142:3389 weight 1 check server gr43sterminal02 10.104.23.141:3389 weight 1 check ## output: [WARNING] 131/102105 (8773) : Server bk_rdp/gr43sterminal01 is DOWN, reason: Layer4 timeout, info: " at initial connection step of tcp-check", check duration: 3001ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. So finally it works. Regards Aleks But in that mode it check server available, not service, if RDP service is down haproxy don't detect it. Maybe you will need some tcp-check squence to check the service. http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#4.2-tcp-check%20send http://cbonte.github.io/haproxy-dconv/1.5/configuration.html#4.2-tcp-check%20send-binary I have found a perl script which checks the rdp maybe this will help you to find the right sequence. https://github.com/portcullislabs/rdp-sec-check/blob/master/rdp-sec-check.pl Regards Aleks Finally it work. The configuration last in: # frontend RDP mode tcp bind *:3389 timeout client 1h tcp-request inspect-delay 25s
