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. The package includes all the topics from our popular Bid Writing: The Basics and Bid Writing: Advanced live workshops plus 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. 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. TERMS Training materials are for use only by the trainee named on the invoice. Training materials may not be copied, circulated or published. 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: commit 493d9dc makes a SVN-checkout stall..
Hi Pieter, On Wed, Mar 25, 2020 at 01:14:46AM +0100, PiBa-NL wrote: > Hi List, Willy, > > Today i thought lets give v2.2-dev5 a try for my production environment ;). > Soon it turned out to cause SVN-Checkout to stall/disconnect for a > repository we run locally in a Collab-SVN server. > > I tracked it down to this commit: 493d9dc (MEDIUM: mux-h1: do not blindly > wake up the tasklet at end of request anymore) causing the problem for the > first time. Is there something tricky there that can be suspected to cause > the issue.? Perhaps a patch i can try? > > While 'dissecting' the issue i deleted the whole directory each time and > performed a new svn-checkout several times. It doesn't always stall at the > exact same point but usually after checking out around +- 20 files something > between 0.5 and 2 MB. , the commit before that one allows me to checkout > 500+MB through haproxy without issue.. A wireshark seems to show that > haproxy is sending several of RST,ACK packets for a 4 different connections > to the svn-server at the same milisecond after it was quiet for 2 seconds.. > The whole issue happens in a timeframe of start of checkout till when it > stalls within 15 seconds. > > The 'nokqueue' i usually try on my FreeBSD machine doesn't change anything. > > Hope you have an idea where to look. Providing captures/logs is a bit > difficult without some careful scrubbing.. > > Regards, > PiBa-NL (Pieter) > No answer yet, but I just tried to do a checkout of the FreeBSD svn tree via haproxy, and it indeed doesn't work, it's a bit late right now, but I'll have a look tomorrow :) Regards, Olivier
commit 493d9dc makes a SVN-checkout stall..
Hi List, Willy,
Today i thought lets give v2.2-dev5 a try for my production environment ;).
Soon it turned out to cause SVN-Checkout to stall/disconnect for a
repository we run locally in a Collab-SVN server.
I tracked it down to this commit: 493d9dc (MEDIUM: mux-h1: do not
blindly wake up the tasklet at end of request anymore) causing the
problem for the first time. Is there something tricky there that can be
suspected to cause the issue.? Perhaps a patch i can try?
While 'dissecting' the issue i deleted the whole directory each time and
performed a new svn-checkout several times. It doesn't always stall at
the exact same point but usually after checking out around +- 20 files
something between 0.5 and 2 MB. , the commit before that one allows me
to checkout 500+MB through haproxy without issue.. A wireshark seems to
show that haproxy is sending several of RST,ACK packets for a 4
different connections to the svn-server at the same milisecond after it
was quiet for 2 seconds.. The whole issue happens in a timeframe of
start of checkout till when it stalls within 15 seconds.
The 'nokqueue' i usually try on my FreeBSD machine doesn't change anything.
Hope you have an idea where to look. Providing captures/logs is a bit
difficult without some careful scrubbing..
Regards,
PiBa-NL (Pieter)
### Complete config (that still reproduces the issue.. things cant get
much simpler than this..):
frontend InternalSites.8.6-merged
bind 192.168.8.67:80
mode http
use_backend APP01-JIRA-SVN_ipvANY
backend APP01-JIRA-SVN_ipvANY
mode http
server svn 192.168.104.20:8080
### uname -a
FreeBSD freebsd11 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul
21 02:08:28 UTC 2017
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
### haproxy -vv
HA-Proxy version 2.2-dev5-3e128fe 2020/03/24 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Build options :
TARGET = freebsd
CPU = generic
CC = cc
CFLAGS = -pipe -g -fstack-protector -fno-strict-aliasing
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-fno-strict-overflow -Wno-null-dereference -Wno-unused-label
-Wno-unused-parameter -Wno-sign-compare -Wno-ignored-qualifiers
-Wno-unused-command-line-argument -Wno-missing-field-initializers
-Wno-address-of-packed-member -DFREEBSD_PORTS -DFREEBSD_PORTS
OPTIONS = USE_PCRE=1 USE_PCRE_JIT=1 USE_STATIC_PCRE=1
USE_GETADDRINFO=1 USE_OPENSSL=1 USE_LUA=1 USE_ACCEPT4=1 USE_ZLIB=1
Feature list : -EPOLL +KQUEUE -NETFILTER +PCRE +PCRE_JIT -PCRE2
-PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -BACKTRACE
+STATIC_PCRE -STATIC_PCRE2 +TPROXY -LINUX_TPROXY -LINUX_SPLICE +LIBCRYPT
-CRYPT_H +GETADDRINFO +OPENSSL +LUA -FUTEX +ACCEPT4 +ZLIB -SLZ
+CPU_AFFINITY -TFO -NS -DL -RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD
-OBSOLETE_LINKER -PRCTL -THREAD_DUMP -EVPORTS
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_THREADS=64, default=16).
Built with OpenSSL version : OpenSSL 1.0.2k-freebsd 26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k-freebsd 26 Jan 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.4
Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY
Built with PCRE version : 8.40 2017-01-11
Running on PCRE version : 8.40 2017-01-11
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Available polling systems :
kqueue : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use kqueue.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
h2 : mode=HTTP side=FE|BE mux=H2
fcgi : mode=HTTP side=BE mux=FCGI
: mode=HTTP side=FE|BE mux=H1
: mode=TCP side=FE|BE mux=PASS
Available services : none
Available filters :
[SPOE] spoe
[CACHE] cache
[FCGI] fcgi-app
[TRACE] trace
[COMP] compression
stable-bot: Bugfixes waiting for a release 2.1 (21), 2.0 (16)
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.1.3 was issued on 2020-02-12. There are currently 21 patches in the queue cut down this way: - 2 MAJOR, first one merged on 2020-02-21 - 6 MEDIUM, first one merged on 2020-02-21 - 13 MINOR, first one merged on 2020-02-21 Thus the computed ideal release date for 2.1.4 would be 2020-03-06, which was two weeks ago. Last release 2.0.13 was issued on 2020-02-13. There are currently 16 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2020-02-21 - 6 MEDIUM, first one merged on 2020-02-21 - 9 MINOR, first one merged on 2020-02-21 Thus the computed ideal release date for 2.0.14 would be 2020-03-06, which was two weeks ago. The current list of patches in the queue is: - 2.0, 2.1 - MAJOR : http-ana: Always abort the request when a tarpit is triggered - 2.1 - MAJOR : list: fix invalid element address calculation - 2.0, 2.1 - MEDIUM : muxes: Use the right argument when calling the destroy method. - 2.0, 2.1 - MEDIUM : ssl: fix several bad pointer aliases in a few sample fetch functions - 2.0, 2.1 - MEDIUM : shctx: make sure to keep all blocks aligned - 2.0, 2.1 - MEDIUM : ebtree: don't set attribute packed without unaligned access support - 2.0, 2.1 - MEDIUM : random: implement a thread-safe and process-safe PRNG - 2.0, 2.1 - MEDIUM : random: initialize the random pool a bit better - 2.0, 2.1 - MINOR : dns: ignore trailing dot - 2.0, 2.1 - MINOR : namespace: avoid closing fd when socket failed in my_socketat - 2.0, 2.1 - MINOR : sample: fix the json converter's endian-sensitivity - 2.1 - MINOR : h2: reject again empty :path pseudo-headers - 2.0, 2.1 - MINOR : connection: make sure to correctly tag local PROXY connections - 2.1 - MINOR : http-htx: Don't return error if authority is updated without changes - 2.0, 2.1 - MINOR : http-ana: Matching on monitor-uri should be case-sensitive - 2.0, 2.1 - MINOR : checks/threads: use ha_random() and not rand() - 2.0, 2.1 - MINOR : filters: Count HTTP headers as filtered data but don't forward them - 2.1 - MINOR : mux-fcgi: Forbid special characters when matching PATH_INFO param - 2.1 - MINOR : http-htx: Do case-insensive comparisons on Host header name - 2.0, 2.1 - MINOR : sample: Make sure to return stable IDs in the unique-id fetch - 2.0, 2.1 - MINOR : http: http-request replace-path duplicates the query string -- 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.
Re: running h2spec in CI ?
On Wed, Mar 25, 2020 at 12:49:29AM +0500, ??? wrote: > Hello, > > here's patch. Applied now, thanks Ilya! Willy
Re: Segfault with HAProxy 2.0 with peers
On Tue, Mar 24, 2020 at 08:32:12PM +0100, Frederic Lecaille wrote: > William, > > I think you are true, but I did not manage to reproduce this issue. But > I think you are correct about the reference to the peers section which > may be found in stktable structs. > > Here is a patch which may fix this issue. > > Olivier, please could you give it a try? > > > Regards. > I confirm that the patch does not produce any use after free with this configuration. Merged in master, thanks for the quick fix! -- William Lallemand
Re: running h2spec in CI ?
Hello, here's patch. вт, 24 мар. 2020 г. в 23:51, Willy Tarreau : > On Tue, Mar 24, 2020 at 11:49:11PM +0500, ??? wrote: > > > In fact it's very difficult to make such a file load and work > properly, it > > > depends on the headers appended etc. > > > > > > > initially, I expected that after WARNING (and truncation), file will be > > loaded :) > > but I was wrong. > > I could be wrong but my suspicion is that it was indeed truncated, but > the truncation was still too large and made it fail later. But that's > pure speculation. > > > ok, so shall we add it as weekly Github Action job ? I do not think we > have > > to run it on every push > > That's something we can do, probably, yes. > > Willy > From 96e726d4e0c3c1bb6281b9fe1b85049c5d878cb6 Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Wed, 25 Mar 2020 00:46:14 +0500 Subject: [PATCH] CI: github actions: add weekly h2spec test ML link: https://www.mail-archive.com/haproxy@formilux.org/msg36753.html this commit adds scheduled run of h2spec tool to test http2 and HPACK compliance. h2spec might be found at: https://github.com/summerwind/h2spec --- .github/errorfile| 209 +++ .github/h2spec.config| 30 + .github/workflows/h2spec.yml | 27 + 3 files changed, 266 insertions(+) create mode 100644 .github/errorfile create mode 100644 .github/h2spec.config create mode 100644 .github/workflows/h2spec.yml diff --git a/.github/errorfile b/.github/errorfile new file mode 100644 index 0..f15d8e0d0 --- /dev/null +++ b/.github/errorfile @@ -0,0 +1,209 @@ +HTTP/1.0 200 OK +Cache-Control: no-cache +Connection: close +Content-Type: text/html + + + +b1z6lx9BLl3rSuonLqkIJAn9k9Hsah5qGfx9aq3qWSw6Nn37AZBJ1lxI0UyI7zvjXIEjSEVdCS4U +k6rTW/LndurrbPieC6OcEBPMjzGtsfpR9IsZ3QH6/mtBGnvAtbhxAfhMZ/QQXkqfv0JPjuLdXBdM +Z9cInHOr4ykoETgRbHaNt9ykBv32nIKt81YxLtTOMyyFAzH/AVSHUs6PanUKhxG11Csqn5RnlvSj +PBCaF0lJAGvndF/1PTSIhzjEtXR3ZUzCfO03/j0q0/4+cduV5jf3XNFeICjY19OHKSMIWVN0XVht +bY2eSMG0LoL8TqWyv6VSnclsVM5S5LJe7prJtWFobEpU3AMZzzjMPsxDiyMGJhjbJa0TnsDGAwln +IVO5n56gtdUdhwWUnVn8ZYGZlFVjOQt++q6XL/Vhm+DFCArXZ6Xz8+mz1o109JpM28jHhxg6e7A1 +CF08n0mwN+adNFTi3Wg8D4RJOOQ90Q1bS/gmW7LtPjYxGuu8k27MjUspEHeeEr5rdAcBJbKiG8C9 +191DBDLxlJv/V4ZYG/FdGIqX/a2F7x03Uj7rsVnBPmOz7U0EbcHGcEEpZlSN9YLuUKvPXeZ8HWa9 +fbaGO39Yt+9DByPWC1Xyr65sPBH8eDURPdSDMh3Sr+16HH46anVI40tjK8NZC6jjFBQPfJBP6MVW +HZF1F48rZXxesnHLHaMESCvwTruBf5R4JjYB1gt1Vv76e4Pew1MTK3/1ooNPV5kvoBV5PSLkMDqx +XO6dxSC9Y3HzxhzkoRK56h7SWDbwxd5OmUHNvjm3k0QtVTAWsAEbJ5q/gp65ikG3+hGvp9xF80pU +C1dAxK9+MHg7Ya3UiV6G/dB9prc3v92lEVqtK5CNKzlFiWQHSF3H+sz4qPGlB2Ub8H0T59TSZcyu +oTFKi802BYc8UnPdUX+mf4Uda4Vad4dPE409UQ1XIEqI+2pCTgOCUm80xM2Hgyjpp8bi1mnv6rI1 +8jafv0e6S23Meb9d93E/MLm82KWfXHIjPkDFaTouGS78IJie3giG68U270AL1+gpUwNunW+Ez0Ch +AwKUOM5BUL9pFfRMeDshy8KfiDGr7enLupqa2xe65Hbo47eioZZfIb0AD3P7yzlciIUXsy5JAwCF +B+L0T+XuRUJuXCaJ+ioDmgW0PenJ6xfL/+BuJ9yVrMGYb0paL/cD7VSVDda1L7+VSbLW7sQ6BOHM +ZgFV6+O81p48hGDquMb9+eURGrFKhQFipUPEi5sTQ7ocmyRZIAI3VeEOdBsX6zuwR9a2L5aV4yZc +HoiQikOgAeF1O8FNoVBIKh6TvFIzG+JFxb64pfWiwku+njgQu/xXkhuDSnYh/tzzqwghzmKHpQQl +7fbxF7jBihOr4qTcD/fUNPNGZYAZnZk/+wuA/6NOqwJl7nV2E7Ht7N13E6RZqGzfcL8KWldZbuFL +cFUVZ7sxogftmAWhSrQ1Io4IcAqt19XL5uGFlAiELphh5v+3mWKVNh5kOaCIDcoOggaerDZMl05F +C/d5veJxVLFBsSKFfdADmGh/8g85JDQC1UJuHYXbmPKuQ3pzUZRg6a3JYoi9ssLz7GijrSmmgkXs +71+8TsvHFP193euCd9N981+Gp4NMxpVvWkrYFsjkdtkzSQBda4dUlJ/QhbbHoRAuzNl2zDkUU7SA +P7LCNw3SKJlCQlwDEtqNYuO6jiQBZcUnajdk/UKwVwiH/p6q8rg8bh+NPV04hTZraUoaKumsPG+5 +tCBRj/WxPDKWfLjpgLx2gJPU4SKJrKwbfSot+VVO0Tc9viV8Jl0PPOkcW3ixx3Hc9WEqj0QZYHsB +kUk4E/q8N5WDnvmCzp3t6tlpeNqqkXhvNOAg0XxVXmKE3pWEytX1iMdggdjnoo9dLLGcNwW5+tnw +XdAlEVuqcvTeKJfYT/RMxpfdB7bXsg6OGEokMEkZHltLPmlYkB9i+J6zpWgo0WCwjawocVc7Y9Lj +FfSezs/Fs2s8OJhFlrHQzh3SwZoyAXHgOPC1wJDanMZWjLASi6W7ds2H2FHuyKYfx/gJb02+d199 +1ac7QG3Vgi0QiNB+6D8vuj4r05jQgHj7REIvFwbvJX/eVCY2kle+nXjzOiTL9M4AoDdaW9Hfzoao +YnwcKslhmHhRl/Q+9jA0YX7TCHh/VcKg6+lao3ScQ5F+MjwZewK0lwOlE9Z7Oz5rDNwTdBe6LhwA +tTkeItrhm45IPdipFKRRcqY7OPV0GgHeqIg704hGnpzws0cJi++lpLi2c+387h28ymvUXArndPtF +at7mboqJ7XCi2mYBOa73e7Q58R5UBhNzZB+M+SbNM3Xi5hcbXMH1UtnHGx8E8uNS5oXQvm4Cm4k0 +v1g0jU5xxU3m8j6ze99Z6sFZ3EJ7IrIdIkKHl0jkr+WZww64BEKmNsJfh0nWO+5Bm50ZK+sNkvDg +PtjkehxsWaaERJ8aQeqzIVQTK81m6FqHYdcSsuxMiY2ZAQSnVRarmSJqyd2oPy5vEkCnS9yd2ha9 +bYqAREVHUEy//dw/XJAtttnZSgwAKdn+SRSQuDiWZ9GPs0k/zKuohKkSXkHPlhIDuer+lJ1Hs17m +r0JTCt2LQVXLdCbKScAHOm4wdGeeIyMsV8MJv/PIWoySW8PIm3IjjzFinphnj6COvvVJUYg6zvPb +1WN7ZU0UyI0nFklUVguc6RF2ByO9ZzZA7nmVXlFawnDc5UkotXSGYZJaiV9c44Mvqg8CgxbfLLk+ +OCOJgQF9xIEk0bUp/QAfKj6o5aP2qHr+YvKxxTxlEthlxdGyM+F8YX4WpR6wf2mbFjc6jWC67xk3 +F7zfTdXtmezimB6vUkRAf4P5yS8J6Q7m7JCE/V0CN0Z6fUG4Z/8cGxpVQwqD44McT257MqSdiwrp +C9NiXxqWiLXcj0NbUI0rxAlzSwzuFAjMdLpPOm3zjm6I3SltMKn9BPSOyz5Q4wclInCx6yvZAqK3 +r95cvb72qVEt7YJKaM3b6Vb0oQRMpSWyoYHZQ75WTwcwd8PRecAXGPqgn0e0GYUSfRqiBi5Z3tUp +eljOJvV9ujIs2rFeySLKVfkCfHvcCRVyFZwsiUO0W9NvvIy40lkHtFshFANYlDkJOznhLVSlUGNW +lNwSTjEuG/bcGiiAm4NogFSmu6ijWrrJZbFAjH2CSKkKJUxCpAeasm5nDBqXY6fmS56WLv+mZmlJ
Re: Segfault with HAProxy 2.0 with peers
On 3/24/20 7:01 PM, William Lallemand wrote:
On Tue, Mar 24, 2020 at 05:41:48PM +0100, Olivier D wrote:
Hello,
With latest haproxy 2.0, you can generate a simple segfault with only
configuration test (haproxy -f test.cfg -c)
Config content :
--
defaults
mode http
backend test
stick-table type ip size 10k expire 1h store http_req_rate(1h) peers
mypeers
peers mypeers
peer toto 127.0.0.1:1024
-
Running :
[WARNING] 083/173758 (2599) : Removing incomplete section 'peers mypeers'
(no peer named 'myhostname.localhost').
Segmentation fault
peers_register_table (peers=0xc8a110, table=table@entry=0xc8c6f0) at
src/peers.c:3028
(gdb) bt
#0 peers_register_table (peers=0xc8a110, table=table@entry=0xc8c6f0) at
src/peers.c:3028
#1 0x00522bec in stktable_init (t=0xc8c6f0) at
src/stick_table.c:644
#2 0x0050fa67 in check_config_validity () at src/cfgparse.c:4048
#3 0x00505311 in init (argc=, argc@entry=4,
argv=, argv@entry=0x7fffe848) at src/haproxy.c:1760
#4 0x0046475f in main (argc=4, argv=0x7fffe848) at
src/haproxy.c:2727
I know my peer entry is not correct (my hostname is not "toto") but we
should not end with a segfault ^^
I agree. It looks like this is the consequence of the peer being free'd
if you don't reference the local peer in the section. It should still
start in your case by specifying -L toto on the command line.
I think the peer pointer is still referenced in the stick-table which
tries to use it during its initialization. So if we want to free the
peer we need to remove its reference too.
William,
I think you are true, but I did not manage to reproduce this issue. But
I think you are correct about the reference to the peers section which
may be found in stktable structs.
Here is a patch which may fix this issue.
Olivier, please could you give it a try?
Regards.
>From 9b4ea422ceb3a06cb2692d56475dfa18ec02bbf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?=
Date: Tue, 24 Mar 2020 20:08:30 +0100
Subject: [PATCH] BUG/MINOR: peers: Use after free of "peers" section.
When a "peers" section has not any local peer, it is removed of the list
of "peers" sections by check_config_validity(). But a stick-table which
refers to a "peers" section stores a pointer to this peers section.
These pointer must be reset to NULL value for each stick-table refering to
such a "peers" section to prevent stktable_init() to start the peers frontend
attached to the peers section dereferencing the invalid pointer.
Furthemore this patch stops the peers frontend as this is done for other
configurations invalidated by check_config_validity().
Thank you to Olivier D for having reported this issue with such a
simple configuration file which made haproxy crash when started with
-c option for configuration file validation.
defaults
mode http
peers mypeers
peer toto 127.0.0.1:1024
backend test
stick-table type ip size 10k expire 1h store http_req_rate(1h) peers mypeers
Must be backported to 2.1 and 2.0.
---
src/cfgparse.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/cfgparse.c b/src/cfgparse.c
index eaa853f6e..2c8008312 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -3925,6 +3925,7 @@ out_uri_auth_compat:
*/
last = _peers;
while (*last) {
+ struct stktable *t;
curpeers = *last;
if (curpeers->state == PR_STSTOPPED) {
@@ -3936,6 +3937,9 @@ out_uri_auth_compat:
else if (!curpeers->peers_fe || !curpeers->peers_fe->id) {
ha_warning("Removing incomplete section 'peers %s' (no peer named '%s').\n",
curpeers->id, localpeer);
+if (curpeers->peers_fe)
+ stop_proxy(curpeers->peers_fe);
+curpeers->peers_fe = NULL;
}
else if (atleast2(curpeers->peers_fe->bind_proc)) {
/* either it's totally stopped or too much used */
@@ -3998,6 +4002,11 @@ out_uri_auth_compat:
*/
free(curpeers->id);
curpeers = curpeers->next;
+ /* Reset any refereance to this peers section in the list of stick-tables */
+ for (t = stktables_list; t; t = t->next) {
+if (t->peers.p && t->peers.p == *last)
+ t->peers.p = NULL;
+ }
free(*last);
*last = curpeers;
}
--
2.20.1
Re: running h2spec in CI ?
On Tue, Mar 24, 2020 at 11:49:11PM +0500, ??? wrote: > > In fact it's very difficult to make such a file load and work properly, it > > depends on the headers appended etc. > > > > initially, I expected that after WARNING (and truncation), file will be > loaded :) > but I was wrong. I could be wrong but my suspicion is that it was indeed truncated, but the truncation was still too large and made it fail later. But that's pure speculation. > ok, so shall we add it as weekly Github Action job ? I do not think we have > to run it on every push That's something we can do, probably, yes. Willy
Re: running h2spec in CI ?
вт, 24 мар. 2020 г. в 23:38, Willy Tarreau : > On Tue, Mar 24, 2020 at 11:01:13PM +0500, ??? wrote: > > I created 16kb response file, and found something that looks like an > error > > > > Run ./haproxy -f .github/h2spec.config -D > > [WARNING] 083/174625 (3194) : custom error message file > '.github/errorfile' > > larger than 16384 bytes. Truncating. > > [ALERT] 083/174625 (3194) : parsing [.github/h2spec.config:29] : > errorfile > > : unable to convert custom error message file '.github/errorfile' in HTX. > > [ALERT] 083/174625 (3194) : Error(s) found in configuration file : > > .github/h2spec.config > > [ALERT] 083/174625 (3194) : Fatal errors found in configuration. > > It's normal if the file is too large. > > > since, I see "WARNING", i.e. "no worry, I'll truncate file". but file is > > not loaded :-) > > In fact it's very difficult to make such a file load and work properly, it > depends on the headers appended etc. > initially, I expected that after WARNING (and truncation), file will be loaded :) but I was wrong. > > > I reduced file size a bit, 146/146 tests > > Excellent! > ok, so shall we add it as weekly Github Action job ? I do not think we have to run it on every push > > Willy >
Re: running h2spec in CI ?
On Tue, Mar 24, 2020 at 11:01:13PM +0500, ??? wrote: > I created 16kb response file, and found something that looks like an error > > Run ./haproxy -f .github/h2spec.config -D > [WARNING] 083/174625 (3194) : custom error message file '.github/errorfile' > larger than 16384 bytes. Truncating. > [ALERT] 083/174625 (3194) : parsing [.github/h2spec.config:29] : errorfile > : unable to convert custom error message file '.github/errorfile' in HTX. > [ALERT] 083/174625 (3194) : Error(s) found in configuration file : > .github/h2spec.config > [ALERT] 083/174625 (3194) : Fatal errors found in configuration. It's normal if the file is too large. > since, I see "WARNING", i.e. "no worry, I'll truncate file". but file is > not loaded :-) In fact it's very difficult to make such a file load and work properly, it depends on the headers appended etc. > I reduced file size a bit, 146/146 tests Excellent! Willy
Re: running h2spec in CI ?
сб, 21 мар. 2020 г. в 15:23, Willy Tarreau : > On Sat, Mar 21, 2020 at 03:13:07PM +0500, ??? wrote: > > > Really you *need* to have some response data, not just an empty 200. > > > Probably that you can do it with something like this to build 10kB of > > > garbage: > > > > > > > am I correct, dealing with large blocks is something HPACK related ? > > No it's unrelated. HPACK only deals with headers encoding. Here it's more > about making sure there are still bytes on the wire to be sent when a > window > is reopening after a WINDOW_UPDATE etc. > I created 16kb response file, and found something that looks like an error Run ./haproxy -f .github/h2spec.config -D [WARNING] 083/174625 (3194) : custom error message file '.github/errorfile' larger than 16384 bytes. Truncating. [ALERT] 083/174625 (3194) : parsing [.github/h2spec.config:29] : errorfile : unable to convert custom error message file '.github/errorfile' in HTX. [ALERT] 083/174625 (3194) : Error(s) found in configuration file : .github/h2spec.config [ALERT] 083/174625 (3194) : Fatal errors found in configuration. since, I see "WARNING", i.e. "no worry, I'll truncate file". but file is not loaded :-) I reduced file size a bit, 146/146 tests https://github.com/chipitsine/haproxy/runs/531318490 no valgrind yet, but we can add it later. > > > so, for example, if we decide, we can split into several steps, like > http2, > > HPACK, ... > > Quite frankly given that a generic config works fine there's no point in > having distinct setups for all the tests, it would be a burden to maintain > and would cause extra confusion. > > > h2spec can report in junit format. but no CI can import it (well, > gitlab-ci > > can, but I did not try). > > I'd actually prefer to see history test by test (and for reg-tests as > well) > > By default in verbose more you have all the output and a summary of failed > tests at the end, which is very easy to read. > > > the most we can do (and it is relatively cheap) is to define several > steps > > in github actions. > > like, I already done for "build" and "download h2spec", we can define > > several steps for h2spec itself. > > I think it's asking for more difficulties and pain than really needed. > The normal case is that h2spec should work fine so we don't need to have > details about what fails, if it fails we can check the output and see what > test failed. You'll never know why anyway, it will always require manual > attempts to reproduce. > > Just my two cents, > Willy >
Re: Segfault with HAProxy 2.0 with peers
On Tue, Mar 24, 2020 at 05:41:48PM +0100, Olivier D wrote: > Hello, > > With latest haproxy 2.0, you can generate a simple segfault with only > configuration test (haproxy -f test.cfg -c) > > > Config content : > -- > defaults > mode http > > backend test > stick-table type ip size 10k expire 1h store http_req_rate(1h) peers > mypeers > > peers mypeers > peer toto 127.0.0.1:1024 > - > Running : > [WARNING] 083/173758 (2599) : Removing incomplete section 'peers mypeers' > (no peer named 'myhostname.localhost'). > Segmentation fault > > peers_register_table (peers=0xc8a110, table=table@entry=0xc8c6f0) at > src/peers.c:3028 > (gdb) bt > #0 peers_register_table (peers=0xc8a110, table=table@entry=0xc8c6f0) at > src/peers.c:3028 > #1 0x00522bec in stktable_init (t=0xc8c6f0) at > src/stick_table.c:644 > #2 0x0050fa67 in check_config_validity () at src/cfgparse.c:4048 > #3 0x00505311 in init (argc=, argc@entry=4, > argv=, argv@entry=0x7fffe848) at src/haproxy.c:1760 > #4 0x0046475f in main (argc=4, argv=0x7fffe848) at > src/haproxy.c:2727 > > I know my peer entry is not correct (my hostname is not "toto") but we > should not end with a segfault ^^ > I agree. It looks like this is the consequence of the peer being free'd if you don't reference the local peer in the section. It should still start in your case by specifying -L toto on the command line. I think the peer pointer is still referenced in the stick-table which tries to use it during its initialization. So if we want to free the peer we need to remove its reference too. -- William Lallemand
Segfault with HAProxy 2.0 with peers
Hello,
With latest haproxy 2.0, you can generate a simple segfault with only
configuration test (haproxy -f test.cfg -c)
Config content :
--
defaults
mode http
backend test
stick-table type ip size 10k expire 1h store http_req_rate(1h) peers
mypeers
peers mypeers
peer toto 127.0.0.1:1024
-
Running :
[WARNING] 083/173758 (2599) : Removing incomplete section 'peers mypeers'
(no peer named 'myhostname.localhost').
Segmentation fault
peers_register_table (peers=0xc8a110, table=table@entry=0xc8c6f0) at
src/peers.c:3028
(gdb) bt
#0 peers_register_table (peers=0xc8a110, table=table@entry=0xc8c6f0) at
src/peers.c:3028
#1 0x00522bec in stktable_init (t=0xc8c6f0) at
src/stick_table.c:644
#2 0x0050fa67 in check_config_validity () at src/cfgparse.c:4048
#3 0x00505311 in init (argc=, argc@entry=4,
argv=, argv@entry=0x7fffe848) at src/haproxy.c:1760
#4 0x0046475f in main (argc=4, argv=0x7fffe848) at
src/haproxy.c:2727
I know my peer entry is not correct (my hostname is not "toto") but we
should not end with a segfault ^^
HAPRoxy -vv :
HA-Proxy version 2.0.13 2020/02/13 - https://haproxy.org/
Build options :
TARGET = linux-glibc
CPU = generic
CC = gcc
CFLAGS = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
-fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wno-implicit-fallthrough
-Wno-stringop-overflow -Wtype-limits -Wshift-negative-value
-Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
OPTIONS = USE_THREAD=0 USE_STATIC_PCRE=1 USE_OPENSSL=1 USE_LUA=1
USE_ZLIB=1 USE_NS=
Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE
-PCRE_JIT -PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED
-REGPARM +STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE
+LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4
-MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO -NS +DL +RT -DEVICEATLAS
-51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_THREADS=64, default=20).
Built with OpenSSL version : OpenSSL 1.1.1d 10 Sep 2019
Running on OpenSSL version : OpenSSL 1.1.1d 10 Sep 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.44 2020-02-12
Running on PCRE version : 8.44 2020-02-12
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available multiplexer protocols :
(protocols marked as cannot be specified using 'proto' keyword)
h2 : mode=HTXside=FE|BE mux=H2
h2 : mode=HTTP side=FEmux=H2
: mode=HTXside=FE|BE mux=H1
: mode=TCP|HTTP side=FE|BE mux=PASS
Available services : none
Available filters :
[SPOE] spoe
[COMP] compression
[CACHE] cache
[TRACE] trace
Olivier
Re: stable-bot: Bugfixes waiting for a release 2.1 (21), 2.0 (16)
Julien, List, Am 24.03.20 um 16:41 schrieb Julien Pivotto: > Dear list, > > We are facing some of the bugs fixed in the 2.1 branch (in particular the > replace-path bug). There are more bugs that have not even been backported, yet. I believe some even have been "skipped" / the RNG changes have been picked out-of-order. > Could you please cut a release ? there are many fixes that just cherry > picking it in my fork would make sense. I second that. I was already thinking about asking after yesterday's 2.2-dev5. Best regards Tim Düsterhus
Re: stable-bot: Bugfixes waiting for a release 2.1 (21), 2.0 (16)
Dear list, We are facing some of the bugs fixed in the 2.1 branch (in particular the replace-path bug). Could you please cut a release ? there are many fixes that just cherry picking it in my fork would make sense. Thanks :) Note: the bot says that the ideal date was 2020-03-06 :) On 18 Mar 00:00, stable-...@haproxy.com wrote: > 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.1.3 was issued on 2020-02-12. There are currently 21 patches > in the queue cut down this way: > - 2 MAJOR, first one merged on 2020-02-21 > - 6 MEDIUM, first one merged on 2020-02-21 > - 13 MINOR, first one merged on 2020-02-21 > > Thus the computed ideal release date for 2.1.4 would be 2020-03-06, which was > one week ago. > > Last release 2.0.13 was issued on 2020-02-13. There are currently 16 patches > in the queue cut down this way: > - 1 MAJOR, first one merged on 2020-02-21 > - 6 MEDIUM, first one merged on 2020-02-21 > - 9 MINOR, first one merged on 2020-02-21 > > Thus the computed ideal release date for 2.0.14 would be 2020-03-06, which > was one week ago. > > The current list of patches in the queue is: > - 2.1 - MAJOR : list: fix invalid element address > calculation > - 2.0, 2.1 - MAJOR : http-ana: Always abort the request > when a tarpit is triggered > - 2.0, 2.1 - MEDIUM : shctx: make sure to keep all blocks > aligned > - 2.0, 2.1 - MEDIUM : muxes: Use the right argument when > calling the destroy method. > - 2.0, 2.1 - MEDIUM : ebtree: don't set attribute packed > without unaligned access support > - 2.0, 2.1 - MEDIUM : random: implement a thread-safe and > process-safe PRNG > - 2.0, 2.1 - MEDIUM : random: initialize the random pool a > bit better > - 2.0, 2.1 - MEDIUM : ssl: fix several bad pointer aliases > in a few sample fetch functions > - 2.0, 2.1 - MINOR : connection: make sure to correctly > tag local PROXY connections > - 2.1 - MINOR : http-htx: Don't return error if > authority is updated without changes > - 2.0, 2.1 - MINOR : checks/threads: use ha_random() and > not rand() > - 2.0, 2.1 - MINOR : sample: Make sure to return stable > IDs in the unique-id fetch > - 2.1 - MINOR : mux-fcgi: Forbid special characters > when matching PATH_INFO param > - 2.0, 2.1 - MINOR : dns: ignore trailing dot > - 2.0, 2.1 - MINOR : filters: Count HTTP headers as > filtered data but don't forward them > - 2.0, 2.1 - MINOR : http-ana: Matching on monitor-uri > should be case-sensitive > - 2.1 - MINOR : http-htx: Do case-insensive > comparisons on Host header name > - 2.0, 2.1 - MINOR : namespace: avoid closing fd when > socket failed in my_socketat > - 2.1 - MINOR : h2: reject again empty :path > pseudo-headers > - 2.0, 2.1 - MINOR : sample: fix the json converter's > endian-sensitivity > - 2.0, 2.1 - MINOR : http: http-request replace-path > duplicates the query string > > -- > 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. > -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Haproxy.com : Strategy to Drag Authentic Clients
Hey Haproxy.com Owner, What might it intend if you see an expansion in contact, boost in closings, and growth in sales? We should have a few moments to discuss how I am going to give these to your business. I'm accessible to discuss over the *phone or WhatsApp*. Can we? With Warm Regards, *Anna Kendrick* Digital Marketing Executive [image: beacon]
Re: [PATCH] MINOR: ssl: rework add cert chain to CTX to be libssl independent
On Mon, Mar 23, 2020 at 03:34:12PM +0100, Emmanuel Hocdet wrote: > > Hi, > > This patch remove #ifdef compatibility for add cert chain to CTX, goal is to > simplify code. > It’s an extract from "[PATCH] MINOR: ssl: skip self issued CA in cert chain > for ssl_ctx » proposal. > > ++ > Manu > > Thanks, merged. -- William Lallemand
