Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST and data corrupted by extra connection close
Le 16/04/2020 à 07:55, Kiran Gavali a écrit : Hi Christopher, Thank you or updating the patch. I have seen the "http-check send" directive you have added in the patch and agree with your point that the syntax must be compatible with the rework in HTTP checks for H1/H2. As for the reg-test, sorry for my misinterpretation, I thought you wanted me to run the test suite to ensure that the patch doesn’t break any existing functionality. Nevertheless, I can now see that you have already created http-check-send.vtc and included it in the patch file. So, I hope it is right for me to now presume that the patch is complete and there’s nothing actionable at my end. Please do let me know if any further action is required from my end in this regard. Hi, I've finally pushed this patch ! Better late that never. I will backport it to 2.1 and 2.0 for now. But I guess it could be backported as far as 1.7. Thanks, -- Christopher Faulet
Distance Learning Package: Bid Writing
NFP WORKSHOPS 18 Blake Street, York YO1 8QG Affordable Training Courses for Charities, Schools & Public Sector Organisations This email has been sent to haproxy@formilux.org CLICK TO UNSUBSCRIBE FROM LIST Alternatively send a blank e-mail to unsubscr...@nfpmail1902.co.uk quoting haproxy@formilux.org in the subject line. Unsubscribe requests will take effect within seven days. Bid Writing: Distance Learning Package Learn at your home or office. No need to travel anywhere. Delivered by e-mail. The package includes all the topics from our popular Bid Writing: The Basics and Bid Writing: Advanced live workshops plus eight sample funding bids. Once you have covered all the materials you can submit up to five questions by email. TOPICS COVERED Do you know the most common reasons for rejection? Are you gathering the right evidence? Are you making the right arguments? Are you using the right terminology? Are your numbers right? Are you learning from rejections? Are you assembling the right documents? Do you know how to create a clear and concise standard funding bid? Are you communicating with people or just excluding them? Do you know your own organisation well enough? Are you thinking through your projects carefully enough? Do you know enough about your competitors? Are you answering the questions funders will ask themselves about your application? Are you submitting applications correctly? Are you applying to the right trusts? Are you applying to enough trusts? Are you asking for the right amount of money? Are you applying in the right ways? Are your projects the most fundable projects? Are you carrying out trust fundraising in a professional way? Are you delegating enough work? Are you highly productive or just very busy? Are you looking for trusts in all the right places? How do you compare with your competitors for funding? Is the rest of your fundraising hampering your bids to trusts? Do you understand what trusts are ideally looking for? TRAINEES Staff members, volunteers, trustees or board members of charities, schools or public sector organisations who intend to submit grant funding applications to charitable grant making trusts and foundations. People who provide advice to these organisations may also order. FORMAT The distance learning package consists of a 201 page text document in PDF format plus 8 real successful bids totalling 239 pages in PDF format. There is no audio or video content. This is not an online course. TIME COMMITMENT Trainees should expect to spend around eight hours reading through all the materials, preparing their "to do" list for the months ahead, writing or revising their standard funding bid, submitting questions by email and processing responses. TERMS Training materials are for use only by the trainee named on the invoice. Training materials may not be copied, circulated or published. ORDER YOUR PACKAGE NOW The cost of the Bid Writing: Distance Learning Package is £190 per trainee. To order please email ord...@nfpmail1902.co.uk with 1) The name of the trainee. 2) The email address to send the materials to. 3) The name of your organisation. 4) The postal address of your organisation. 5) A purchase order number if required. We will send you an invoice within 24 hours containing BACS electronic payment details. Once we receive payment the materials will be emailed to the specifed email address within 24 hours. Please check your spam folder to ensure you receive everything. QUESTIONS If you have a question please e-mail questi...@nfpmail1902.co.uk You will usually receive a response within 24 hours. We are unable to accept questions by phone. FEEDBACK FROM PAST ATTENDEES AT OUR LIVE WORKSHOPS I must say I was really impressed with the course and the content. My knowledge and confidence has increased hugely. I got a lot from your course and a lot of pointers! I can say after years of fundraising I learnt so much from your bid writing course. It was a very informative day and for someone who has not written bids before I am definitely more confident to get involved with them. I found the workshops very helpful. It is a whole new area for me but the information you imparted has given me a lot of confidence with the direction I need to take and for that I am very grateful. I found the day very informative and it gave me confidence to take on this aspect of work that I had been apprehensive of. I enjoyed the session and found it valuable. So much relevant, practical information all passed on in a way which I was able to follow. All greatly enhanced by your sense of humour. It was a useful course and your examples real or otherwise helped to make it practical. Many thanks. The morning just flew by - always a good sign! I enjoyed the course and learnt a lot. I will begin putting this into practice.
Re: [ANNOUNCE] haproxy-2.2-dev6
On Mon, Apr 27, 2020 at 11:32:15PM +0500, ??? wrote: > How haproxy.org is managed, some manual update? Can we run git master there? Yep the upgrade is manual, with an automatic revert to the previous version in case of sudden death (has happened quite a few times in the past, not much on 2.2-dev yet). I do prefer to let it run for long because this is the only place where we can confirm the stability over long uptimes. I usually let it last 50-100 days before upgrading, even with known bugs that don't affect the deployment. And as you can see it occasionally pays off ;-) For testing the latest master we already have development, reg tests, CI etc. Cheers, Willy
Re: [ANNOUNCE] haproxy-2.2-dev6
Hi William, On Mon, Apr 27, 2020 at 08:34:48PM +0200, William Dauchy wrote: > If this can help, the issue is possibly between dev5 and dev6. We have > been following quite closely the dev releases, but we had to revert > from dev6 to dev5 as it produced issues on our side - where it is > perfectly running fine on dev5. I did not reported it earlier (shame > on me) because I did not had the time to investigate and collect some > more details. I however can do that in the following days if > necessary; be I believe you now have traces on your side as well. Thanks very much for these extra details, this will definitely help. Please don't waste your time for now, I have various "show *" commands from the CLI and I generated a core file so I should have plenty to investigate. Thanks, Willy
[PATCH] remove reg-tests/checks/tcp-check-ssl.vtc on CentOS 6
Hello, new reg-test requires ALPN which is not available on CentOS 6. Cheers, Ilya Shipitcin From f6edcbacc58ccbfe47f25fccfe6a5743fcae1122 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Mon, 27 Apr 2020 23:35:13 +0500 Subject: [PATCH] CI: cirrus-ci: remove reg-tests/checks/tcp-check-ssl.vtc on CentOS 6 reg-tests/checks/tcp-check-ssl.vtc requires ALPN which is not available on CentOS 6 --- .cirrus.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.cirrus.yml b/.cirrus.yml index 2d26952c0..07e1bb285 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -26,6 +26,6 @@ centos_6_task: - make CC=cc V=1 TARGET=linux-glibc-legacy USE_ZLIB=1 USE_PCRE=1 USE_OPENSSL=1 - ./haproxy -vv - ldd haproxy -# remove alpn reg-test (CentOS 6 does not support alpn) -- rm reg-tests/connection/proxy_protocol_random_fail.vtc +# remove some reg-tests (CentOS 6 does not support alpn) +- rm reg-tests/connection/proxy_protocol_random_fail.vtc reg-tests/checks/tcp-check-ssl.vtc - env VTEST_PROGRAM=../vtest/vtest make reg-tests || (for folder in /tmp/*regtest*/vtc.*; do cat $folder/INFO $folder/LOG; done && exit 1) -- 2.25.4
Re: [ANNOUNCE] haproxy-2.2-dev6
Hello Willy, On Mon, Apr 27, 2020 at 7:29 PM Willy Tarreau wrote: > just a quick note, be careful with -dev6, monitor your FDs from time > to time. Today it caused an outage on haproxy.org after all FDs were > in use. Sadly we had skipped a number of -dev in the past, jumping > from something between dev2 and dev3 to dev6, so the breakage might > have happened anywhere in between. > The symptoms were that the CLI was still working pretty fine, "show fd" > would show a lot of FD and "show sess" would show only the CLI's socket. > A reload managed to get my stats request immediately accepted by the new > process so that proves that it was waiting in the accept queue, thus > accept() was refraining from doing its work. > For now that's all I know, but I do have traces so I hope we'll quickly > figure where it comes from. > I just wanted to let you know given that others might start to run a few > -dev releases in production and such issues are very nasty to detect :-/ If this can help, the issue is possibly between dev5 and dev6. We have been following quite closely the dev releases, but we had to revert from dev6 to dev5 as it produced issues on our side - where it is perfectly running fine on dev5. I did not reported it earlier (shame on me) because I did not had the time to investigate and collect some more details. I however can do that in the following days if necessary; be I believe you now have traces on your side as well. -- William
Re: [ANNOUNCE] haproxy-2.2-dev6
How haproxy.org is managed, some manual update? Can we run git master there? On Mon, Apr 27, 2020, 10:30 PM Willy Tarreau wrote: > Hi all, > > just a quick note, be careful with -dev6, monitor your FDs from time > to time. Today it caused an outage on haproxy.org after all FDs were > in use. Sadly we had skipped a number of -dev in the past, jumping > from something between dev2 and dev3 to dev6, so the breakage might > have happened anywhere in between. > > The symptoms were that the CLI was still working pretty fine, "show fd" > would show a lot of FD and "show sess" would show only the CLI's socket. > A reload managed to get my stats request immediately accepted by the new > process so that proves that it was waiting in the accept queue, thus > accept() was refraining from doing its work. > > For now that's all I know, but I do have traces so I hope we'll quickly > figure where it comes from. > > I just wanted to let you know given that others might start to run a few > -dev releases in production and such issues are very nasty to detect :-/ > > Willy > >
Re: [ANNOUNCE] haproxy-2.2-dev6
Hi all, just a quick note, be careful with -dev6, monitor your FDs from time to time. Today it caused an outage on haproxy.org after all FDs were in use. Sadly we had skipped a number of -dev in the past, jumping from something between dev2 and dev3 to dev6, so the breakage might have happened anywhere in between. The symptoms were that the CLI was still working pretty fine, "show fd" would show a lot of FD and "show sess" would show only the CLI's socket. A reload managed to get my stats request immediately accepted by the new process so that proves that it was waiting in the accept queue, thus accept() was refraining from doing its work. For now that's all I know, but I do have traces so I hope we'll quickly figure where it comes from. I just wanted to let you know given that others might start to run a few -dev releases in production and such issues are very nasty to detect :-/ Willy
Suggestion: better defaults for mysql-check healthcheck (post-41 enabled)
Hello, This is my first message here, so: hi everyone :) And thanks to everyone involved in the Haproxy project ! I wanted to give an idea of a (minor) better default that should be improved: => enable by default the "post-41" parameter in *mysql-check* Today, it's off by default, so Haproxy is using the "very very old" authentication method (before MySQL 4.1) to do the health-checks. But since MySQL 4.1 is now *16* years old (stable in 2004), we are fairly sure that all new installations of Haproxy will certainly be used with a "recent-enough" (>= 4.1) mysql version that supports the new protocol. NB: of course, I know it's a breaking-change, so it needs to be properly packaged in the right version. For the anecdote, I'm writing this email because of: 1) What happened to me today: I was debugging a slightly complex (but temporary) setup of an Haproxy being in front of MaxScale proxies (mysql-specialized L7 LB) which are themself forwarding to mysql daemons. And the haproxy had "Layer7 wrong status: #08S01Bad handshake" errors. After some hours of tests, I understood that my Haproxy was doing its health-checks using the default config, so "very-old auth protocol", but MaxScale only accepts the "new" protocol. It worked properly after enabling the "post-41" option :) If Haproxy had the "post-41" option enabled by default, I wouldn't have had the issue. 2) The HAProxyConf 2019 Keynote in which Willy T. talked about "Better defaults" that I saw a few months ago. Because I kinda recognized my issue as a (fairly minor) example of such "usability tests". What do you think ? -- Florent R.
Re: random 502's
Hi Baptiste, i'll add the global maxconn, but according to stats link we never go over 40 ... We do use keepalive, but i'll need to adjust our logs to see if this is the first or some other request within the keepalive session. We seem to have managed to fix the problem. By setting "no option http-use-htx" in the global section the random 502's disappeared. As we didn't have this option in 1.6 i guess we won't miss out much, but i still don't understand why this goes wrong. thank you for your swift response! Yves On Mon, Apr 27, 2020 at 2:10 PM Baptiste wrote: > Hi, > > first, you need to set a global maxconn to 3000, otherwise it may be > limited by your system. In any case, the frontend maxconn will never be > reachable with your current config. > do you know if that happens on keep alive requests or if this happens on > the first request of the connection? Do you have some timers provided by > apache for this session? > how many connections are established between apache and haproxy? > > Baptiste > > >
Re: Server weight in server-template and consul dns
On Mon, Apr 27, 2020 at 10:14 PM Baptiste wrote: > > > On Mon, Apr 27, 2020 at 3:05 AM Igor Cicimov < > ig...@encompasscorporation.com> wrote: > >> Hi, >> >> On Mon, Apr 20, 2020 at 10:25 PM Igor Cicimov < >> ig...@encompasscorporation.com> wrote: >> >>> Hi, >>> >>> I have the following template in a server backend: >>> >>> server-template tomcats 10 _tomcat._tcp.service.consul resolvers consul >>> resolve-prefer ipv4 check >>> >>> This is the SRV records resolution: >>> >>> # dig +short @127.0.0.1 -p 8600 _tomcat._tcp.service.consul SRV >>> 1 10 8080 ip-10-20-3-21.node.dc1.consul. >>> 1 10 8080 ip-10-20-4-244.node.dc1.consul. >>> >>> The server's weight reported by haproxy is 1 where I expected to see 10. >>> Just to clarify, is this expected or there is a mixup between priority and >>> weight? >>> >>> Thanks, >>> Igor >>> >>> >> Giving this another try. Maybe Baptiste can help to clarify which part of >> the SRV record is considered as server weight, the record priority or the >> record weight? >> >> Thanks, >> Igor >> >> >> > Hi, > > This is the record weight. > There is a trick for weights: DNS weight range if from 0 to 65535 while > HAProxy weight is from 0 to 256. So basically, your DNS weight is divided > by 256 before being applied. > so adjust your DNS weight accordingly. > > Baptiste > Thanks Baptiste, works as per your comment! Cheers, Igor
Re: Server weight in server-template and consul dns
On Mon, Apr 27, 2020 at 3:05 AM Igor Cicimov wrote: > Hi, > > On Mon, Apr 20, 2020 at 10:25 PM Igor Cicimov < > ig...@encompasscorporation.com> wrote: > >> Hi, >> >> I have the following template in a server backend: >> >> server-template tomcats 10 _tomcat._tcp.service.consul resolvers consul >> resolve-prefer ipv4 check >> >> This is the SRV records resolution: >> >> # dig +short @127.0.0.1 -p 8600 _tomcat._tcp.service.consul SRV >> 1 10 8080 ip-10-20-3-21.node.dc1.consul. >> 1 10 8080 ip-10-20-4-244.node.dc1.consul. >> >> The server's weight reported by haproxy is 1 where I expected to see 10. >> Just to clarify, is this expected or there is a mixup between priority and >> weight? >> >> Thanks, >> Igor >> >> > Giving this another try. Maybe Baptiste can help to clarify which part of > the SRV record is considered as server weight, the record priority or the > record weight? > > Thanks, > Igor > > > Hi, This is the record weight. There is a trick for weights: DNS weight range if from 0 to 65535 while HAProxy weight is from 0 to 256. So basically, your DNS weight is divided by 256 before being applied. so adjust your DNS weight accordingly. Baptiste
Re: random 502's
Hi, first, you need to set a global maxconn to 3000, otherwise it may be limited by your system. In any case, the frontend maxconn will never be reachable with your current config. do you know if that happens on keep alive requests or if this happens on the first request of the connection? Do you have some timers provided by apache for this session? how many connections are established between apache and haproxy? Baptiste
