Bid Writing, Fundraising and Volunteering Workshops plus Trusts Database
NFP WORKSHOPS Affordable Training Courses Bid Writing 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? ONLINE VIA ZOOM 10.00 TO 12.30 COST £95.00 CLICK ON DATE TO BOOK YOUR PLACE THU 13 JAN 2022 THU 27 JAN 2022 MON 07 FEB 2022 MON 21 FEB 2022 MON 07 MAR 2022 MON 21 MAR 2022 MON 04 APR 2022 MON 25 APR 2022 Trust Fundraising 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? ONLINE VIA ZOOM 10.00 TO 12.30 COST £95.00 CLICK ON DATE TO BOOK YOUR PLACE TUE 25 JAN 2022 TUE 22 FEB 2022 TUE 22 MAR 2022 TUE 26 APR 2022 GrantMakingTrusts.co.uk Our online database has details of more than 34,000 trusts, foundations and charities that make grants to organisations. The site allows users to quickly find a wide range of new potential funders including regional, lower profile and newer trusts plus charities that make grants to organisations as well as running activities themselves. A 1 year subscription to the database costs £95.00 per user. VIEW MORE DETAILS & SUBSCRIBE Recruiting and Managing Volunteers 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 volunteers? 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? ONLINE VIA ZOOM 10.00 TO 12.30 COST £95.00 CLICK ON DATE TO BOOK YOUR PLACE FRI 28 JAN 2022 TUE 08 MAR 2022 TUE 05 APR 2022 Charity Finance An introduction to the basic principles of finance in charities and voluntary organisations. Legal Requirements - Charitable Funds Financial Management - Income Sources Bookkeeping - Control Systems - Auditing Formal Accounts - Management Accounting Budgeting - Trading Income - Taxation This workshop is for staff members, volunteers, trustees or board members of charities and voluntary organisations who are not professionals in finance but wish to understand more about the subject. People who provide advice to these organisations are also welcome. ONLINE VIA ZOOM 10.00 TO 12.30 COST £95.00 CLICK ON DATE TO BOOK YOUR PLACE WED 09 MAR 2022 Legacy Fundraising Why do people make legacy gifts? What are the ethical issues? What are the regulations? What are the tax issues? What are the statistics? What are the trends? How can we integrate legacy fundraising into our other fundraising? What are the sources for research? How should we set a budget? How should we evaluate our results? How should we forecast likely income? Should we use consultants? How should we build a case for support? What media and marketing channels should we use? What about in memory giving? How should we setup our admin systems? What are the common problems & pitfalls? ONLINE VIA ZOOM 10.00 TO 12.30 COST £95.00 CLICK ON DATE TO BOOK YOUR PLACE WED 26 JAN 2022 WED 23 MAR 2022 Major Donor Fundraising Major Donor Characteristics, Motivations and Requirements. Researching and Screening Major Donors. Encouraging, Involving and Retaining Major Donors. Building Relationships with Major Donors. Major Donor Events and Activities. Setting Up Major Donor Clubs. Asking For Major Gifts. Looking After and Reporting Back to Major Donors. Delivering on Major Donor Expectations. Showing Your Appreciation to Major Donors. Fundraising Budgets and Committees. ONLINE VIA ZOOM 10.00 TO 12.30 COST £95.00 CLICK ON DATE TO BOOK YOUR PLACE WED 09 FEB 2022 WED 06 APR 2022 Corporate Fundraising Who are these companies? Why do they get involved? What do they like? What can you get
Re: [PATCH] BUG/MEDIUM: server: avoid changing healthcheck ctx with set server ssl
Hi William! On Mon, Jan 10, 2022 at 10:49:38PM +0100, William Dauchy wrote: > On Mon, Jan 10, 2022 at 7:51 AM Willy Tarreau wrote: > > It's important to always keep in mind that checks are not necessarily > > related to the production traffic, and that configuring one part should > > not have any impact on the other one. By default a server running in SSL > > will not be checked using SSL unless "check-ssl" is set. > > note it is only true in your example if you use another port. Hmmm I didn't remember about this :-( > > You could for > > example have a server forwarding to multiple ports (say 80 and 443) and > > decide to check only one of them, or even check another one. > > > > As such, I think your patch is correct as it only affects what the user > > attempts to modify. I suspect that the reason for your initial choice was > > that it was not yet possible by then to enable SSL checks manually, > > sorry what do you mean by manually? I meant "on the CLI". I.e. you added support for enabling/disabling SSL while few options were still configurable on the CLI by then. > "check-ssl" has been available for a long time, so that's not the > reason behind it, but I guess you were referring to something else. I > suspect I did a dumb copy/paste from the new_server function and > probably never thought was possibly wrong as my previous production > never had any check using tls. Maybe but then I don't remember about all the detailed rules in place that indicate when check-ssl *has* to be used. I'll have to read the doc. At this point I'm starting to think that we should probably avoid as much as possible to use implicit settings for whatever is dynamic. Originally a lot of settings were implicit because we don't want to have huge config lines to enforce lots of obvious settings. On the CLI it's less of a problem and for example if "ssl" only deals with the traffic without manipulating the checks, I'm personally not shocked, because these are normally sent by bots and we don't care if they have to set a few more settings to avoid multiple implicit changes that may not always be desired. This is where the CLI (or any future API) might differ a bit from the config, and an agent writing some config might have to explicitly state certain things like "no-check-ssl" for example to stay safe and avoid such implicit dependencies. Note that such a brainstorming doesn't apply to your fix and should not hold it from being merged in any way, I'm just speaking in the general sense, as I don't feel comfortable with keep all these special cases in a newly introduced API, that are only there for historical reasons. > > it > > would be worth rechecking, because if that's the case, maybe we should > > not backport it to 2.4 and only document a behavior change between 2.4 > > and 2.5. > > If you could have a double-check at the history behind this, that would > > be nice so that we know how far to backport it. By the way, maybe your > > proposed alternative would be acceptable for older versions which do not > > allow to enable SSL health checks on the CLI. > > unless I missed something, for me the current behavior is broken as > you can't come back to a working state if you are using tls on both > traffic and health check path. That's my understanding as well. > The only working setup is when you are > using `no-check-ssl` in your default server. In that sense I believe > it should be backported to v2.4. If you're *certain* that we're not going to break existing 2.4 deployments that could rely on the current behavior, I'm fine with that. It's just that I absolutely hate behavior changes in stable versions because we tend to think we've seen all corner cases, and after a release someone reports an issue :-/ I can't think of a case which would benefit from the current bug, I'm just trying to be careful. Thanks! Willy
Re: [PATCH] BUG/MEDIUM: server: avoid changing healthcheck ctx with set server ssl
On Sat, Jan 8, 2022 at 3:03 PM Tim Düsterhus wrote: > Causes issues when applying the patch, because git gets confused and > believes this to be the patch. > I tend to indent this type of "literal code block" within my commit > message with 4 spaces for clarity. indeed, good point, will fix if I have to resend a v2 On Mon, Jan 10, 2022 at 7:51 AM Willy Tarreau wrote: > It's important to always keep in mind that checks are not necessarily > related to the production traffic, and that configuring one part should > not have any impact on the other one. By default a server running in SSL > will not be checked using SSL unless "check-ssl" is set. note it is only true in your example if you use another port. > You could for > example have a server forwarding to multiple ports (say 80 and 443) and > decide to check only one of them, or even check another one. > > As such, I think your patch is correct as it only affects what the user > attempts to modify. I suspect that the reason for your initial choice was > that it was not yet possible by then to enable SSL checks manually, sorry what do you mean by manually? "check-ssl" has been available for a long time, so that's not the reason behind it, but I guess you were referring to something else. I suspect I did a dumb copy/paste from the new_server function and probably never thought was possibly wrong as my previous production never had any check using tls. > it > would be worth rechecking, because if that's the case, maybe we should > not backport it to 2.4 and only document a behavior change between 2.4 > and 2.5. > If you could have a double-check at the history behind this, that would > be nice so that we know how far to backport it. By the way, maybe your > proposed alternative would be acceptable for older versions which do not > allow to enable SSL health checks on the CLI. unless I missed something, for me the current behavior is broken as you can't come back to a working state if you are using tls on both traffic and health check path. The only working setup is when you are using `no-check-ssl` in your default server. In that sense I believe it should be backported to v2.4. -- William
Re: Issue with uploads and HAProxy 2.4.11
Le 1/10/22 à 14:46, Christian Ruppert a écrit :
On 2022-01-10 13:33, Sander Klein wrote:
Hi,
I've upgraded to HAProxy 2.4.11 and now I seem to have a problem with
bigger file uploads (>70MB).
When uploading a file I get a 500 back from HAProxy, and if I retry it
immediately it most of the time succeeds. Downgrading to 2.4.10 fixes
the issue. The log I get is:
Jan 10 12:09:45 [redacted] haproxy[21823]: 2001:67c:[redacted]
[10/Jan/2022:12:09:20.543] [redacted]~ [redacted]/[redacted]
11198/0/0/-1/25137 500 1991 - - IH-- 957/282/0/0/0 0/0
{[redacted].[redacted].com|Mozilla/5.0
(Mac|80349066|https://[redacted].[redacted].com/upload} {} “POST
https://[redacted].[redacted].com/upload/process?projectId=3431=149
HTTP/2.0”
The frontend is HTTP/2.0 and the backend is NGINX talking HTTP/1.1
(non-TLS).
The config is quite large, but I think it boils down to:
---
frontend [redacted]
bind [redactes]]:80 transparent
bind 2001:67c:[redacted]:80 transparent
bind [redacted]:443 transparent ssl crt /etc/haproxy/ssl/[redacted]
strict-sni alpn h2,http/1.1 npn h2,http/1.1
bind 2001:67c:[redacted]:443 transparent ssl crt
/etc/haproxy/ssl/[redacted] strict-sni alpn h2,http/1.1 npn
h2,http/1.1
mode http
maxconn 16384
option httplog
option dontlog-normal
option http-ignore-probes
option forwardfor
option http-buffer-request
capture request header Host len 64
capture request header User-Agent len 16
capture request header Content-Length len 10
capture request header Referer len 256
capture response header Content-Length len 10
acl [some ACLs here]
acl [some ACLs here]
http-request deny if [an ACL]
http-request deny if [another ACL]
use_backend [failing-backend] if [ACL]
use_backend
%[req.hdr(host),lower,regsub(^www\.,,i),map(/etc/haproxy/map.d/file.map,yes-backend)]
default_backend another-backend
backend failing-backend
fullconn256
modehttp
balance roundrobin
option abortonclose
option prefer-last-server
option redispatch
option httpchk GET /check-thingy HTTP/1.0
http-check expect status 200
default-server weight 100 maxconn 20 check inter 2s rise 3 fall 3
slowstart 5m agent-check agent-port 8081 agent-inter 20s
server server1 [redacted]:80 cookie cookie1
server server2 [redacted]:80 cookie cookie2
# Sorry Server
server outage 127.0.0.1:80 backup
retries 1
---
If any more info is needed, please let me know.
Regards,
Sander Klein
Hi Sander,
this might be also related to
https://github.com/haproxy/haproxy/issues/1510
Thanks Christian. Indeed, it is most probably the same issue. The proposed patch
is in attachment. The 2.6 and 2.5 are also affected.
--
Christopher FauletFrom 2984ccfc1f5c4ca1157f7a498dcdc7de2f7ba934 Mon Sep 17 00:00:00 2001
From: Christopher Faulet
Date: Mon, 10 Jan 2022 17:27:51 +0100
Subject: [PATCH] BUG/MAJOR: mux-h1: Don't decrement .curr_len for unsent data
A regression was introduced by commit 140f1a585 ("BUG/MEDIUM: mux-h1: Fix
splicing by properly detecting end of message"). To detect end of the
outgoing message, when the content-length is announced, we count amount of
data already sent. But only data really sent must be counted.
If the output buffer is full, we can fail to send data (fully or
partially). In this case, we must take care to only count sent
data. Otherwise we may think too much data were sent and an internal error
may be erroneously reported.
This patch should solve issue #1511. It must be backported as far as 2.4.
---
src/mux_h1.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mux_h1.c b/src/mux_h1.c
index f9a6120fe4..c2dc80834d 100644
--- a/src/mux_h1.c
+++ b/src/mux_h1.c
@@ -2180,7 +2180,6 @@ static size_t h1_process_output(struct h1c *h1c, struct buffer *buf, size_t coun
H1_EV_TX_DATA|H1_EV_STRM_ERR|H1_EV_H1C_ERR|H1_EV_H1S_ERR, h1c->conn, h1s);
goto error;
}
- h1m->curr_len -= vlen;
}
if ((h1m->flags & H1_MF_RESP) && (h1s->flags & H1S_F_BODYLESS_RESP)) {
TRACE_PROTO("Skip data for bodyless response", H1_EV_TX_DATA|H1_EV_TX_BODY, h1c->conn, h1s, chn_htx);
@@ -2226,6 +2225,8 @@ static size_t h1_process_output(struct h1c *h1c, struct buffer *buf, size_t coun
H1_EV_TX_DATA|H1_EV_TX_BODY, h1c->conn, h1s, 0, (size_t[]){v.len});
skip_data:
+if (h1m->state == H1_MSG_DATA && (h1m->flags & H1_MF_CLEN))
+ h1m->curr_len -= vlen;
if (last_data)
goto done;
break;
--
2.33.1
Issue with uploads and HAProxy 2.4.11
Hi,
I've upgraded to HAProxy 2.4.11 and now I seem to have a problem with
bigger file uploads (>70MB).
When uploading a file I get a 500 back from HAProxy, and if I retry it
immediately it most of the time succeeds. Downgrading to 2.4.10 fixes
the issue. The log I get is:
Jan 10 12:09:45 [redacted] haproxy[21823]: 2001:67c:[redacted]
[10/Jan/2022:12:09:20.543] [redacted]~ [redacted]/[redacted]
11198/0/0/-1/25137 500 1991 - - IH-- 957/282/0/0/0 0/0
{[redacted].[redacted].com|Mozilla/5.0
(Mac|80349066|https://[redacted].[redacted].com/upload} {} “POST
https://[redacted].[redacted].com/upload/process?projectId=3431=149
HTTP/2.0”
The frontend is HTTP/2.0 and the backend is NGINX talking HTTP/1.1
(non-TLS).
The config is quite large, but I think it boils down to:
---
frontend [redacted]
bind [redactes]]:80 transparent
bind 2001:67c:[redacted]:80 transparent
bind [redacted]:443 transparent ssl crt /etc/haproxy/ssl/[redacted]
strict-sni alpn h2,http/1.1 npn h2,http/1.1
bind 2001:67c:[redacted]:443 transparent ssl crt
/etc/haproxy/ssl/[redacted] strict-sni alpn h2,http/1.1 npn h2,http/1.1
mode http
maxconn 16384
option httplog
option dontlog-normal
option http-ignore-probes
option forwardfor
option http-buffer-request
capture request header Host len 64
capture request header User-Agent len 16
capture request header Content-Length len 10
capture request header Referer len 256
capture response header Content-Length len 10
acl [some ACLs here]
acl [some ACLs here]
http-request deny if [an ACL]
http-request deny if [another ACL]
use_backend [failing-backend] if [ACL]
use_backend
%[req.hdr(host),lower,regsub(^www\.,,i),map(/etc/haproxy/map.d/file.map,yes-backend)]
default_backend another-backend
backend failing-backend
fullconn256
modehttp
balance roundrobin
option abortonclose
option prefer-last-server
option redispatch
option httpchk GET /check-thingy HTTP/1.0
http-check expect status 200
default-server weight 100 maxconn 20 check inter 2s rise 3 fall 3
slowstart 5m agent-check agent-port 8081 agent-inter 20s
server server1 [redacted]:80 cookie cookie1
server server2 [redacted]:80 cookie cookie2
# Sorry Server
server outage 127.0.0.1:80 backup
retries 1
---
If any more info is needed, please let me know.
Regards,
Sander Klein
