stable-bot: Bugfixes waiting for a release 2.2 (11), 2.1 (9), 2.0 (7), 1.8 (18)

2020-10-13 Thread stable-bot
Hi,

This is a friendly bot that watches fixes pending for the next haproxy-stable 
release!  One such e-mail is sent periodically once patches are waiting in the 
last maintenance branch, and an ideal release date is computed based on the 
severity of these fixes and their merge date.  Responses to this mail must be 
sent to the mailing list.


Last release 2.2.4 was issued on 2020-09-30.  There are currently 11 patches in 
the queue cut down this way:
- 3 MEDIUM, first one merged on 2020-10-02
- 8 MINOR, first one merged on 2020-10-02

Thus the computed ideal release date for 2.2.5 would be 2020-10-30, which is in 
three weeks or less.

Last release 2.1.9 was issued on 2020-09-30.  There are currently 9 patches in 
the queue cut down this way:
- 4 MEDIUM, first one merged on 2020-09-30
- 5 MINOR, first one merged on 2020-10-08

Thus the computed ideal release date for 2.1.10 would be 2020-10-30, which is 
in three weeks or less.

Last release 2.0.18 was issued on 2020-09-30.  There are currently 7 patches in 
the queue cut down this way:
- 2 MEDIUM, first one merged on 2020-10-08
- 5 MINOR, first one merged on 2020-10-08

Thus the computed ideal release date for 2.0.19 would be 2020-12-03, which is 
in seven weeks or less.

Last release 1.8.26 was issued on 2020-08-03.  There are currently 18 patches 
in the queue cut down this way:
- 8 MEDIUM, first one merged on 2020-08-05
- 10 MINOR, first one merged on 2020-08-03

Thus the computed ideal release date for 1.8.27 would be 2020-10-26, which is 
in two weeks or less.

The current list of patches in the queue is:
 - 2.0, 2.1, 2.2 - MEDIUM  : mux-h2: Don't handle pending read0 too 
early on streams
 - 1.8   - MEDIUM  : h2: report frame bits only for handled 
types
 - 2.1, 2.2  - MEDIUM  : mux-fcgi: Don't handle pending read0 
too early on streams
 - 2.1   - MEDIUM  : ssl: crt-list negative filters don't 
work
 - 1.8   - MEDIUM  : ssl: check OCSP calloc in 
ssl_sock_load_ocsp()
 - 1.8   - MEDIUM  : pattern: fix memory leak in regex 
pattern functions
 - 1.8   - MEDIUM  : map/lua: Return an error if a map is 
loaded during runtime
 - 1.8   - MEDIUM  : pattern: Renew the pattern expression 
revision when it is pruned
 - 1.8   - MEDIUM  : mux-h2: Don't fail if nothing is 
parsed for a legacy chunk response
 - 1.8   - MEDIUM  : ssl: does not look for all SNIs before 
chosing a certificate
 - 1.8   - MEDIUM  : listeners: do not pause foreign 
listeners
 - 2.0, 2.1, 2.2 - MEDIUM  : queue: make pendconn_cond_unlink() 
really thread-safe
 - 1.8   - MINOR   : stats: use strncmp() instead of 
memcmp() on health states
 - 2.2   - MINOR   : http: Fix content-length of the 
default 500 error
 - 1.8   - MINOR   : startup: haproxy -s cause 100% cpu
 - 1.8   - MINOR   : config: Fix memory leak on config 
parse listen
 - 1.8, 2.0, 2.1, 2.2- MINOR   : stats: fix validity of the json 
schema
 - 2.0, 2.1, 2.2 - MINOR   : http-htx: Expect no body for 204/304 
internal HTTP responses
 - 1.8   - MINOR   : ssl: verifyhost is case sensitive
 - 2.0, 2.1, 2.2 - MINOR   : peers: Inconsistency when dumping peer 
status codes.
 - 1.8   - MINOR   : lua: Check argument type to convert it 
to IP mask in arg validation
 - 1.8   - MINOR   : dns: ignore trailing dot
 - 1.8   - MINOR   : threads: work around a libgcc_s issue 
with chrooting
 - 1.8   - MINOR   : lua: Check argument type to convert it 
to IPv4/IPv6 arg validation
 - 2.0, 2.1, 2.2 - MINOR   : mux-h1: Always set the session on 
frontend h1 stream
 - 2.2   - MINOR   : mux-h1: Be sure to only set 
CO_RFL_READ_ONCE for the first read
 - 1.8   - MINOR   : reload: do not fail when no socket is 
sent
 - 2.2   - MINOR   : tcpcheck: Set socks4 and send-proxy 
flags before the connect call
 - 2.0, 2.1, 2.2 - MINOR   : Fix several leaks of 'log_tag' in 
init().

-- 
The haproxy stable-bot is freely provided by HAProxy Technologies to help 
improve the quality of each HAProxy release.  If you have any issue with these 
emails or if you want to suggest some improvements, please post them on the 
list so that the solutions suiting the most users can be found.



Bid Writing and Managing Volunteers workshops via Zoom

2020-10-13 Thread NFP Workshops


NFP WORKSHOPS
18 Blake Street, York YO1 8QG   01133 280988
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...@nfpmail2001.co.uk quoting 
haproxy@formilux.org in the subject line.
Unsubscribe requests will take effect within seven days. 




Bid Writing: The Basics
Online via ZOOM 

COST £95.00

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?

PARTICIPANTS  

Staff members, volunteers, trustees or board members of charities, schools, not 
for profits 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 are also welcome.
Bid Writing: Advanced
Online via ZOOM 

COST £95.00

TOPICS COVERED

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?

PARTICIPANTS  

Staff members, volunteers, trustees or board members of charities, schools, not 
for profits 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 are also welcome.
Dates & Booking Links
BID WRITING: THE BASICS
Mon 26 Oct 2020
10.00 to 12.30Booking Link
Mon 09 Nov 2020
10.00 to 12.30Booking Link
Mon 23 Nov 2020
10.00 to 12.30Booking Link
Mon 07 Dec 2020
10.00 to 12.30Booking Link
BID WRITING: ADVANCED
Tue 27 Oct 2020
10.00 to 12.30Booking Link
Tue 10 Nov 2020
10.00 to 12.30Booking Link
Tue 24 Nov 2020
10.00 to 12.30Booking Link

Tue 08 Dec 2020
10.00 to 12.30Booking Link



Recruiting and Managing Volunteers
Online via ZOOM 

COST £195

TOPICS COVERED

Where do you find volunteers? How do you find the right volunteers? How do you 
attract volunteers? How do you run volunteer recruitment events? How do you 
interview volunteers? How do you train volunteers? How do you motivate 
volunteers? How do you involve volunteers?

How do you recognise volunteer? How do you recognise problems with volunteers? 
How do you learn from volunteer problems? How do you retain volunteers? How do 
you manage volunteers? What about volunteers and your own staff? What about 
younger, older and employee volunteers?

PARTICIPANTS

Staff members, volunteers, trustees or board members of charities, schools, not 
for profits or public sector organisations who intend to recruit volunteers 
into their organisation and then manage those volunteers. People who provide 
advice to these organisations are also welcome.
Dates & Booking Links
RECRUITING AND MANAGING VOLUNTEERS
Wed 11 Nov 2020
10.00 to 16.00Booking Link



FEEDBACK FROM PAST ATTENDEES AT 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 

Re: Unable to get pack file - HTTP 416

2020-10-13 Thread Tim Düsterhus
Willy,

Am 14.10.20 um 00:31 schrieb Willy Tarreau:
> I wouldn't have thought about such a client-side issue, indeed!
> 
> You may be interested in discussing it on the git mailing list:
> 
>  g...@vger.kernel.org
> 
> (not subscription required, just like here).

Yes, thank you. I'll definitely report this in a spare minute.

> Time to get some sleep for me now, have a nice night :-)

But I'll definitely grab some sleep as well first!

Best regards
Tim Düsterhus



Re: Unable to get pack file - HTTP 416

2020-10-13 Thread Willy Tarreau
On Wed, Oct 14, 2020 at 12:24:20AM +0200, Tim Düsterhus wrote:
> I assume the following happened:
> 
> 1. git started downloading the packfile into a temporary file [0]
> 2. git finished the download (I got all the bytes).
> 3. I killed git before it was able to rename the temporary file.
> 4. When trying again git tries to resume the download [1].
> 5. Because I already got the whole file git will send an invalid range.
> 6. nginx does not like it and sends a 416.
> 7. git hard fails instead of retrying without the 'Range' header and
> without taking the 'content-range' response into account.
> 
> So the stuff happening in step (7) would IMO be a git bug.

I wouldn't have thought about such a client-side issue, indeed!

You may be interested in discussing it on the git mailing list:

 g...@vger.kernel.org

(not subscription required, just like here).

> I already copied my local repository to test out whether truncating
> works. I could fix the issue by truncating off the last byte, causing
> git to send a valid range:
> 
> truncate -s 21680736 pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack.temp
> 
> After that worked I did the same on my real repository and called `fsck`
> + `gc` to make sure I did not break anything.

And this validates your theory above. Good job!

> I believe the server side `git gc` would have fixed it as well, because
> the pack file in question is completely gone now. It was replaced by a
> single large pack :-)

Yep indeed!

Time to get some sleep for me now, have a nice night :-)
Willy



Re: Unable to get pack file - HTTP 416

2020-10-13 Thread Tim Düsterhus
Willy,

Am 14.10.20 um 00:14 schrieb Willy Tarreau:
>>> [pid 11946] sendto(9, "GET 
>>> /git/haproxy.git/objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack
>>>  HTTP/1.1\r\nHost: git.haproxy.org\r\nRange: bytes=21680737-\r\nUser-Agent: 
>>> git/2.28.0\r\nAccept: */*\r\n\r\n", 181, MSG_NOSIGNAL, NULL, 0) = 181
>>> [...]
>>> [pid 11946] recvfrom(9, "HTTP/1.1 416 Requested Range Not 
>>> Satisfiable\r\nserver: nginx\r\ndate: Tue, 13 Oct 2020 17:08:56 
>>> GMT\r\ncontent-type: text/html\r\ncontent-length: 206\r\ncontent-range: 
>>> bytes */21680737\r\n\r\n\r\n416 Requested Range Not 
>>> Satisfiable\r\n\r\n416 
>>> Requested Range Not 
>>> Satisfiable\r\nnginx\r\n\r\n\r\n",
>>>  16384, 0, NULL, NULL) = 385
> 
> Now I understand why, it's exactly the file's size:
> 
>   $ ls -l objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack 
>   -r--r--r-- 1 christopher haproxy-stable 21680737 Oct  9 17:49 
> objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack
> 
> However I don't know why it's trying to fetch more of it, which is a good
> reason for this to fail!

I assume the following happened:

1. git started downloading the packfile into a temporary file [0]
2. git finished the download (I got all the bytes).
3. I killed git before it was able to rename the temporary file.
4. When trying again git tries to resume the download [1].
5. Because I already got the whole file git will send an invalid range.
6. nginx does not like it and sends a 416.
7. git hard fails instead of retrying without the 'Range' header and
without taking the 'content-range' response into account.

So the stuff happening in step (7) would IMO be a git bug.

[0]
https://github.com/git/git/blob/4f0a8be78499454eac3985b6e7e144b8376ab0a5/http.c#L2331
[1]
https://github.com/git/git/blob/4f0a8be78499454eac3985b6e7e144b8376ab0a5/http.c#L2350-L2358

> I've just run git fsck and am seeing this:
> 
>   $ git fsck
>   Checking object directories: 100% (256/256), done.
>   Checking objects: 100% (84716/84716), done.
>   dangling commit 309200e7332312e4cd7bfe2d9b21d37a6da9a698
> 
> Christopher faced some permission issues the first time he tried to
> publish his version, so I suspect that the issue is that one file
> failed to be updated and that a pack is probably bad there.
> 
> I've run a git gc and now git fsck is happy. Please try again!
> 

I already copied my local repository to test out whether truncating
works. I could fix the issue by truncating off the last byte, causing
git to send a valid range:

truncate -s 21680736 pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack.temp

After that worked I did the same on my real repository and called `fsck`
+ `gc` to make sure I did not break anything.

I believe the server side `git gc` would have fixed it as well, because
the pack file in question is completely gone now. It was replaced by a
single large pack :-)

Best regards
Tim Düsterhus



Re: Unable to get pack file - HTTP 416

2020-10-13 Thread Willy Tarreau
On Tue, Oct 13, 2020 at 07:13:12PM +0200, Tim Düsterhus wrote:
> Willy,
> 
> Am 13.10.20 um 19:05 schrieb Willy Tarreau:
> > Strange. I can get it from here as a whole (not tested with ranges
> > though). The pack file is recent, it dates a few days ago only. I'll
> > try to investigate further.
> > 
> 
> I've attached 'strace' to 'git fetch'. It appears that I actually have
> the full packfile on disk, because git attempts to the bytes starting at
> the last byte of the pack file (21680737). Apparently the nginx does not
> like that:
> 
> > [pid 11946] sendto(9, "GET 
> > /git/haproxy.git/objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack
> >  HTTP/1.1\r\nHost: git.haproxy.org\r\nRange: bytes=21680737-\r\nUser-Agent: 
> > git/2.28.0\r\nAccept: */*\r\n\r\n", 181, MSG_NOSIGNAL, NULL, 0) = 181
> > [...]
> > [pid 11946] recvfrom(9, "HTTP/1.1 416 Requested Range Not 
> > Satisfiable\r\nserver: nginx\r\ndate: Tue, 13 Oct 2020 17:08:56 
> > GMT\r\ncontent-type: text/html\r\ncontent-length: 206\r\ncontent-range: 
> > bytes */21680737\r\n\r\n\r\n416 Requested Range Not 
> > Satisfiable\r\n\r\n416 
> > Requested Range Not 
> > Satisfiable\r\nnginx\r\n\r\n\r\n",
> >  16384, 0, NULL, NULL) = 385

Now I understand why, it's exactly the file's size:

  $ ls -l objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack 
  -r--r--r-- 1 christopher haproxy-stable 21680737 Oct  9 17:49 
objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack

However I don't know why it's trying to fetch more of it, which is a good
reason for this to fail!

I've just run git fsck and am seeing this:

  $ git fsck
  Checking object directories: 100% (256/256), done.
  Checking objects: 100% (84716/84716), done.
  dangling commit 309200e7332312e4cd7bfe2d9b21d37a6da9a698

Christopher faced some permission issues the first time he tried to
publish his version, so I suspect that the issue is that one file
failed to be updated and that a pack is probably bad there.

I've run a git gc and now git fsck is happy. Please try again!

Thanks!
Willy



Re: Unable to get pack file - HTTP 416

2020-10-13 Thread Tim Düsterhus
Willy,

Am 13.10.20 um 19:05 schrieb Willy Tarreau:
> Strange. I can get it from here as a whole (not tested with ranges
> though). The pack file is recent, it dates a few days ago only. I'll
> try to investigate further.
> 

I've attached 'strace' to 'git fetch'. It appears that I actually have
the full packfile on disk, because git attempts to the bytes starting at
the last byte of the pack file (21680737). Apparently the nginx does not
like that:

> [pid 11946] sendto(9, "GET 
> /git/haproxy.git/objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack
>  HTTP/1.1\r\nHost: git.haproxy.org\r\nRange: bytes=21680737-\r\nUser-Agent: 
> git/2.28.0\r\nAccept: */*\r\n\r\n", 181, MSG_NOSIGNAL, NULL, 0) = 181
> [...]
> [pid 11946] recvfrom(9, "HTTP/1.1 416 Requested Range Not 
> Satisfiable\r\nserver: nginx\r\ndate: Tue, 13 Oct 2020 17:08:56 
> GMT\r\ncontent-type: text/html\r\ncontent-length: 206\r\ncontent-range: bytes 
> */21680737\r\n\r\n\r\n416 Requested Range Not 
> Satisfiable\r\n\r\n416 
> Requested Range Not 
> Satisfiable\r\nnginx\r\n\r\n\r\n",
>  16384, 0, NULL, NULL) = 385

So this is probably a bug in git and I should be able to work around it
by truncating the temporary packfile in my repository.

I assume a server side workaround would be stripping the `range` request
header.

Do you happen to know where I would report a git bug? Is it on the git
mailing list?

Best regards
Tim Düsterhus



Re: Unable to get pack file - HTTP 416

2020-10-13 Thread Willy Tarreau
Hi Tim,

On Tue, Oct 13, 2020 at 06:55:44PM +0200, Tim Düsterhus wrote:
> Hi List,
> Willy,
> 
> I'm unable to update my local repository:
> 
> > $ g f
> > error: Unable to get pack file 
> > http://git.haproxy.org/git/haproxy.git/objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack
> > The requested URL returned error: 416 Requested Range Not Satisfiable
> > error: Unable to find db9f0524509801b83ec428a8ae2ca535ea3ae264 under 
> > http://git.haproxy.org/git/haproxy.git
> > Cannot obtain needed object db9f0524509801b83ec428a8ae2ca535ea3ae264
> > error: fetch failed.
> 
> This error persists even after retrying the `git fetch` and also after
> running a `git fsck` / `git gc`. I'm not sure whether my local copy is
> borked (I killed a previous `git fetch` because it hung) or whether
> that's a server issue.
> 
> Any ideas?

Strange. I can get it from here as a whole (not tested with ranges
though). The pack file is recent, it dates a few days ago only. I'll
try to investigate further.

Thanks!
Willy



Unable to get pack file - HTTP 416

2020-10-13 Thread Tim Düsterhus
Hi List,
Willy,

I'm unable to update my local repository:

> $ g f
> error: Unable to get pack file 
> http://git.haproxy.org/git/haproxy.git/objects/pack/pack-4c6bfad2590afe3d5591d203ad9b3cf2da4aef97.pack
> The requested URL returned error: 416 Requested Range Not Satisfiable
> error: Unable to find db9f0524509801b83ec428a8ae2ca535ea3ae264 under 
> http://git.haproxy.org/git/haproxy.git
> Cannot obtain needed object db9f0524509801b83ec428a8ae2ca535ea3ae264
> error: fetch failed.

This error persists even after retrying the `git fetch` and also after
running a `git fsck` / `git gc`. I'm not sure whether my local copy is
borked (I killed a previous `git fetch` because it hung) or whether
that's a server issue.

Any ideas?

Best regards
Tim Düsterhus



[PATCH] BUG/MINOR: deinit: fix segfault while accessing fdtab

2020-10-13 Thread William Dauchy
while starting a valid config with check option (`-c`)
trying to fix the following segfault:

  Program received signal SIGSEGV, Segmentation fault.
  0x556b81b9 in deinit () at src/haproxy.c:2455
  2455if (!fdtab[cur_fd].owner)
  #0  0x556b81b9 in deinit () at src/haproxy.c:2455
  #1  0x556b98d8 in deinit_and_exit (status=status@entry=0) at 
src/haproxy.c:2814
  #2  0x556ba77d in init (argc=, argc@entry=5, 
argv=, argv@entry=0x7fffe578) at src/haproxy.c:2028
  #3  0x555963e6 in main (argc=5, argv=0x7fffe578) at 
src/haproxy.c:3069

no backport needed

Signed-off-by: William Dauchy 
---
 src/haproxy.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 3924df1d5..610051df6 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2451,15 +2451,17 @@ void deinit(void)
 */
protocol_unbind_all();
 
-   for (cur_fd = 0; cur_fd < global.maxsock; cur_fd++) {
-   if (!fdtab[cur_fd].owner)
-   continue;
+   if (fdtab) {
+   for (cur_fd = 0; cur_fd < global.maxsock; cur_fd++) {
+   if (!fdtab[cur_fd].owner)
+   continue;
 
-   if (fdtab[cur_fd].iocb == listener_accept) {
-   struct listener *l = fdtab[cur_fd].owner;
+   if (fdtab[cur_fd].iocb == listener_accept) {
+   struct listener *l = fdtab[cur_fd].owner;
 
-   BUG_ON(l->state != LI_INIT);
-   unbind_listener(l);
+   BUG_ON(l->state != LI_INIT);
+   unbind_listener(l);
+   }
}
}
 
-- 
2.28.0




Took some digging, but I found 100 really good ones.

2020-10-13 Thread Dan Hollings
Dan here. Wanted to get this new PDF to you. I compiled the TOP 100 High Pay 
Aff programs...

Hi there

I've been quarantined-up here in my home for months now. It's so crazy, even my 
dog wants to take ME out for a walk!  But I've made good use of my time.

IN A RUSH? Here's the bottomline: This PDF 
https://docs.google.com/forms/d/e/1FAIpQLSexz5bdyr4K0KEc4hesOIvNEfgJhsP3K-71Zmg0Z-2JUrQgXA/viewform?usp=pp_url=haproxy@formilux.org
 is well worth the download. It's 100 well-researched aff programs with no 
catches, no aff links, just throwing it your way. Enjoy!

If you're curious, here's how it came about...

Last year almost 50% of my take-home was made from affiliate programs. But this 
year, with this pandemic breathing down my neck I thought my side hustles were 
going to bomb out.

They didn't.  They doubled.  No kidding.

Many people I know, including affiliate marketers and entrepreneurs have 
recently found themselves in a pickle.  Some folks are hanging in there ok, but 
others are not. In fact, I'm seeing some people do some really dumb stuff.  
Perhaps they’re desperate, I don’t know, but I decided I'd do something to help 
out... Who couldn't use a little extra green about now?

So here's what I did:

I combed through 1000s of aff offers (oh my, there is a lot of garbage stuff 
out there) and ultimately trimmed it down to 100... I threw this all together 
in a PDF and gave it a compelling title:

Top 100 “High-Pay”

Affiliate Programs of 2020

(Pandemic-Proof Edition)

If you've been wondered what's working (or not working) right now, today, 
pandemic or not! It’s all in a this freebie PDF (download here 
https://docs.google.com/forms/d/e/1FAIpQLSexz5bdyr4K0KEc4hesOIvNEfgJhsP3K-71Zmg0Z-2JUrQgXA/viewform?usp=pp_url=haproxy@formilux.org).

And here's the kicker:

The PDF has ZERO aff links in it. Nothing but top-pick programs with 
direct-to-site links. I'm NOT trying to make a thing off this. My 
recommendations are not based on me trying to cash-in on your clicks.  Yep, 
this is just a raw-file freebie.

You can thank me later.

Who am I? (Perhaps you already know)

I'm best known as the guy that did the marketing campaign behind the mega-hit 
book & move “The Secret” - Perhaps you remember this from one of the 4 shows 
Oprah hosted about my campaign? Or perhaps you saw this on the cover of 
Newsweek?  Or maybe you saw the movie (It hit #1 on Amazon)? 

So there you have it… a PDF, ready for you to download now.  No catches.  No 
aff links. Clean and good. It’s pandemic-proof and it’s yours.

Download PDF here:

DOWNLOAD PDF HERE 
https://docs.google.com/forms/d/e/1FAIpQLSexz5bdyr4K0KEc4hesOIvNEfgJhsP3K-71Zmg0Z-2JUrQgXA/viewform?usp=pp_url=haproxy@formilux.org

All the best!

Dan Hollings

Here's the download link (my partner set this up for a quick and easy 
download): TOP 100 
https://docs.google.com/forms/d/e/1FAIpQLSexz5bdyr4K0KEc4hesOIvNEfgJhsP3K-71Zmg0Z-2JUrQgXA/viewform?usp=pp_url=haproxy@formilux.org

.

Dan Hollings

6351 Lindell Rd, Suite D174, Las Vegas, NV 89103 

Unsubscribe 
https://u3000257.ct.sendgrid.net/asm/unsubscribe/?user_id=3000257=p2fC3pfazr6c3-DIKNUE1MANFMNy67fnH7rGjOy1vW-nSdv6APzV1Gm78L1DavYHWeBPqOI6HYRycTdhR-cA76up8pElDGyYwSjN-d-HfcZ-pkGISTvPSi3Q4IrzmOxCMlC0ozgc8HhyAW62PdsNOekxYBgMnRXB8D89RJg3MXuqfAjQzAqsVeszNEsRbVtN3gFHXXvfcP73LEtHveX-bU0zlx0rLra3UBHdQb5Cjvu-DUiT8n6lQYOr3OfHUB8AVyhlCe2oUyh4RHL1SdN7vaS-_ifbaq0UVB6oveXqPivCJjkiX_lIROc6FSyfiSm0qUhiRet-BBs15Svw9YQCD-qaqTB3EylI5fpR77zinuARQBzZiUOi_12e9OLVTTHjNtkznPLcLHYnRo7Dxb5qv1NBKkmD2UlUwkLLJ6ya4ZVc_GRFxpVeMYzZvcgA547Jgg-BOwjIWcnEufIIn4Mt_7iTgiJByTiiR8Ko5T8ONkUkeEAm-CQVJ76yT3TeDCkLFEF0gWwjtj2O4mA2SeF1KZ1DA7NURYetSyf111Ch7tyZh-FTNz1jsvmLtPk-pKJSgxpVC1oXZmZY57T0ZNaEOg==
 - Unsubscribe Preferences 
https://u3000257.ct.sendgrid.net/asm/?user_id=3000257=ty1mudIsVJm-OJ1BtLZL3CNOH-rCG6Mr_iagNCAx2LKNOZ1lCZVRC44Ki-5zwdxkUPigsj0-S-gB05JcvHBTLFKtIWv7OBK135CPhLxE0UOyblY6Ni1IE2zo0tC64ybCJh2mMt4mVB-384Q-fWTYzRNxeYIhzFLFC6KE0Byxo2gS72aEmSRHWP7ihYhrQ0t9NixvYXCuKTuEEGTRv94uZ7B-nCqrD38aKM4zyrkvkPzhZ78dZKHyqjPaqyGg0tMdYXnqS7giSFkBCbD5-NC1UvSvMsNBxcLIB8mDVkuz24DpSe26_1I1WvRbkU2bPCMOYmjKeI6TcCZWP2zcTvQyoQrdG4EMY506y039smD2Gw-bPhQ6yX69YE9d6rJBYm-EeY8rAo--wCqm30AgH71gj-kfNzNl02pDaL8XK01c7P2Z57WFWWXALC7VZFbvmeTvei0jjIJ2A2r9oLP1zB70UOSAk_idfjp_f31eWamPvJjyMMJF4NSdLk7iku8eNty4wxknCd6lEH27OyI9cmm0FO2ocGD4_p64vqdp84yGmdIWrX5QNzL9G4GhkZU3sOvY

Re: [PATCH v2 0/4] add set server ssl command

2020-10-13 Thread William Dauchy
Hi William, Willy,

On Wed, Oct 7, 2020 at 5:02 PM William Dauchy  wrote:
> adding some more thoughts we discussed internally with Pierre:
> - we started to use `show servers state`, as it was the only way to
> get the current config for the parameters we wanted to change with the
> existing runtime API.
> - even if it was not necessarily designed for that purpose, we need a
> way to get the current config.
> - we understood `show servers state` was more likely designed for
> internal usage, especially for `load-server-state-from-file`, so that
> my patch set has some implications.
>
> That being said, would it more acceptable to add a new API which which
> reflects all the `set` commands such as:
> - show server [/]
> would display all the config of a given server or all of them
> - show server / agent
> - show server / state
> - show server / weight
> etc
> and for my first proposition:
> - show server ssl [/]
> - set server ssl [/] on/off
>
> for our immediate usage around ssl we are also thinking about ca_file,
> crt, crt-file.
>
> This also would be a good answer to simplify how it is managed through
> the current dataplane API
> https://www.haproxy.com/documentation/dataplaneapi/latest/#operation/createServer
>
> What are your thoughts about it?

any thoughts about this proposition?

Thanks,
--
William



Crash when using wlc in multithreaded mode with agent checks (1.8.26).

2020-10-13 Thread Peter Statham
Hello,

We've found an issue when using agent checks in conjunction with the
weighted least connections algorithm in multithreaded mode.  It seems to me
as if it is possible for next_eweight in struct server to be modified in
another thread during the execution of fwlc_srv_reposition.  If
next_eweight is set to zero then a division by zero occurs on line 59 in
src/lb_fwlc.c in fwlc_queue_srv.

I notice that in haproxy-2.0.18 this section of code is protected by
HA_SPINLOCKs and I've been unable to replicate this issue in that version.

I've written an agent (attached), bad_agent.py, which provokes this
condition by switching randomly between 1 and 0 percent.  I also include a
minimal configuration, cfg (also attached), which seems sufficient to cause
the issue.  With these two running “ab -n 500 -c 500
http://192.168.92.1:8080/” will quickly crash the haproxy process.

I include links to a coredump and the binary that generated it
(unstripped).  The backtrace of thread 1 follows.

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./haproxy...done.
[New LWP 11307]
[New LWP 11308]

warning: Unexpected size of section `.reg-xstate/11307' in core file.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./haproxy -db -- cfg'.
Program terminated with signal SIGFPE, Arithmetic exception.

warning: Unexpected size of section `.reg-xstate/11307' in core file.
#0  0x56120ec24a90 in fwlc_queue_srv (s=0x56120f989e80) at
src/lb_fwlc.c:59
59  fwlc_queue_srv(s);
[Current thread is 1 (Thread 0x7f5871e723c0 (LWP 11307))]
(gdb) set pagination off
(gdb) bt full
#0  0x56120ec24a90 in fwlc_queue_srv (s=0x56120f989e80) at
src/lb_fwlc.c:59
No locals.
#1  fwlc_srv_reposition (s=0x56120f989e80) at src/lb_fwlc.c:59
No locals.
#2  0x56120ebf5390 in connect_server (s=s@entry=0x56120fa02650) at
src/backend.c:1234
count = 
cli_conn = 0x7f586c504e70
srv_conn = 0x7f586c099020
srv_cs = 
old_cs = 
srv = 
reuse = 
err = 
#3  0x56120eb990f8 in sess_update_stream_int (s=0x56120fa02650) at
src/stream.c:886
conn_err = 
srv = 0x56120f989e80
si = 0x56120fa028c0
req = 0x56120fa02660
srv = 
si = 
req = 
conn_err = 
#4  process_stream (t=) at src/stream.c:2234
srv = 
s = 0x56120fa02650
sess = 
rqf_last = 
rpf_last = 2147483648
rq_prod_last = 
rq_cons_last = 
rp_cons_last = 
rp_prod_last = 
req_ana_back = 
req = 0x56120fa02660
res = 0x56120fa026a0
si_f = 0x56120fa02898
si_b = 0x56120fa028c0
#5  0x56120ec2007d in process_runnable_tasks () at src/task.c:317
t = 
i = 
max_processed = 
local_tasks = {0x56120fa029b0, 0x7f586c04d340, 0x50004, 0xb2,
0x0, 0x56120ec2527b , 0x50004, 0xb2, 0x0,
0x7f586c529180, 0x2c80, 0x56120ec15513 , 0x0,
0x, 0x7fff32892a50, 0x7fff32892a50}
local_tasks_count = 
final_tasks_count = 0
#6  0x56120ebce414 in run_poll_loop () at src/haproxy.c:2499
next = 
exp = 
next = 
exp = 
#7  run_thread_poll_loop (data=) at src/haproxy.c:2569
ptif = 
ptdf = 
start_lock = 0
#8  0x56120eb4212f in main (argc=, argv=)
at src/haproxy.c:3172
tids = 
threads = 0x56120f9861c0
i = 
old_sig = {__val = {2048, 48, 72057589742960643, 94635570839576,
31, 80, 18446744073709544224, 0, 206158430211, 0, 0, 472446402651,
511101108348, 0, 140017846675184, 140017846656064}}
blocked_sig = {__val = {1844674406710583, 18446744073709551615
}}
err = 
retry = 
limit = {rlim_cur = 4027, rlim_max = 4027}
errmsg = "\000pression support (neither USE_ZLIB nor
\000X%-x\342/6\375\000\000\000\000\000\000\000(-\211\062\377\177\000\000\350+\211\062\377\177\000\000\001\303\307\016\022V\000\000\201\000\000\000\000\000\000\000H,\211\062\377\177\000\000`C\225\017"
pidfd = 
(gdb)

 core-1.8.26

 haproxy-1.8.26

Re: [PATCH] BUG/MINOR: mworker: delete the pidfile when the master process is stopped

2020-10-13 Thread William Lallemand
On Thu, Oct 08, 2020 at 04:59:46AM +, mizuta.take...@fujitsu.com wrote:
> Hi, all,
> 
> haproxy does not delete the pidfile when stopped.
> If the PID in the remaining pidfile is reused by other process,
> the operation using the pidfile may affect other process.
> In master-worker mode, fixed to delete pidfile when stopped.
> 
> However, in the daemon mode, it has not been dealt with yet.
> Is there any objection to dealing only with master-worker mode?
> 
> Best regards,
> MIZUTA Takeshi


Hello,

I'm not convince that it should be done within HAProxy, you will still
have the same problem if the master crashes.

It's also a big change of behavior that could break existing scripts.

In my opinion this should be done this in your init script.

-- 
William Lallemand



Re: how to use tune.ssl.keylog

2020-10-13 Thread William Lallemand
On Mon, Oct 12, 2020 at 10:33:26AM +0200, micu...@gmail.com wrote:
> Hi All,
> 
> Because of troubleshooting I would like to decrypt the TLS connection on
> the backend towards our partner.
> I found I can do it with the setting of environment variable
>  SSLKEYLOGFILE and Wireshark.
> I set "tune.ssl.keylog on" but I do not understand the description below
> this parameter.
> 
> Please could someone provide me some example how to configure  HAPROXY to
> save data to  SSLKEYLOGFILE
> 
> Regards,
> Peter Micunek

Hello,

HAProxy is not able to write to a file once started, so the
"tune.ssl.keylog" option allows you to log each parameter of this file.

You will need to configure a log-format with the sample fetches
described in the documentation:

https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#tune.ssl.keylog

And then compose a SSLKEYLOGFILE from your logs that you will open with
wireshark.

-- 
William Lallemand



Advertising offer

2020-10-13 Thread Maria Biz


Hello,
Hope this finds you well.
I was just wondering if you had a chance of reviewing my latest message. 
Concerning advertising on haproxy.com
Looking forward to your answer, thanks once again and have a great day.
Best regards,
-- 
Maria Biz