Hi,
[if you've already read the 1.5-dev18 announce, you don't need to read
this one]
I'm announcing haproxy 1.4.23. It contains a security fix, users of 1.4
MUST upgrade or MUST apply the patch. Please read.
Configurations at risk are those which combine use of HTTP keywords in
TCP content insp
Hi,
here's an update for 1.5. It contains a security fix, please read, as
you'll want either to update or to apply the fix on top of your version
if you are running it.
Configurations at risk are those which combine use of HTTP keywords in
TCP content inspection rules, client-side keep-alive, hea
Hey Jim,
Here's the pertinent section from the docs
(http://cbonte.github.com/haproxy-dconv/configuration-1.4.html#4-balance)
"The source IP address is hashed and divided by the total
weight of the running servers to designate which server will
receive the request. Thi
oke the response forward state machine last evening
> > > then (the last 3 patches that went into 20130402), because all other
> > > patches are just cosmetic. I'm re-auditing the code now.
> >
> > OK I could reproduce using nginx only as well. I still don'
On Wed, Apr 03, 2013 at 12:11:35AM +0200, Willy Tarreau wrote:
> Hi Sander,
>
> On Tue, Apr 02, 2013 at 11:35:45PM +0200, Willy Tarreau wrote:
> > Sounds like I broke the response forward state machine last evening
> > then (the last 3 patches that went into 2013040
Hi Sander,
On Tue, Apr 02, 2013 at 11:35:45PM +0200, Willy Tarreau wrote:
> Sounds like I broke the response forward state machine last evening
> then (the last 3 patches that went into 20130402), because all other
> patches are just cosmetic. I'm re-auditing the code now.
OK I c
don't load, or
> partially load. And, the sites on the old cluster (apache) behave
> normally.
>
> I'm not sure, but it almost looks like the timing issue I had with
> POST's back in the early dev17 days. Although I'm doing a simple get
> right now.
So
On Tue, Apr 02, 2013 at 10:16:14PM +0200, Lukas Tribus wrote:
> > that leaves 87,88,89,93,94,95,96,99,100 and 101, right?
>
> git-bisect is your friend :)
>
>
> That said, I see some hangs after commit a890d072, but thats
> patch 104 and not in ss-20130402, so its a
Hi again Lukas,
OK I found it, it was a typo in my fix :-(
It is now fixed by commit ffb6f08ba
Thanks for reporting this quickly! I'm finishing the last
ACL/samples merge review and I think I'm OK.
Cheers,
Willy
Hi Lukas,
On Tue, Apr 02, 2013 at 10:27:31PM +0200, Lukas Tribus wrote:
> Hi Willy,
>
> since commit a890d072, the following frontend configuration
> (in http mode) hangs haproxy, debug output above.
>
> > acl iscluster1-2 hdr_sub(host) -i testdom2.local
> > use_backend cluster1-2
Hi Willy,
since commit a890d072, the following frontend configuration
(in http mode) hangs haproxy, debug output above.
> acl iscluster1-2 hdr_sub(host) -i testdom2.local
> use_backend cluster1-2 if iscluster1-2
After process_switching_rules haproxy seems to hang (new
connections d
> that leaves 87,88,89,93,94,95,96,99,100 and 101, right?
git-bisect is your friend :)
That said, I see some hangs after commit a890d072, but thats
patch 104 and not in ss-20130402, so its a separate issue
(I will post a new topic about this).
Willy, I would rather not issue dev-18
Can someone provide some insight into what's happening when balancing
based on source? Is it consistent across different haproxy instances?
For example, in a simple setup with one frontend balancing between two
backends, A and B - does balance source send 0.0.0.0-127.255.255.255 to
backend A and
Hi,
On 02.04.2013 21:37, Sander Klein wrote:
> I'm not sure, but it almost looks like the timing issue I had with
> POST's back in the early dev17 days. Although I'm doing a simple get
> right now.
that leaves 87,88,89,93,94,95,96,99,100 and 101, right?
cheers
thomas
Hi Thomas,
On 02.04.2013 21:02, Thomas Heil wrote:
Of course, it matters. As you explained the problem should be arround
patch 86 up to 101. How does you haproxy -vv
look like? Do you use compression or SSL? Could you eliminate Patch
91,92 and 98?
haproxy -vv looks like:
sander@lb01-a:~$ /us
Hi,
On 02.04.2013 20:49, Sander Klein wrote:
> Replying to myself again...
>
> On 02.04.2013 16:59, Sander Klein wrote:
>> Hi!,
>>
>> On 02.04.2013 16:16, Sander Klein wrote:
>>
>>> When using this config with ss-20130402 I do not get any traffic to
>&
Replying to myself again...
On 02.04.2013 16:59, Sander Klein wrote:
Hi!,
On 02.04.2013 16:16, Sander Klein wrote:
When using this config with ss-20130402 I do not get any traffic to
cluster1-2. I didn't have enough time to do a proper debug since I
was
doing it in production ;-) I
Hi!,
On 02.04.2013 16:16, Sander Klein wrote:
When using this config with ss-20130402 I do not get any traffic to
cluster1-2. I didn't have enough time to do a proper debug since I was
doing it in production ;-) I might have a better look at it this
evening. It works fine with ss-201
Hi,
Today I tried upgrading to haproxy-ss-20130402 and this gave me a lot
of problems.
I do something like:
# Web cluster
acl iscluster1-1-rlhdr_sub(host) -i somehost.com anotherhost.com
acl iscluster1-1 hdr(host) -f /etc/haproxy/cluster1-1.txt
acl iscluster1-2 hdr(host) -f
Hi Lukas,
On Tue, Apr 02, 2013 at 03:14:12PM +0200, Lukas Tribus wrote:
> > > So do you think it would make sense to introduce a new build flag for TFO
> > > and define TCP_FASTOPEN?
> > >
> > > This would be similar to USE_TPROXY, USE_LINUX_SPLICE or USE_ACCEPT4 I
> > > guess.
> > >
> > > That w
> > So do you think it would make sense to introduce a new build flag for TFO
> > and define TCP_FASTOPEN?
> >
> > This would be similar to USE_TPROXY, USE_LINUX_SPLICE or USE_ACCEPT4 I
> > guess.
> >
> > That way, users have a documented way to enable TFO with current libc's?
>
> Yes, that's an i
On Tue, Apr 02, 2013 at 01:53:21PM +0200, Marc-Antoine Perennou wrote:
> Formerly, if A was replaced by B, and then B by C before
> A finished exiting, we didn't wait for B to finish so it
> ended up as a zombie process.
> Fix this by waiting randomly every child we spawn.
applied, thank you !
Wi
Formerly, if A was replaced by B, and then B by C before
A finished exiting, we didn't wait for B to finish so it
ended up as a zombie process.
Fix this by waiting randomly every child we spawn.
Signed-off-by: Marc-Antoine Perennou
---
src/haproxy-systemd-wrapper.c | 10 --
1 file change
Hi Baptiste,
Thank you for your answer but I probably wasn't clear enough on my
problem ;-)
The problem is that the stick table in the example only stores IPv4 or
IPv6 not both. But I need to rate-limit both IPv4 and IPv6.
Just a copy and paste of the setup:
frontend cluster1-in
bind x.x.
Hi,
With latest HAProxy version, it will apply configuration to IPv4 or IPv6
independently.
Just add an IPv6 bind to your HAProxy setup and you're done.
no IPv6 to configure on your servers, since HAProxy will act as a 6to4
gateway:
http://blog.exceliance.fr/2011/06/14/layer-7-ipv6-configuration/
Hi All,
I know this question has been asked more times, but currently I'm
experiencing some problems with some people harvesting data from our
websites at high rates. I would like to block them based on the URL or
simply on src IP.
Currently I've implemented the 'Limiting the HTTP request ra
26 matches
Mail list logo
