Re: Haproxy 1.8.26-1~bpo9+1

2020-08-13 Thread Erwin Schliske
> The patch was for the 2.0. It must be adapted for the 1.8. But, it is not
> necessary because the bug is now fixed in 2.0 and 1.8 :
>
>   * 2.0 : http://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=307f31ec
>   * 1.8 : http://git.haproxy.org/?p=haproxy-1.8.git;a=commit;h=179d316c


Thanks. I need the patch until 1.8.27 is released. I found it yesterday and
tested it successfully. The observed problem is now solved.

Best regards,
Erwin Schliske


Re: Haproxy 1.8.26-1~bpo9+1

2020-08-12 Thread Erwin Schliske
>
> Ok I confirm the issue on the 1.8 is related to the commit 6ad7cd981 and
> the
> provided patch should fix it (on 1.8 and 2.0). But I'm unable to reproduce
> the
> bug on the 2.2.
>

I also have the problem described in this thread with the 1.8.26. When
building with the mentioned patch I get this error:

src/mux_h2.c:3311:9: error: 'max' undeclared (first use in this function)
 if (max) {
 ^
src/mux_h2.c:3311:9: note: each undeclared identifier is reported only once
for each function it appears in
make: *** [src/mux_h2.o] Error 1


Best regards,
Erwin Schliske


Re: unique-id-header set twice

2016-05-04 Thread Erwin Schliske
Hello,

I described the case haproxy->application->haproxy.

My preferred behavior would be that the header is set only if it is not
present already.

Our goal is tracing requests through our whole stack. This can be for
example

Haproxy --> Varnish --> Haproxy --> Application --> Backend

We could achieve the desired behavior , if we did not set the option
​globally ​
and would then only deal with ACLs to
​set the ​
header if it does not exist . But since we have quite a few front ends ,
the expense of this would be quite high
​.


Regards,
Erwin​






2016-05-01 7:43 GMT+02:00 Willy Tarreau <w...@1wt.eu>:
>
> On Sat, Apr 30, 2016 at 05:47:49PM +0100, Jonathan Matthews wrote:
> > On 29 Apr 2016 06:55, "Willy Tarreau" <w...@1wt.eu> wrote:
> > >
> > > On Fri, Apr 22, 2016 at 04:37:04PM +0200, Erwin Schliske wrote:
> > > > Hello,
> > > >
> > > > for some of our services requests pass haproxy twice. As we have
set the
> > > > global option unique-id-header this header is added twice.
> > [snip]
> > >
> > > I don't know what could cause this. Would you happen to have it in a
> > > defaults section maybe, with your traffic passing through a frontend
> > > and a backend ? If that's what causes it, I think we have a mistake
> > > in the implementation and should ensure it's done only once, just like
> > > x-forwarded-for.
> >
> > I /think/ you're talking at slight cross-porpoises!
> >
> > My reading of the OP is that when a request comes in to a
frontend/listener
> > with the configured unique-Id header already present, then a second UID
> > header is added.
> >
> > My reading of your post, Willy, is that this would be a bug (which might
> > suggest why unique-id-header isn't ACL-able?). But I may have
misunderstood
> > - you may be talking solely about when a request crosses a
frontend/backend
> > boundary, and not when the request comes in the front door anew (even
if it
> > was, as per the OP, a request coming back in directly from a backend).
>
> What I'm describing is the fact that HTTP processing is performed in the
> frontend and in the backend. If *both* the frontend and the backend do
> the same operation, then it can result in this operation being performed
> twice. I'm not saying this is necessarily the case with unique-id-header,
> I haven't checked, but the description of the problem makes me think about
> this.
>
> > Am I right, both? I only ask because this has bugged me slightly in the
> > past, and it'd be great to clear up the definition of the UID header
> > option: When enabled, is the header's addition predicated on its initial
> > absence?
>
> No, for me it's unconditionally performed at one specific point in the
> code. I don't even remember if the original header is automatically
> removed or needs to be removed manually.
>
> Ok, now checked the code :
>
> - in http_process_request() we have this :
>
> if (sess->fe->header_unique_id && s->unique_id) {
> chunk_printf(, "%s: %s",
sess->fe->header_unique_id, s->unique_id);
> if (trash.len < 0)
> goto return_bad_req;
> if (unlikely(http_header_add_tail2(>req,
>hdr_idx, trash.str, trash.len) < 0))
>goto return_bad_req;
> }
>
>   => so as you can see the info is retrieved only from the frontend.
>  And this analyser is called only once and cannot yield so it
>  cannot be the cause of the problem.
>
> However it's not automatically removed so if the request passes
> twice through haproxy (eg: haproxy->application->haproxy) and no
> explicit rule to remove it is present, then you'll have it twice.
>
> Willy
>


unique-id-header set twice

2016-04-22 Thread Erwin Schliske
Hello,

for some of our services requests pass haproxy twice. As we have set the
global option unique-id-header this header is added twice.

Is there a way to avoid this? I could set the header with 'http-request
set-header', but
​ this cannot be configured globally.

Thanks.

Regards,
Erwin​


Re: SPDY with Apache mod_spdy

2015-01-29 Thread Erwin Schliske
Thanks.

Your suggestion works.

Regards,
Erwin

2015-01-27 21:21 GMT+01:00 Baptiste bed...@gmail.com:

 On Tue, Jan 27, 2015 at 7:21 PM, Erwin Schliske
 erwin.schli...@sevenval.com wrote:
  Hello,
 
  actually I have the task to setup a system with Haproxy balancing a
 Apache
  with mod_spdy enabled. I don't have a problem with ssl-offloading, but I
  cannot find out how to serve spdy enabled clients. I have tried several
  howtos like
 
 
 http://www.igvita.com/2012/10/31/simple-spdy-and-npn-negotiation-with-haproxy/
 
  My config is:
 
  listen spdytest
modetcp
bind  X.X.X.X:443 ssl crt /etc/haproxy/ssl/example.com.pem
  no-sslv3 npn spdy/2
server   backend1 10.X.X.X:1443 ssl
 
  All tutorials I've found use Nginx as webserver, which can serve spdy
  without ssl. But this is not the case with Apache mod_spdy. It needs
 https
  as proto.
 
  Does someone have a hint what I'm doing wrong?
 
 
  Thanks.


 Hi Erwin,

 HAProxy does not send the ALPN (or NPN) SSL extension to the server
 side with your configuration.
 Simply failover to a SSL forward configuration:
  listen spdytest
modetcp
bind  X.X.X.X:443
server   backend1 10.X.X.X:1443

 Baptiste



SPDY with Apache mod_spdy

2015-01-27 Thread Erwin Schliske
Hello,

actually I have the task to setup a system with Haproxy balancing a Apache
with mod_spdy enabled. I don't have a problem with ssl-offloading, but I
cannot find out how to serve spdy enabled clients. I have tried several
howtos like

http://www.igvita.com/2012/10/31/simple-spdy-and-npn-negotiation-with-haproxy/

My config is:

listen spdytest
  modetcp
  bind  X.X.X.X:443 ssl crt /etc/haproxy/ssl/example.com.pem
no-sslv3 npn spdy/2
  server   backend1 10.X.X.X:1443 ssl

All tutorials I've found use Nginx as webserver, which can serve spdy
without ssl. But this is not the case with Apache mod_spdy. It needs https
as proto.

Does someone have a hint what I'm doing wrong?


Thanks.


Regards,
Erwin


Re: How to negate options

2014-11-24 Thread Erwin Schliske
Hi,

works perfectly. Thanks a lot.

Regards,
Erwin

2014-11-21 17:05 GMT+01:00 Baptiste bed...@gmail.com:

 On Fri, Nov 21, 2014 at 2:47 PM, Erwin Schliske
 erwin.schli...@sevenval.com wrote:
  Hello,
 
  I have one question which I cannot solve on my own.
 
  In my defaults I set this options.
 
  option httplog
  option forwardfor
  option http-pretend-keepalive
 
  All of my frontends are http-frontends. Now I have a frontend, which I
 have
  to run with mode tcp. If I reload the config I get this warnings.
 
  root@haproxy1:~ :( # /etc/init.d/haproxy reload
  haproxy neu laden: [WARNING] 324/143744 (28779) : parsing
  [/etc/haproxy/haproxy.cfg:48] : 'option httplog' not usable with proxy
  'moma_sms_01_mms' (needs 'mode http'). Falling back to 'option tcplog'.
  [WARNING] 324/143744 (28779) : config : 'option forwardfor' ignored for
  proxy 'moma_sms_01_mms' as it requires HTTP mode.
  [WARNING] 324/143744 (28779) : config : 'option http-pretend-keepalive'
  ignored for proxy 'moma_sms_01_mms' as it requires HTTP mode.
 
 
  Is it possible to set the defaults that they are only applied if they are
  valid or can I negate the defaults in this single frontend?
 
  Thanks.
 
  Regards,
 
  Erwin


 Hi Erwin,

 A defaults section applies parameters until the next defaults section.
 Simply create a defaults section for HTTP, one for TCP and move your
 frontends and backends accordingly and the warnings will disappear.

 Baptiste



How to negate options

2014-11-21 Thread Erwin Schliske
Hello,

I have one question which I cannot solve on my own.

In my defaults I set this options.

option httplog
option forwardfor
option http-pretend-keepalive

All of my frontends are http-frontends. Now I have a frontend, which I have
to run with mode tcp. If I reload the config I get this warnings.

root@haproxy1:~ :( # /etc/init.d/haproxy reload
 haproxy neu laden: [WARNING] 324/143744 (28779) : parsing
 [/etc/haproxy/haproxy.cfg:48] : 'option httplog' not usable with proxy
 'moma_sms_01_mms' (needs 'mode http'). Falling back to 'option tcplog'.
 [WARNING] 324/143744 (28779) : config : 'option forwardfor' ignored for
 proxy 'moma_sms_01_mms' as it requires HTTP mode.
 [WARNING] 324/143744 (28779) : config : 'option http-pretend-keepalive'
 ignored for proxy 'moma_sms_01_mms' as it requires HTTP mode.


Is it possible to set the defaults that they are only applied if they are
valid or can I negate the defaults in this single frontend?

Thanks.

Regards,

Erwin


PFS

2013-08-20 Thread Erwin Schliske
Hello, 

is it possible to use SSL with PFS (Perfect Forward Secrecy) in HaProxy 1.5?

Thanks.


Regards,
Erwin Schliske





Set ssl ciphers in defaults section

2013-06-20 Thread Erwin Schliske
Hello, 

is it possible to set our preferred ciphers in defaults section? Background is 
that we set as in 
http://blog.exceliance.fr/2013/01/21/mitigating-the-ssl-beast-attack-using-the-aloha-load-balancer-haproxy/
 described alternative ciphers to be secured against BEAST.

It would be great not to set this for every listen in the config.

Thanks.

Regards,
Erwin