ach reload. Running 2.5 with
fab0fdce981149a4e3172f2b81113f505f415595 seems to fix the issue for me.
https://github.com/haproxy/haproxy/commit/fab0fdce981149a4e3172f2b81113f505f415595
--
Regards,
Christian Ruppert
likely the best place for this. It had
been awhile since I've used it, but there have been times I did
special, unsupported builds in COPR for others to use.
Hope this helps.
Ryan
Links:
--
[1] http://haproxy.debian.net
--
Regards,
Christian Ruppert
g/msg39689.html
--
Regards,
Christian Ruppert
On 2022-08-01 09:45, Christian Ruppert wrote:
On 2022-07-29 13:59, William Lallemand wrote:
On Fri, Jul 29, 2022 at 11:10:32AM +0200, Christopher Faulet wrote:
Le 7/29/22 à 10:13, Christian Ruppert a écrit :
> Hi list,
>
> so I noticed on my private HAProxy I have 2 of those logs w
Hey,
I've got a kinda strange problem with UNIX sockets. I first thought it's
a Varnish issue but it may be actually be a HAProxy one.
So I've this attached test config, a static error file and a test script
(perl, no third party modules, just a few lines), which I'd like to
share only off-l
On 2022-08-19 11:50, Christian Ruppert wrote:
On 2022-08-01 09:45, Christian Ruppert wrote:
On 2022-07-29 13:59, William Lallemand wrote:
On Fri, Jul 29, 2022 at 11:10:32AM +0200, Christopher Faulet wrote:
Le 7/29/22 à 10:13, Christian Ruppert a écrit :
> Hi list,
>
> so I noti
flags=HTX|NO_UPG
: mode=TCP side=FE|BE mux=PASS flags=
none : mode=TCP side=FE|BE mux=PASS flags=NO_UPG
Available services : prometheus-exporter
Available filters :
[BWLIM] bwlim-in
[BWLIM] bwlim-out
[CACHE] cache
[COMP] compression
[FCGI] fcgi-app
[SPOE] spoe
[TRACE] trace
--
Regards,
Christian Ruppert
lly
don't get it.
I really wonder if that's a HAProxy bug.
--
Regards,
Christian Ruppert
On 2023-03-03 16:37, Christopher Faulet wrote:
Le 3/3/23 à 15:40, Christian Ruppert a écrit :
So I can reproduce it. I captured the response, extracted the data
which
includes to entire header + payload. I put that into a file like
foo.bin
and I start a "nc" that just serves that on
On 2023-03-13 15:50, Christopher Faulet wrote:
Le 3/6/23 à 08:50, Christian Ruppert a écrit :
On 2023-03-03 16:37, Christopher Faulet wrote:
Le 3/3/23 à 15:40, Christian Ruppert a écrit :
So I can reproduce it. I captured the response, extracted the data
which
includes to entire header
hands.
Cheers,
Willy
Enjoy your holidays and rest! :)
--
Regards,
Christian Ruppert
ometheus-exporter
Available filters :
[SPOE] spoe
[CACHE] cache
[FCGI] fcgi-app
[TRACE] trace
[COMP] compression
--
Regards,
Christian Ruppert
Hi Olivier,
On 2020-03-27 14:50, Olivier Houchard wrote:
Hi Christian,
On Fri, Mar 27, 2020 at 02:37:41PM +0100, Christian Ruppert wrote:
Hi list,
we have some weird issues now, the second time, that *some* SSL
sockets
seem to be broken as well as stats sockets.
HTTP seems to work fine
020-03-27 15:00, Christian Ruppert wrote:
Hi Olivier,
On 2020-03-27 14:50, Olivier Houchard wrote:
Hi Christian,
On Fri, Mar 27, 2020 at 02:37:41PM +0100, Christian Ruppert wrote:
Hi list,
we have some weird issues now, the second time, that *some* SSL
sockets
seem to be broken as well as stats sock
someotherlistener: cannot bind socket [:::18540]
So during the reload, this happened and seems to have caused any further
issues/trouble.
On 2020-03-27 15:10, Christian Ruppert wrote:
So now I looked for more of those "SC"'s in the log, from our
monitoring and it appeared first around 13:38:0
On 2020-03-27 16:27, Olivier Houchard wrote:
On Fri, Mar 27, 2020 at 04:21:20PM +0100, Christian Ruppert wrote:
During the reload I just found something in the daemon log:
Mar 27 13:37:54 somelb haproxy[20799]: [ALERT] 086/133748 (20799) :
Starting proxy someotherlistener: cannot bind socket
On 2020-03-27 16:49, Olivier Houchard wrote:
On Fri, Mar 27, 2020 at 04:32:21PM +0100, Christian Ruppert wrote:
On 2020-03-27 16:27, Olivier Houchard wrote:
> On Fri, Mar 27, 2020 at 04:21:20PM +0100, Christian Ruppert wrote:
>> During the reload I just found something in the daemon lo
On 2020-03-27 16:58, Christian Ruppert wrote:
On 2020-03-27 16:49, Olivier Houchard wrote:
On Fri, Mar 27, 2020 at 04:32:21PM +0100, Christian Ruppert wrote:
On 2020-03-27 16:27, Olivier Houchard wrote:
> On Fri, Mar 27, 2020 at 04:21:20PM +0100, Christian Ruppert wrote:
>> During the
ble to catch that one via test case
(regtest).
--
Regards,
Christian Ruppert
ul 03, 2020 at 11:02:48AM +0200, Christian Ruppert wrote:
> Hi List,
>
> we've just noticed and confirmed some strange change in behavior, depending
> on whether the request is made with HTTP 1.x or 2.x.
> [...]
> That also affects ACLs like url*/path* and probably others.
>
ke to know like where a bot triggered some action and stuff like
that.
--
Regards,
Christian Ruppert
Hey Willy,
On 2020-12-21 11:36, Willy Tarreau wrote:
Hi,
On Sun, Dec 20, 2020 at 12:58:52PM +0500, ??? wrote:
ping :)
Oh I completely missed this one in the noise it seems! I'm sorry.
No problem! :)
> Author: Christian Ruppert
> Number of patches: 1
>
> Thi
No Problem at all. Feel free :)
On 2020-12-21 12:59, Willy Tarreau wrote:
On Mon, Dec 21, 2020 at 12:20:36PM +0100, Christian Ruppert wrote:
> 2) we include from this file so that it becomes
> consistent
> with everything else ;
>
> 3) we add the ifdef VAR_ARRAY di
Hi list, Christopher,
we're having issues with the mentioned commit / patch:
d13afbcce5e664f9cfe797eee8c527e5fa947f1b
https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=d13afbcce5e664f9cfe797eee8c527e5fa947f1b
I can also reproduce it with 2.2.9 as well as 2.3.5. I don't have any
useful detai
On 2021-02-08 14:46, Christopher Faulet wrote:
Le 08/02/2021 à 14:31, Christian Ruppert a écrit :
Hi list, Christopher,
we're having issues with the mentioned commit / patch:
d13afbcce5e664f9cfe797eee8c527e5fa947f1b
https://git.haproxy.org/?p=haproxy-2.2.git;a=com
On 2021-02-10 18:15, Christopher Faulet wrote:
Le 08/02/2021 à 14:31, Christian Ruppert a écrit :
Hi list, Christopher,
we're having issues with the mentioned commit / patch:
d13afbcce5e664f9cfe797eee8c527e5fa947f1b
https://git.haproxy.org/?p=haproxy-2.2.git;a=com
an you confirm this behavior? Is there any other way I
could figure out whether a backend is currently in use?
--
Regards,
Christian Ruppert
On 2021-02-12 12:06, William Dauchy wrote:
Hi Christian,
On Fri, Feb 12, 2021 at 11:59 AM Christian Ruppert
wrote:
Is this a bug? Can you confirm this behavior? Is there any other way I
could figure out whether a backend is currently in use?
unfortunately reload does not recover stats
altogether). Less
context switching, might improve performance)
Hope that helps,
Conrad
On 10/21/2016 04:47 PM, Christian Ruppert wrote:
Hi,
again a performance topic.
I did some further testing/benchmarks with ECC and nbproc >1. I was
testing
on a "E5-2697 v4" and the first thin
Hi Willy,
On 2016-11-25 14:30, Willy Tarreau wrote:
Hi Christian,
On Fri, Nov 25, 2016 at 12:12:06PM +0100, Christian Ruppert wrote:
I'll compare HT/no-HT afterwards. In my first tests it didn't same to
make
much of a difference o far.
I also tried (in this case) to disable HT en
On 2016-11-25 14:44, Christian Ruppert wrote:
Hi Willy,
On 2016-11-25 14:30, Willy Tarreau wrote:
Hi Christian,
On Fri, Nov 25, 2016 at 12:12:06PM +0100, Christian Ruppert wrote:
I'll compare HT/no-HT afterwards. In my first tests it didn't same to
make
much of a difference o f
On 2016-11-25 15:26, Willy Tarreau wrote:
On Fri, Nov 25, 2016 at 02:44:35PM +0100, Christian Ruppert wrote:
I have a default bind for process 1 which is basically the http
frontend and
the actual backend, RSA is bound to another, single process and ECC is
bound
to all the rest. So in this
go beyond the limit of 64 or just the ones >64 which is
currently not possible. Is there any reason to limit the cpu/-set value
instead of just the number of processes?
--
Regards,
Christian Ruppert
Hi Willy,
please see the attached patch that fixes linking / LDFLAGS order of some
contrib modules which is related to e.g. linking with -Wl,--as-needed.
--
Regards,
Christian RuppertFrom c702537864f7e062d18f4ccce3e29d14d4ccf05f Mon Sep 17 00:00:00 2001
From: Christian Ruppert
Date: Thu, 30
the problem. I suspect the issue is located in the
propagation
of the frontend's mask to the listener, I'll look at this.
Thanks!
Willy
-Patrick
--
Regards,
Christian Ruppert
not support HTTP/2 properly.
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0
Can anybody else confirm that? Tested with HAProxy 1.9.6.
Any ideas what might be the reason? Right now, I'd guess that's a
Problem with H/2 and those sockets on the HAProxy side.
--
Regards,
Christian Ruppert
esn't help.
On 2019-04-23 15:57, Christian Ruppert wrote:
Hey,
we have an older setup using nbproc >1 and having a listener for the
initial tcp connection and one for the actual SSL/TLS, also using tcp
mode which then goes to the actual frontend using http mode. Each
being bound to differ
2test_tcp.tls"
On 2019-04-24 15:06, Willy Tarreau wrote:
Hi Christian,
On Wed, Apr 24, 2019 at 02:29:40PM +0200, Christian Ruppert wrote:
Hi,
so I did some more tests and it seems to be an issue between
h2test_tcp.tls
and the frontend, using the UNIX sockets. Adding a TCP bind to that
liste
plink
mode http
option httplog
log global
# ...
So it would be cool if both were possible, H2 as well as H1 via that
socket, using "alpn h2,http/1.1"
--
Regards,
Christian Ruppert
Hi Jarno,
On 2019-06-04 12:44, Jarno Huuskonen wrote:
Hi Christian,
On Thu, Apr 25, Christian Ruppert wrote:
listen genlisten_10320-cust1.tls-tcp
acl REQ_TLS_HAS_ECC req.ssl_ec_ext eq 1
tcp-request content accept if { req_ssl_hello_type 1 } # Match
Client SSL Hello
the
old process and proceed with the old child until the problem has been
fixed.
Can anybody confirm that? Is that intended?
https://cbonte.github.io/haproxy-dconv/2.0/management.html#4
https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#3.1-master-worker
--
Regards,
Christian Ruppert
haproxy
in waitpid mode, then the master exiting with the usage message in your
logs.
--
Regards,
Christian Ruppert
ck's status properly?
I'd like to avoid using an external check script to do all those checks.
--
Regards,
Christian Ruppert
Hi Aleks,
On 2019-11-21 11:01, Aleksandar Lazic wrote:
Hi.
Am 21.11.2019 um 10:49 schrieb Christian Ruppert:
Hi list,
for an old exchange cluster I have some check listener like:
listen chk_s015023
bind 0.0.0.0:1001
mode http
monitor-uri /check
tcp
On 2019-11-20 11:05, William Lallemand wrote:
On Wed, Nov 20, 2019 at 10:19:20AM +0100, Christian Ruppert wrote:
Hi William,
thanks for the patch. I'll test it later today. What I actually
wanted to
achieve is:
https://cbonte.github.io/haproxy-dconv/2.0/management.html#4 Then
HAProxy
0
[5] http://10.3.54.43:62403
[6] http://10.3.20.30:445
--
Regards,
Christian Ruppert
o not allocate
more than
4096 filters ‐ or applications should not create more than 4096 outgoing
connections.
The limit does not apply to inbound connections to a listening socket.
On 2017-12-20 13:11, Christian Ruppert wrote:
Hi Elias,
I'm currently preparing a test setup including a SFN852
Hi guys,
I saw that 1.5.x will have IPv6 ACL support. Would it be possible to backport it
to 1.4.x? :)
I haven't looked at the patch yet though so I don't know how much work it may
be.
--
Regards,
Christian Ruppert
pgpScmPJYmYHN.pgp
Description: PGP signature
t; or "unless" statement,
indicating when the condition will trigger the action."
I would really like to see that fixed. Or is that on purpose?
Mit freundlichen Grüßen,
Christian Ruppert
Christian Ruppert
Systemadministrator
Babiel GmbH
Erkr
Hi Baptiste,
it is IMHO not really clear that brackets are for anonymous ACLs only.
Wouldn't it make sense to support it for use_backend as well?
It just makes things easier in my opinion.
Mit freundlichen Grüßen,
Christian Ruppert
----
Christian Ru
Grüßen,
Christian Ruppert
Christian Ruppert
Systemadministrator
Babiel GmbH
Erkrather Str. 224 a
D-40233 Düsseldorf
Tel: 0211-179349 0
Fax: 0211-179349 29
E-Mail: c.rupp...@babiel.com
Internet: http://www.babiel.com <h
the control socket by using socat:
https://code.google.com/p/haproxy-docs/wiki/UnixSocketCommands
So e.g. "disable server backend1/server1"
Or even via the stats interface with "stats admin if ...".
--
Regards,
Christian Ruppert
pgpOHYOzE_D16.pgp
Description: PGP signature
Hm, I haven't tried Apache yet but would that be a huge benefit compared
to a setup using nbproc > 1?
Hope this helps,
Lukas
[1] https://twitter.com/ngx_vbart/status/611956593324916736
--
Regards,
Christian Ruppert
~144 r/s
you're basically lost when being under attack. How did you guys solve
this problem?
External SSL offloading, using hardware crypto foo, special
cipher/settings tuning,
simply *much* more hardware or not yet at all?
--
Regards,
Christian Ruppert
ache will scale better currently, because its threading.
Hm, I haven't tried Apache yet but would that be a huge benefit
compared
to a setup using nbproc> 1?
I haven't tried it either, but yes, I would assume so. It also doesn't
block
other connections will handshaking new ones.
Regards,
Lukas
--
Regards,
Christian Ruppert
On 2016-03-17 00:14, Nenad Merdanovic wrote:
Hello,
On 3/16/2016 6:25 PM, Christian Ruppert wrote:
Some customers may require 4096 bit keys as it seems to be much more
decent than 2048 nowadays. So you may be limited here. A test with a
2048 bit Cert gives me around ~770 requests per second
On 2016-03-18 11:31, Christian Ruppert wrote:
Hi Willy,
On 2016-03-17 06:05, Willy Tarreau wrote:
Hi Christian,
On Wed, Mar 16, 2016 at 05:25:53PM +0100, Christian Ruppert wrote:
Hi Lukas,
On 2016-03-16 16:53, Lukas Tribus wrote:
>>The "option httpclose" was on purpose.
Hi Aleks,
On 2016-03-16 15:57, Aleksandar Lazic wrote:
Hi.
Am 16-03-2016 15:17, schrieb Christian Ruppert:
Hi,
this is rather HAProxy unrelated so more a general problem but
anyway..
I did some tests with SSL vs. non-SSL performance and I wanted to
share my
results with you guys but also
Hi Willy,
On 2016-03-17 06:05, Willy Tarreau wrote:
Hi Christian,
On Wed, Mar 16, 2016 at 05:25:53PM +0100, Christian Ruppert wrote:
Hi Lukas,
On 2016-03-16 16:53, Lukas Tribus wrote:
>>The "option httpclose" was on purpose. Also the client could (during a
>>attack)
lose".
The "option httpclose" was on purpose. Also the client could (during a
attack) simply do the same and achieve the same result. I don't think
that will help in such cases.
--
Regards,
Christian Ruppert
ntentional to not evaluate if there's just
something like
"use_backend somebackend if { ... }"
2. Why is the function called twice? That's only when using the ACL
variant.
Using the workaround with req_ssl_ver above just calls it once.
--
Regards,
Christian Ruppert
results into several
thousands of requests on our prod. systems but according to the logs it
can't be correct.
Does anybody else have similar weirdness or can you guys confirm false
values?
The *_cnt values seem to be ok but the *_rate ones seem to be false in
some cases.
--
Regards,
Christian Ruppert
again?
frontend SSL-Offload
bind :443 ssl crt ssl.pem ecdhe prime256v1
tcp-request connection accept if { src_get_gpc0(whitelist) eq 1 }
tcp-request connection reject
backend whitelist
stick-table type ip size 1m expire 1h nopurge store gpc0
Thanks
Seri
--
Regards,
Chri
if (!msg_cur) {
/* malformed message */
appctx->st0 = PEER_SESS_ST_ERRPROTO;
Thanks a lot for the fast investigation! The proposed patch seems to do
the trick :)
--
Regards,
Christian Ruppert
On 2016-03-29 10:58, Christian Ruppert wrote:
Hi Willy,
On 2016-03-25 18:17, Willy Tarreau wrote:
On Fri, Mar 25, 2016 at 01:53:50PM +0100, Willy Tarreau wrote:
I think it's even different (but could be wrong) since Christian
spoke
about counters suddenly doubling. The issue you
On 2016-03-29 15:13, Christian Ruppert wrote:
On 2016-03-29 10:58, Christian Ruppert wrote:
Hi Willy,
On 2016-03-25 18:17, Willy Tarreau wrote:
On Fri, Mar 25, 2016 at 01:53:50PM +0100, Willy Tarreau wrote:
I think it's even different (but could be wrong) since Christian
spoke
about cou
op here, even tough the bind uses the first / only one process anyway?
--
Regards,
Christian Ruppert
cc if HAS_ECC
server ecc unix@/var/run/haproxy_ssl_ecc.sock send-proxy-v2
use-server rsa if !HAS_ECC
server rsa unix@/var/run/haproxy_ssl_rsa.sock send-proxy-v2
frontend http_https_combined
mode http
bind-process 1-40
bind :80 process 1
bind unix@/var/run/haproxy_ssl_ecc.sock accept-proxy ssl crt
/etc/haproxy/ssltest.pem-ECC user haproxy process 4-40
bind unix@/var/run/haproxy_ssl_rsa.sock accept-proxy ssl crt
/etc/haproxy/ssltest.pem-RSA user haproxy process 3
...
default_backend somebackend
The plan was to have the same http performance as before, move SSL
termination onto other/independent processes and furthermore split RSA
and ECC. The "bind-process 1-40" is necessary because it's otherwise not
possible to bind the SSL binds to the other processes.
Please also note that you'll get a build warning that first needs
another
fix on listen_accept() which doesn't have the same prototype between
the
.c and the .h (!). I'll handle it as well.
Cheers,
Willy
--
Regards,
Christian Ruppert
On 2016-04-14 11:41, Willy Tarreau wrote:
Hi Christian,
On Thu, Apr 14, 2016 at 11:06:02AM +0200, Christian Ruppert wrote:
I've applied your patch and I just looked at the performance so far.
The
performance is still the same, so the lessperformant one is still less
performant tha
On 2016-04-14 11:06, Christian Ruppert wrote:
Hi Willy,
On 2016-04-14 10:17, Willy Tarreau wrote:
On Thu, Apr 14, 2016 at 08:55:47AM +0200, Lukas Tribus wrote:
Le me put it this way:
frontend haproxy_test
bind-process 1-8
bind :12345 process 1
bind :12345 process 2
bind :12345 process 3
e much easier/better IMHO.
--
Regards,
Christian Ruppert
Hi Dennis,
On 2016-04-16 02:13, Dennis Jacobfeuerborn wrote:
On 15.04.2016 16:01, Christian Ruppert wrote:
Hi,
would it be possible to inherit the SSL information from a SSL
listener/frontend via PROXY protocol?
So for example:
listen ssl-relay
mode tcp
...
server rsa unix@/var
case but it also happens with binds bound
to just one process.
--
Regards,
Christian Ruppert
200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
I actually thought I was using 1.6.9 on that host already so I just
upgraded and tried again some benchmarks but it looks like it's almost
equal at the first glance.
--
Regards,
Christian Ruppert
Hey guys,
just a thought... wouldn't it make sense to add an option to "tcp-request
connection reject" to disable the actual TCP RST? So, an attacker tries to
(keep) open a lot of ports:
a) HAProxy (configured with rate limiting etc.) does a "tcp-request connection
reject" which ends up as a TCP
side but don't notify
the remote side it will probably exhaust the attacker and we could handle more
connections and/or free and re-use such connections that has been classified too
much.
On 01/14/2015 05:28 PM, Baptiste wrote:
> On Wed, Jan 14, 2015 at 5:00 PM, Christian Ruppert
> wr
orwarded-For,-1) 192.168.1.2 # This *might* be
a special case... Not yet further verified.
frontend example
use_backend ... if foo
use_backend ... if foobar
--
Regards,
Christian Ruppert
Hi Willy,
On 2015-02-02 17:31, Willy Tarreau wrote:
Hi Christian,
On Mon, Feb 02, 2015 at 04:55:56PM +0100, Christian Ruppert wrote:
Hey,
are there some kind of global ACLs perhaps? I think that could be
really
useful. In my case I have ~70 frontends and ~100 backends. I often use
the same
le config.
Best regards,
; Yuan
--
Regards,
Christian Ruppert
fy my own dhparams file to avoid using those pre-generated ones
and/ore appending some to all certificates. Wouldn't it make sense to
allow it to be read from a file, globally?
--
Regards,
Christian Ruppert
params.pem
2048 was just an example. There is 1024 and IIRC 768 as well. One might
be forced to use 1024.
Also, according to the documentation HAProxy wouldn't allow/use anything
greater than tune.ssl.default-dh-param which is 1024 by default - unless
I misunderstood something.
--
Regards,
Christian Ruppert
81 matches
Mail list logo
