Re: Frontend ACL rewrites URL incorrectly to backend

2015-10-05 Thread Daren Sefcik 
Hey Joris, I appreciate the help...I am not sure I quite understand though,
is there something I can configure in haproxy to resolve this? It is not
just a Wordpress problem, I have other sites also that do not behave
correctly when I put haproxy in front of them.

On Mon, Oct 5, 2015 at 8:22 AM, joris dedieu  wrote:

> Hi,
>
> 2015-10-04 23:33 GMT+02:00 Daren Sefcik :
> > I am trying to make some requests go to specific backends but am finding
> > that in certain backends that the url gets doubled up or otherwise
> mangled,
> > ie:
> >
> > request to frontend = http://my.company.com
> > what the backend server ends up with =
> > http://my.company.comhttp://my.company.com
> >
> > This does not happen in all of the backends, only a few...a wordpress
> site
>
> This is typically what append when wordpress is invoked with a wrong
> Host header.
> It must match WP_SITEURL and WP_HOME
>
> Regards
> Joris
>
> > comes to mind as a specific example. Since this does not happen on every
> > single backend server I suspect it is instead something happening on the
> > receiving server but since it only happens when I put haproxy in front
> of it
> > there is some connection between them.
> >
> > Can someone help me understand what haproxy is doing or how to fix this
> from
> > happening?
> > Before anyone says it is varnish doing it I should say several of the
> other
> > backends using varnish work fine, it is only a few that get the url
> messed
> > up.
> >
> > TIA
> >
> > example ACL:
> >
> > acl   acl_my.company.com hdr(host) -i my.company.com
> > use_backend  VARNISH_BKEND if acl_my.company.com
>

Re: [PATCH] BUG: config: external-check command validation is checking for incorrect arguments.

2015-10-05 Thread Ben Cabot 
Sorry I'd not noticed that. Everything looks good now thank you Willy.

Ben


On 4 October 2015 at 09:41, Willy Tarreau  wrote:

> Resending after some mails were lost du to low space on device...
>
> On Fri, Oct 02, 2015 at 11:15:35PM +0200, Willy Tarreau wrote:
> > On Fri, Oct 02, 2015 at 03:56:58PM +0200, Igor Wiedler wrote:
> > > Hello,
> > >
> > > I wanted to test the external-check option in 1.6 (master) and it
> seems like
> > > the validation logic is broken. I was wondering what the status of
> this patch
> > > is: http://marc.info/?l=haproxy=144240175729490=2
> > > . Can we get it
> merged?
> >
> > Just done, thanks for bringing it up, I indeed missed it!
> >
> > Ben, your mailer mangled the patch, I had to redo it by hand, it looks
> > OK but I would appreciate it if you could double-check.
> >
> > Thanks!
> > Willy
> >
>



-- 
LOADBALANCER.ORG LTD.
www.loadbalancer.org
supp...@loadbalancer.org

Re: [PATCH] BUG: config: external-check command validation is checking for incorrect arguments.

2015-10-05 Thread Willy Tarreau 
On Mon, Oct 05, 2015 at 06:33:36PM +0100, Ben Cabot wrote:
> Sorry I'd not noticed that. Everything looks good now thank you Willy.

OK thanks Ben.

Willy

Re: core dump, lua service, 1.6-dev6 ss-20150930

2015-10-05 Thread PiBa-NL 

Hi Thierry,

With or without "option http-server-close" does not seem to make any 
difference.


Adding a empty backend does seem to resolve the problem, stats also show 
the backend handling connections and tracking its 2xx http result 
session totals when configured like this.:


frontend http_frt
  mode http
  bind :801
  http-request use-service lua.hello-world
  default_backend http-lua-service
backend http-lua-service
  mode http

Op 5-10-2015 om 16:06 schreef Thierry FOURNIER:

Hi,

I process this email later. For waiting, I propose to you to set the
"option http-server-close". Actually, the "services" doesn't support
itself the keepalive, but HAProxy does this job.

The "option http-server-close" expectes a server-close from the service
stream. The front of HAProxy maintains the keep-alive between the
client and the haproxy.

This method embbed a limitation: if some servers are declared in the
backend, the "option http-server-close" forbid the keepalive between
haproxy and the serveur.

Can you test with this option ?

Thierry



On Thu, 1 Oct 2015 23:00:45 +0200
Cyril Bonté  wrote:


Hi,

Le 01/10/2015 20:52, PiBa-NL a écrit :

Hi List,

With the config below while running 'siege' i get a core dump within a
few hundreds of requests.. Viewing the stats page from a chrome browser
while siege is running seems to crash it sooner..

Is below enough to find the cause? Anything else i should try?

This is embarrassing because with your configuration, I currently can't
reproduce a segfault but I can reproduce another issue with HTTP
keep-alive requests !

(details below)


Using the haproxy snapshot from: 1.6-dev6 ss-20150930
Or perhaps i just did compile it wrong?..
make NO_CHECKSUM=yes clean debug=1 reinstall WITH_DEBUG=yes

global
  stats socket /tmp/hap.socket level admin
  maxconn 6
  lua-load /haproxy/brute/hello.lua

defaults
  timeout client 1
  timeout connect 1
  timeout server 1

frontend HAProxyLocalStats
  bind :2300 name localstats
  mode http
  stats enable
  stats refresh 1000
  stats admin if TRUE
  stats uri /
frontend http_frt
bind :801
mode http
http-request use-service lua.hello-world

Here, if I use :
$ ab -n100 -c1 -k http://127.0.0.1:801/
There will be a 1ms delay after the first request.

Or with another test case :
echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET /
HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
HTTP/1.1 200 OK
content-type: text/plain
Transfer-encoding: chunked

d
Hello World !
0

=> only 1 response

Now, if I change "frontend http_frt" to "listen http_frt", I get the
awaited behaviour.

The second test case with "listen" :
echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET /
HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
HTTP/1.1 200 OK
content-type: text/plain
Transfer-encoding: chunked

d
Hello World !
0

HTTP/1.1 200 OK
content-type: text/plain
Transfer-encoding: chunked

d
Hello World !
0

=> the 2 responses are returned


core.register_service("hello-world", "http", function(applet)
 local response = "Hello World !"
 applet:set_status(200)
 applet:add_header("content-type", "text/plain")
 applet:start_response()
 applet:send(response)
end )

(gdb) bt full
#0  0x000801a2da75 in memcpy () from /lib/libc.so.7
No symbol table info available.
#1  0x00417388 in buffer_slow_realign (buf=0x7d3c90) at
src/buffer.c:166
  block1 = -3306
  block2 = 0
#2  0x00480c42 in http_wait_for_request (s=0x80247d600,
req=0x80247d610, an_bit=4)
  at src/proto_http.c:2686
  cur_idx = -6336
  sess = (struct session *) 0x80241e400
  txn = (struct http_txn *) 0x802bb2140
  msg = (struct http_msg *) 0x802bb21a0
  ctx = {line = 0x2711079 , idx
= 3, val = 0, vlen = 7, tws = 0,
del = 33, prev = 0}
#3  0x004d55b1 in process_stream (t=0x80244b390) at
src/stream.c:1759
  max_loops = 199
  ana_list = 52
  ana_back = 52
  flags = 4227584
  srv = (struct server *) 0x0
  s = (struct stream *) 0x80247d600
  sess = (struct session *) 0x80241e400
  rqf_last = 8397312
  rpf_last = 2248179715
  rq_prod_last = 7
  rq_cons_last = 9
  rp_cons_last = 7
  rp_prod_last = 0
  req_ana_back = 8192
  req = (struct channel *) 0x80247d610
  res = (struct channel *) 0x80247d650
  si_f = (struct stream_interface *) 0x80247d7f8
  si_b = (struct stream_interface *) 0x80247d818
#4  0x0041fe78 in process_runnable_tasks () at src/task.c:238
  t = (struct task *) 0x80244b390
  max_processed = 0
#5  0x0040cc4e in run_poll_loop () at src/haproxy.c:1539
  next = 549107027
#6  0x0040daee in main (argc=4, argv=0x7fffeaf0) at
src/haproxy.c:1892
  err = 0
  retry = 200

Re: [PATCH 1/1] MINOR: cli: Dump all resolvers stats if no resolver

2015-10-05 Thread Willy Tarreau 
On Mon, Oct 05, 2015 at 11:57:08PM +0200, Baptiste wrote:
> Andrew,
> 
> My appologies about the proxy_find_by_name function, I was not in the
> right context!!!
> Tested and approved.
> 
> Willy, you can apply :)
> 
> Thanks a lot for your contribution, Andrew.

Applied, thanks guys!

Willy

Does Haproxy supports backend on https for reverse proxy

2015-10-05 Thread Kuchekar, Yogita (Yogita) 
Hi ,

I have installed Haproxy servere 5.1 on linux RHEL 6.1

I have configured Haproxy servere on linux at 80 port and trying to do reverse 
proxy with backend on https protocol (443). Is it possible in haparoxy ?
Client -->http traffic -->Haproxy server-->https traffic-->backend server


If I have Haproxy kistening to https traffic (have certificate support)and 
backend  server with https traffic, is  this reverse proxy supported in Haproxy 
?
   Client -->https traffic -->Haproxy server-->https 
traffic-->backend server


Is there any other solution for this scenario?
Really appreciate your help here.


Thanks,
Yogita

Re: Does Haproxy supports backend on https for reverse proxy

2015-10-05 Thread Bryan Talbot 
On Mon, Oct 5, 2015 at 12:49 PM, Kuchekar, Yogita (Yogita) <
ykuche...@avaya.com> wrote:

> Hi ,
>
>
>
> I have installed Haproxy servere 5.1 on linux RHEL 6.1
>


Assuming you mean haproxy version 1.5, then yes both scenarios are
possible. I'm sure you can find many blog posts and sample configurations
on this mailing list to get you started.

-Bryan




>
>
> I have configured Haproxy servere on linux at 80 port and trying to do
> reverse proxy with backend on https protocol (443). Is it possible in
> haparoxy ?
>
> Client -->http traffic -->Haproxy server-->https traffic-->backend server
>
>
>
>
>
> If I have Haproxy kistening to https traffic (have certificate support)and
> backend  server with https traffic, is  this reverse proxy supported in
> Haproxy ?
>
>Client -->https traffic -->Haproxy server-->https
> traffic-->backend server
>
>
>
>
>
> Is there any other solution for this scenario?
>
> Really appreciate your help here.
>
>
>
>
>
> Thanks,
>
> Yogita
>
>
>
>
>

Re: Does Haproxy supports backend on https for reverse proxy

2015-10-05 Thread Bryan Talbot 
On Mon, Oct 5, 2015 at 1:42 PM, Kuchekar, Yogita (Yogita) <
ykuche...@avaya.com> wrote:

> Thanks for your reply..
>
>
>
> Sorry for the typo. Version for Haproxy is 1.5.
>
>
>
> I have been trying to achieve this for a while referring to forum examples.
>
> My configuration is like this. Could you please point me to a working
> example .
>
>
>
> defaults
>
> modehttp
>
> log global
>
> option  httplog
>
> option  dontlognull
>
> option http-server-close
>
> option forwardfor   except 127.0.0.0/8
>
> option  redispatch
>
> retries 3
>
> timeout http-request10s
>
> timeout queue   1m
>
> timeout connect 10s
>
> timeout client  1m
>
> timeout server  1m
>
> timeout http-keep-alive 10s
>
> timeout check   10s
>
> maxconn 3000
>
>
>
> #-
>
> # main frontend which proxys to the backends
>
> #-
>
>
>
>
>
>  frontend www
>
>bind 10.177.222.83:80
>
>option http-server-close
>

Should not need to repease 'http-server-close' here since you have it in
default already.



>default_backend default-backend
>
>
>
>
>
> backend default-backend
>
>server adm-testing-platform 10.177.222.82:443 check
>
>
>
>

I think this would work if you were using non-ssl port 80 for the server
backend, but since you're using ssl port 443, you need to enable ssl
options for that server line. Specifically the 'ssl' and 'ca-file' options
detailed at
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.2

-Bryan

RE: req_ssl_ver ACL not working

2015-10-05 Thread Lukas Tribus 
Hi Julien,



>> Maybe you can also try with "curl --tlsv1.2" which should use a 3.3
>> version.
>
> That's a very interesting details. Indeed curl sets the HELLO version to
> 0x0303
> whereas OpenSSL uses 0x0301. Interestingly, both Firefox and Chrome also
> use 0x0301
> in the version of the record layer. In all cases though, the version of
> the handshake
> message is correctly set to 0x0303, as you would expect for TLS1.2.
>
> $ openssl s_client -connect jve.linuxwall.info:443 -tls1_2 -servername
> jve.linuxwall.info -debug|head
> CONNECTED(0003)
> write to 0x97a510 [0x984043] (342 bytes => 342 (0x156))
>  - 16 03 01 01 51 01 00 01-4d 03 03 22 95 43 27 f9
> Q...M..".C'.
> ^ ^^
> record layer version handshake version
>
> I would argue that HAProxy is doing the wrong thing here: the
> req_ssl_ver variable
> should return the handshake version, not the record layer version.

Agreed.


We really should ignore the record layer and use the client hello
version instead (smp_fetch_ssl_hello_sni() has code checking for both
if anyone has time to come up with a patch for req_ssl_ver).

We had similar bugs in the past in those code paths (parsing SSL manually,
see below).

For this use case specifically most SSL libraries and browsers try to be
most compatible, and since the record layer version doesn't impact the
handshake in any way (other than some hanging SSL servers if the record
layer is set to TLSv1.2), it is most often set to something low like
SSLv3 (GnuTLS) or TLSv1.0 (OpenSSL), because the record layer simply
doesn't matter.


Also see:
- rfc5246#appendix-E
- http://marc.info/?l=haproxy=139710628814932=2
- commit 57d229747 ("BUG/MINOR: acl: req_ssl_sni fails with SSLv3 record 
version")




Regards,

Lukas

RE:recycled shopping canvas bag / cotton canvas bag/ printing canvas bag 10/5/2015 4:46:04 PM

2015-10-05 Thread Custom_bags 
Dear Sir/Madam,

Good day!

This is RONTA(XIAMEN)CO.,LTD. We are specializing in design, development, 
production and sales of different types of bags for many years, the company 
passed ISO9001 quality system certification.

Following are some featured bags we’re doing:

1.Drawstring bags

2.Cotton canvas bags

3.Non-woven bags

4.Backpacks

5.Duffle bags

If you’re interested in any of them, please contact with us. We can talk about 
the details.

Best regards,

--

2015/10/5 16:46:04 60364.19

Re: Health check and flapping

2015-10-05 Thread Baptiste 
Hi,

I've not forgotten you, I'm just running out of time.

Baptiste


On Tue, Sep 29, 2015 at 5:43 PM,   wrote:
> Le 2015-08-28 16:40, Baptiste a écrit :
>>
>> Le 28 août 2015 15:45,  a écrit :
>>  >
>>  > Hello,
>>  >
>>  > We have tcp-check configured on some backends, which works fine,
>> except when service is flapping.
>>  >
>>  > If the backend server is in transitional state, for example
>> transitionally DOWN (going up), the counter is not reset to 0 if
>> tcp-check give a KO state between some OK state. The result is that if
>> the service is flapping, backend become up for a few seconds quite
>> often, even if all OK state are not consecutives.
>>  >
>>  > Example of sequence with rise 3:
>>  >
>>  > KO -> 0/3
>>  > KO -> 0/3
>>  > OK -> 1/3
>>  > KO -> 1/3 <- should back to 0/3
>>  > KO -> 1/3
>>  > KO -> 1/3
>>  > OK -> 2/3
>>  > KO -> 2/3
>>  > KO -> 2/3
>>  > OK -> 3/3 -> Server UP
>>  >
>>  > Is there a way to configure the counter to reset itself in case of
>> flapping ?
>>  >
>>  > Thanks.
>>
>> Hi there,
>>
>> Thanks for reporting this behavior.
>>
>> I'll have a look and come back to you.
>>
>> Baptiste
>
>
> Hello,
>
> Are you able to reproduce on your side ?
>
> Thanks

Re: [PATCH 1/1] MINOR: cli: Dump all resolvers stats if no resolver

2015-10-05 Thread Baptiste 
Andrew,

My appologies about the proxy_find_by_name function, I was not in the
right context!!!
Tested and approved.

Willy, you can apply :)

Thanks a lot for your contribution, Andrew.

Baptiste


On Mon, Oct 5, 2015 at 5:47 PM, Andrew Hayworth
 wrote:
> On Mon, Oct 5, 2015 at 7:24 AM, Baptiste  wrote:
>> Hi,
>>
>> No problem for me about the feature itself.
>> That said, a few things should be changed in the code:
>>
>> - use of proxy_find_by_name() instead of parsing the proxy list
>
> I'm fairly certain that 'proxy_find_by_name' does not search the
> dns_resolvers list (both from reading the code, and from empirically
> testing it). Notably, this looping-through-the-list behavior was
> already present in src/dumpstats.c before I touched it, and we also do
> the same thing when parsing the config files. I _do_ believe we should
> have a nice function for finding a resolvers section by name (either
> 'resolver_find_by_name' or by extending 'proxy_find_by_name'), but I
> don't think this is the commit to do that right before a release.
>
>> - the following statement is hardly readable: "if
>> (appctx->ctx.resolvers.ptr != NULL && appctx->ctx.resolvers.ptr !=
>> presolvers) continue;"
>> Please write "continue" on a new line.
>
> Done.
>
>>
>> Please repost an updated patch and I'll give it a try before final approval.
>>
>> Baptiste
>
> Updated patch below:
>
> From 190fee509a81755a8be3d9281c2edd7d3f72ff19 Mon Sep 17 00:00:00 2001
> From: Andrew Hayworth 
> Date: Fri, 2 Oct 2015 20:33:01 +
> Subject: [PATCH] MINOR: cli: Dump all resolvers stats if no resolver section
>  is given
>
> This commit adds support for dumping all resolver stats. Specifically
> if a command 'show stats resolvers' is issued withOUT a resolver section
> id, we dump all known resolver sections. If none are configured, a
> message is displayed indicating that.
> ---
>  doc/configuration.txt |  6 +++--
>  src/dumpstats.c   | 73 
> +++
>  2 files changed, 43 insertions(+), 36 deletions(-)
>
> diff --git a/doc/configuration.txt b/doc/configuration.txt
> index 3102516..e519662 100644
> --- a/doc/configuration.txt
> +++ b/doc/configuration.txt
> @@ -16043,8 +16043,10 @@ show stat [  ]
>  A similar empty line appears at the end of the second block (stats) so 
> that
>  the reader knows the output has not been truncated.
>
> -show stat resolvers 
> -  Dump statistics for the given resolvers section.
> +show stat resolvers []
> +  Dump statistics for the given resolvers section, or all resolvers sections
> +  if no section is supplied.
> +
>For each name server, the following counters are reported:
>  sent: number of DNS requests sent to this server
>  valid: number of DNS valid responses received from this server
> diff --git a/src/dumpstats.c b/src/dumpstats.c
> index bdfb7e3..ff44120 100644
> --- a/src/dumpstats.c
> +++ b/src/dumpstats.c
> @@ -1166,23 +1166,19 @@ static int stats_sock_parse_request(struct
> stream_interface *si, char *line)
>   if (strcmp(args[2], "resolvers") == 0) {
>   struct dns_resolvers *presolvers;
>
> - if (!*args[3]) {
> - appctx->ctx.cli.msg = "Missing resolver section identifier.\n";
> - appctx->st0 = STAT_CLI_PRINT;
> - return 1;
> - }
> -
> - appctx->ctx.resolvers.ptr = NULL;
> - list_for_each_entry(presolvers, _resolvers, list) {
> - if (strcmp(presolvers->id, args[3]) == 0) {
> - appctx->ctx.resolvers.ptr = presolvers;
> - break;
> + if (*args[3]) {
> + appctx->ctx.resolvers.ptr = NULL;
> + list_for_each_entry(presolvers, _resolvers, list) {
> + if (strcmp(presolvers->id, args[3]) == 0) {
> + appctx->ctx.resolvers.ptr = presolvers;
> + break;
> + }
> + }
> + if (appctx->ctx.resolvers.ptr == NULL) {
> + appctx->ctx.cli.msg = "Can't find that resolvers section\n";
> + appctx->st0 = STAT_CLI_PRINT;
> + return 1;
>   }
> - }
> - if (appctx->ctx.resolvers.ptr == NULL) {
> - appctx->ctx.cli.msg = "Can't find resolvers section.\n";
> - appctx->st0 = STAT_CLI_PRINT;
> - return 1;
>   }
>
>   appctx->st2 = STAT_ST_INIT;
> @@ -6400,24 +6396,33 @@ static int
> stats_dump_resolvers_to_buffer(struct stream_interface *si)
>   /* fall through */
>
>   case STAT_ST_LIST:
> - presolvers = appctx->ctx.resolvers.ptr;
> - chunk_appendf(, "Resolvers section %s\n", presolvers->id);
> - list_for_each_entry(pnameserver, >nameserver_list, list) {
> - chunk_appendf(, " nameserver %s:\n", pnameserver->id);
> - chunk_appendf(, "  sent: %ld\n", pnameserver->counters.sent);
> - chunk_appendf(, "  valid: %ld\n", pnameserver->counters.valid);
> - chunk_appendf(, "  update: %ld\n", pnameserver->counters.update);
> - chunk_appendf(, "  cname: %ld\n", pnameserver->counters.cname);
> - chunk_appendf(, "  cname_error: %ld\n",
> pnameserver->counters.cname_error);
> - chunk_appendf(, "  any_err: %ld\n", pnameserver->counters.any_err);
> - chunk_appendf(, "  nx: %ld\n",

RE: Does Haproxy supports backend on https for reverse proxy

2015-10-05 Thread Yogita 
Thanks for your reply..

Sorry for the typo. Version for Haproxy is 1.5.

I have been trying to achieve this for a while referring to forum examples.
My configuration is like this. Could you please point me to a working example .

defaults
modehttp
log global
option  httplog
option  dontlognull
option http-server-close
option forwardfor   except 127.0.0.0/8
option  redispatch
retries 3
timeout http-request10s
timeout queue   1m
timeout connect 10s
timeout client  1m
timeout server  1m
timeout http-keep-alive 10s
timeout check   10s
maxconn 3000

#-
# main frontend which proxys to the backends
#-


 frontend www
   bind 10.177.222.83:80
   option http-server-close
   default_backend default-backend


backend default-backend
   server adm-testing-platform 10.177.222.82:443 check


Thanks

From: Bryan Talbot [mailto:bryan.tal...@ijji.com]
Sent: Monday, October 05, 2015 1:02 PM
To: Kuchekar, Yogita (Yogita) **CTR**
Cc: haproxy@formilux.org
Subject: Re: Does Haproxy supports backend on https for reverse proxy

On Mon, Oct 5, 2015 at 12:49 PM, Kuchekar, Yogita (Yogita) 
> wrote:
Hi ,

I have installed Haproxy servere 5.1 on linux RHEL 6.1


Assuming you mean haproxy version 1.5, then yes both scenarios are possible. 
I'm sure you can find many blog posts and sample configurations on this mailing 
list to get you started.

-Bryan




I have configured Haproxy servere on linux at 80 port and trying to do reverse 
proxy with backend on https protocol (443). Is it possible in haparoxy ?
Client -->http traffic -->Haproxy server-->https traffic-->backend server


If I have Haproxy kistening to https traffic (have certificate support)and 
backend  server with https traffic, is  this reverse proxy supported in Haproxy 
?
   Client -->https traffic -->Haproxy server-->https 
traffic-->backend server


Is there any other solution for this scenario?
Really appreciate your help here.


Thanks,
Yogita

Outbound SMTP connection with HAProxy

2015-10-05 Thread Charles Meruwoma 
Hi Everyone,

 

Please I need help. I have this setup and I want to be able to route SMTP
traffic from the client access servers to the internet via HAProxy:

 

HAProxy:

Management IP: 10.0.0.133

Virtual IP: 10.0.0.101 [A Public IP address is NAT'ed to this VIP]

 

Microsoft Exchange 2013:

CAS-01: 10.0.0.169 [Client Access Server]

CAS-02: 10.0.0.170 [Client Access Server]

MBX-01: 10.0.0.171 [Mailbox Server]

MBX-02: 10.0.0.172 [Mailbox Server]

 



 

With the above design, how do I setup HAProxy to route external SMTP traffic
from the Client Access Servers to the internet?

 

 

Regards,

Charles Meruwoma

Re: Frontend ACL rewrites URL incorrectly to backend

2015-10-05 Thread Igor Cicimov 
Sorry don't know why the previous message was sent only to you and not to
the forum as well. Maybe because I sent it from my phone. Anyway,
rectifying that now.

>From what you posted about haproxy config, I can't see how can that acl
cause any problems and why would haproxy rewrite the url in the first
place. If that is happening then we all would be seeing the same problem
not just you. I'm also running WP on apache behind haproxy and definitely
don't see this issue. So it has to be something specific to your setup.
Maybe the combination of haproxy and varnish maybe htaccess file.

You can post the full setup of haproxy obfuscating any sensitive details.
Someone might notice something suspicious. Also taking tcpdump for the
traffic entering varnish should confirm that haproxy is mangling the url or
not. If it doens't then you move further down and take a tcp dump of the
traffic entering apache. In that way you will find the culprit for sure.

Cheers,
Igor



On Tue, Oct 6, 2015 at 9:22 AM, Daren Sefcik 
wrote:

> As I wrote in my previous emails it is not just a WP problem but several
> other sites also that behave weird but some others are just fine. They all
> work just fine with varnish and have been for several years, it is only a
> problem when I put haproxy in the front of all of it.
>
> wp-config is just the config file, if anything it may be an issue with
> whats in the .htaccess file but again, it is not just WP. I am happy to
> send you relevant parts of those files if you think you understand the
> problem and want to look at them.
>
> thanks,
> Daren
>
>
> On Mon, Oct 5, 2015 at 2:58 PM, Igor Cicimov <
> ig...@encompasscorporation.com> wrote:
>
>>
>> On 06/10/2015 5:48 AM, "Daren Sefcik"  wrote:
>> >
>> > Hey Joris, I appreciate the help...I am not sure I quite understand
>> though, is there something I can configure in haproxy to resolve this? It
>> is not just a Wordpress problem, I have other sites also that do not behave
>> correctly when I put haproxy in front of them.
>> >
>> > On Mon, Oct 5, 2015 at 8:22 AM, joris dedieu 
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> 2015-10-04 23:33 GMT+02:00 Daren Sefcik :
>> >> > I am trying to make some requests go to specific backends but am
>> finding
>> >> > that in certain backends that the url gets doubled up or otherwise
>> mangled,
>> >> > ie:
>> >> >
>> >> > request to frontend = http://my.company.com
>> >> > what the backend server ends up with =
>> >> > http://my.company.comhttp://my.company.com
>> >> >
>> >> > This does not happen in all of the backends, only a few...a
>> wordpress site
>> >>
>> >> This is typically what append when wordpress is invoked with a wrong
>> >> Host header.
>> >> It must match WP_SITEURL and WP_HOME
>> >>
>> >> Regards
>> >> Joris
>> >>
>> >> > comes to mind as a specific example. Since this does not happen on
>> every
>> >> > single backend server I suspect it is instead something happening on
>> the
>> >> > receiving server but since it only happens when I put haproxy in
>> front of it
>> >> > there is some connection between them.
>> >> >
>> >> > Can someone help me understand what haproxy is doing or how to fix
>> this from
>> >> > happening?
>> >> > Before anyone says it is varnish doing it I should say several of
>> the other
>> >> > backends using varnish work fine, it is only a few that get the url
>> messed
>> >> > up.
>> >> >
>> >> > TIA
>> >> >
>> >> > example ACL:
>> >> >
>> >> > acl   acl_my.company.com hdr(host) -i
>> my.company.com
>> >> > use_backend  VARNISH_BKEND if acl_my.company.com
>> >
>> >
>> Whats in your wp-config.php file? Also seams you have varnish in the mix
>> too you sure it is not varnish doing something weird?
>>
>>
>


-- 
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com 
w*.* encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000

Les plus belles rencontres pour une nuit ou pour la vie

2015-10-05 Thread Marion de MecACroquer 
Title: La rentrée des rencontres








	
		
	
	
		
	
	
		
	
	
		
	
	
		
	
	
		
	
	
		
	


	 
		 
			Site de rencontre généraliste où les femmes ont le pouvoir   	
			Découvrez le site de rencontre MecACroquer ! Un site qui change les codes de la rencontre. Ce sont les femmes qui ont le pouvoir. Osez MecACroquer.Com, un site basé sur le concept du girl power. Les codes de séductions changent, ce sont désormais les femmes qui ont le pouvoir dans le jeu de la séduction.
			Rejoignez les milliers de célibataires sans plus attendre.
			Discutez, échangez et rencontrez de nouvelles personnes, qui sait ? Venez rencontrer des célibataires qui vous correspondent.
			Inscrivez-vous maintenant sur MecACroquer en moins de 1 minute ! 
			
			Grâce à MecACroquer, faites les plus belles rencontres ! Laissez vous surprendre par de belles rencontres. Faites toujours plus de rencontres via notre service en ligne. Utilisez et abusez des nombreuses fonctionnalités proposées afin de rencontrer l'amour pour une nuit ou pour la vie.
			
			Inscrivez-vous et utilisez notre service de rencontre innovant !
			Un problème à l'inscription ? Contactez notre service client : cont...@mecacroquer.com.
			Vous avez reçu ce mail de notre part car vous avez visité notre site internet récemment. 
			Vous n'avez cependant pas été ajouté à une base de donnée marketing. Veuillez ignorer cet email si vous êtes déjà inscrit. 
		 
		 
	 





Pour ne plus recevoir de newsletter de notre part, configurer vos alertes et notifications en vous désinscrivant de la newsletter :  sur cette page.

x-forwarded-for help

2015-10-05 Thread Travis Fitch 

  
  
Hello,

Some quick background; My current setup is haproxy in front of
Apache on the same host. If I send a request to haproxy, I see the
x-forwarded-for entry in Apache's logs and also with tcpdump
  
  tcpdump -i any -nn -A
- -s  'host x.x.x.51 and port 8880' | egrep 'X-F'

X-Forwarded-For: x.x.x.207
X-Forwarded-Port: 443
X-Forwarded-Proto: https
  
  We also have  hardware LB in a non in-line configuration  in-front
  of HAP. Its configured to send x-forwarded onto haproxy.
  
  My issue is, if I bypass the hardware LB, I see the
  X-Forwarded-For header, if I go via the the Hardware LB to haproxy
  and onto Apache, I don't see any x-forwarded-for headers in
  Apaches log files.
  
  If on the other hand I go via the hardware LB directly to Apache
  (by passing haproxy) I see the x-forwarded-for header. Any ideas
  what I am missing in my config file (i'm testing against
  privatetest.dom.net
  
  snippet of my haproxy config file looks like this
  
global
    log 127.0.0.1 local0
    log-send-hostname app04
    maxconn 4096
    user haproxy
    group haproxy
    daemon
    stats socket /tmp/haproxy mode 600 level admin
    tune.ssl.default-dh-param 1024
    ssl-server-verify none

defaults
    log global
    mode http        # Default to L7 proxy service
    option httplog    # HTTP log format
    option dontlognull    # Do not log connections with no
requests
    option contstats    # Enable continuous traffic statistics
updates
    option redispatch    # Try another server in case of
connection failure
    option http-server-close    # Force client side keepalives.
    retries 3
    maxconn 2000
    timeout connect 5s
    timeout client 605s    # GM: uploads take a while to process
in PHP
    timeout server 600s    # GM: (as above)
    timeout http-keep-alive 1s
    timeout http-request 10s    # slowloris protection

frontend http-in
    ## ACL Statements
    acl is_privatetest hdr(host) -i privatetest.dom.net
privatetest2.dom.net

    bind *:80
    use_backend private if is_privatetest
    default_backend dom_net

frontend https-in-private
    capture request header X-Forwarded-For len 50
    # Use General Purpose Couter (gpc) 0 in SC1 as a global
abuse counter
    # Monitors the number of request sent by an IP over a period
of 20 seconds
    stick-table type ip size 1m expire 20s store
gpc0,http_req_rate(500s)
    tcp-request connection track-sc1 src
    # refuses a new connection from an abuser
    tcp-request content reject if { src_get_gpc0 gt 0 }
    # returns a 403 for requests in an established connection
    http-request deny if { src_get_gpc0 gt 0 }
    acl secure dst_port eq 443
    bind 119.82.1.51:443 ssl crt /etc/haproxy/certs/dom_net.pem
name private
    reqadd X-Forwarded-Proto:\ https
    rspadd Strict-Transport-Security:\ max-age=31536000;\
includeSubDomains;\ preload if secure
    rsprep ^Set-Cookie:\ (.*) Set-Cookie:\ \1;\ Secure if secure
    # Do not allow this site to be displayed in iframes
    rspadd X-Frame-Options:\ SAMEORIGIN
    # Do not permit Content-Type sniffing.
    rspadd X-XSS-Protection:\ 1;\ mode=block
    rspadd X-Content-Type-Options:\ nosniff
    use_backend private

# Backend
backend private
    # If the source IP sent 10 or more http request over the
defined period,
    # flag the IP as abuser on the frontend
    acl abuse src_http_req_rate(https-in-private) ge 500
    acl flag_abuser src_inc_gpc0(https-in-private) ge 0
    # Returns a 403 to the abuser
    tcp-request content reject if abuse flag_abuser
    http-request deny if abuse flag_abuser
    #
    balance leastconn
    cookie SERVERID insert nocache indirect
    option httpchk HEAD /
HTTP/1.1\r\nHost:localhost\r\nUser-agent:\ HAP-Check
    option httpclose
    option forwardfor except x.x.x.195
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request set-header X-Forwarded-Proto https if  { ssl_fc
}
    http-request set-header X-Forwarded-Proto http  if !{ ssl_fc
}
    server app04 x.x.x.51:8880 cookie sydapp04 check maxconn 20
    redirect scheme https if !{ ssl_fc }

listen stats 127.0.0.1:1936
   

Re: [PATCH 1/1] MINOR: cli: Dump all resolvers stats if no resolver

2015-10-05 Thread Baptiste 
Hi,

No problem for me about the feature itself.
That said, a few things should be changed in the code:

- use of proxy_find_by_name() instead of parsing the proxy list
- the following statement is hardly readable: "if
(appctx->ctx.resolvers.ptr != NULL && appctx->ctx.resolvers.ptr !=
presolvers) continue;"
Please write "continue" on a new line.

Please repost an updated patch and I'll give it a try before final approval.

Baptiste


On Sun, Oct 4, 2015 at 11:00 AM, Willy Tarreau  wrote:
> At first glance it seems OK. Baptiste, can you please quickly check
> and let me know if you don't see any issue there so that I can merge
> it ?
>
> Willy
>
> On Fri, Oct 02, 2015 at 03:41:06PM -0500, Andrew Hayworth wrote:
>> Hi all -
>>
>> Below is a patch for the 'show stat resolvers' cli command. It changes
>> the command such that it will show all resolvers configured, if you do
>> not specify a resolver id.
>>
>> I found this useful for debugging, and plan on using it in the hatop tool.
>>
>> Let me know if you have any feedback on it!
>>
>> Thanks -
>>
>> Andrew Hayworth
>> --
>>
>> >From c4061d948d21cabb95f093b5d9655c9d226724af Mon Sep 17 00:00:00 2001
>> From: Andrew Hayworth 
>> Date: Fri, 2 Oct 2015 20:33:01 +
>> Subject: [PATCH 1/1] MINOR: cli: Dump all resolvers stats if no resolver
>>  section is given
>>
>> This commit adds support for dumping all resolver stats. Specifically
>> if a command 'show stats resolvers' is issued withOUT a resolver section
>> id, we dump all known resolver sections. If none are configured, a
>> message is displayed indicating that.
>> ---
>>  doc/configuration.txt |  6 +++--
>>  src/dumpstats.c   | 72 
>> +++
>>  2 files changed, 42 insertions(+), 36 deletions(-)
>>
>> diff --git a/doc/configuration.txt b/doc/configuration.txt
>> index 3102516..e519662 100644
>> --- a/doc/configuration.txt
>> +++ b/doc/configuration.txt
>> @@ -16043,8 +16043,10 @@ show stat [  ]
>>  A similar empty line appears at the end of the second block (stats) so 
>> that
>>  the reader knows the output has not been truncated.
>>
>> -show stat resolvers 
>> -  Dump statistics for the given resolvers section.
>> +show stat resolvers []
>> +  Dump statistics for the given resolvers section, or all resolvers sections
>> +  if no section is supplied.
>> +
>>For each name server, the following counters are reported:
>>  sent: number of DNS requests sent to this server
>>  valid: number of DNS valid responses received from this server
>> diff --git a/src/dumpstats.c b/src/dumpstats.c
>> index 1a39258..ea3f49a 100644
>> --- a/src/dumpstats.c
>> +++ b/src/dumpstats.c
>> @@ -1166,23 +1166,19 @@ static int stats_sock_parse_request(struct
>> stream_interface *si, char *line)
>>   if (strcmp(args[2], "resolvers") == 0) {
>> struct dns_resolvers *presolvers;
>>
>> -   if (!*args[3]) {
>> - appctx->ctx.cli.msg = "Missing resolver section identifier.\n";
>> - appctx->st0 = STAT_CLI_PRINT;
>> - return 1;
>> -   }
>> -
>> -   appctx->ctx.resolvers.ptr = NULL;
>> -   list_for_each_entry(presolvers, _resolvers, list) {
>> - if (strcmp(presolvers->id, args[3]) == 0) {
>> -   appctx->ctx.resolvers.ptr = presolvers;
>> -   break;
>> +   if (*args[3]) {
>> + appctx->ctx.resolvers.ptr = NULL;
>> + list_for_each_entry(presolvers, _resolvers, list) {
>> +   if (strcmp(presolvers->id, args[3]) == 0) {
>> + appctx->ctx.resolvers.ptr = presolvers;
>> + break;
>> +   }
>> + }
>> + if (appctx->ctx.resolvers.ptr == NULL) {
>> +   appctx->ctx.cli.msg = "Can't find that resolvers section\n";
>> +   appctx->st0 = STAT_CLI_PRINT;
>> +   return 1;
>>   }
>> -   }
>> -   if (appctx->ctx.resolvers.ptr == NULL) {
>> - appctx->ctx.cli.msg = "Can't find resolvers section.\n";
>> - appctx->st0 = STAT_CLI_PRINT;
>> - return 1;
>> }
>>
>> appctx->st2 = STAT_ST_INIT;
>> @@ -6402,24 +6398,32 @@ static int
>> stats_dump_resolvers_to_buffer(struct stream_interface *si)
>> /* fall through */
>>
>>   case STAT_ST_LIST:
>> -   presolvers = appctx->ctx.resolvers.ptr;
>> -   chunk_appendf(, "Resolvers section %s\n", presolvers->id);
>> -   list_for_each_entry(pnameserver, >nameserver_list, list) {
>> - chunk_appendf(, " nameserver %s:\n", pnameserver->id);
>> - chunk_appendf(, "  sent: %ld\n", pnameserver->counters.sent);
>> - chunk_appendf(, "  valid: %ld\n", pnameserver->counters.valid);
>> - chunk_appendf(, "  update: %ld\n", pnameserver->counters.update);
>> - chunk_appendf(, "  cname: %ld\n", pnameserver->counters.cname);
>> - chunk_appendf(, "  cname_error: %ld\n",
>> pnameserver->counters.cname_error);
>> - chunk_appendf(, "  any_err: %ld\n", 
>>

NOSRV error

2015-10-05 Thread Kevin COUSIN 
Hi list

I want to LB an https backend (Layer 4 LB), but I have a lot of NOSRV errors in 
log : 

Oct  5 15:09:38 localhost haproxy[13839]: 10.250.0.4:43318 
[05/Oct/2015:15:09:38.486] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:09:43 localhost haproxy[13839]: 10.250.0.4:44851 
[05/Oct/2015:15:09:43.642] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:09:48 localhost haproxy[13839]: 10.250.0.4:29479 
[05/Oct/2015:15:09:48.761] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:09:53 localhost haproxy[13839]: 10.250.0.4:53748 
[05/Oct/2015:15:09:53.790] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:09:58 localhost haproxy[13839]: 10.250.0.4:44828 
[05/Oct/2015:15:09:58.847] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:10:03 localhost haproxy[13839]: 10.250.0.4:51021 
[05/Oct/2015:15:10:03.937] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:10:08 localhost haproxy[13839]: 10.250.0.4:21815 
[05/Oct/2015:15:10:08.925] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:10:13 localhost haproxy[13839]: 10.250.0.4:57069 
[05/Oct/2015:15:10:13.902] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:10:18 localhost haproxy[13839]: 10.250.0.4:42239 
[05/Oct/2015:15:10:18.873] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:10:23 localhost haproxy[13839]: 10.250.0.4:65477 
[05/Oct/2015:15:10:23.893] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0
Oct  5 15:10:28 localhost haproxy[13839]: 10.250.0.4:51091 
[05/Oct/2015:15:10:28.860] fe_pp-portail-https be_pp-xctl-https/ -1/-1/0 
0 -- 0/0/0/0/3 0/0

Here is my configuration (works well with http)

global
   log 127.0.0.1 local4
   maxconn 65535
   user haproxy
   group haproxy
   daemon
   stats socket /var/lib/haproxy/stats user haproxy group haproxy
   ssl-server-verify none
   ssl-default-bind-ciphers 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
   tune.ssl.default-dh-param 2048

defaults
log global
mode tcp
option tcplog
option contstats   # Enable continuous traffic Statistics 
updates
option redispatch
timeout client 2h  #alctl: client inactivity timeout
maxconn 15000
timeout client-fin 1m   # When connection are close on one side 
only
timeout server  60s
timeout connect 60s
timeout tunnel 2h   # Set the maximum inactivity time on the client 
and server side for tunnels.
default-server inter 2s  fall 3 rise 2 on-marked-down shutdown-sessions


frontend fe_pp-portail-http
bind 10.250.0.48:80
default_backend be_pp-xctl-http

frontend fe_pp-portail-https
bind 10.250.0.48:443
default_backend be_pp-xctl-https

backend be_pp-xctl-http
balance source
server pp-xctl01002-http 172.21.12.8:80 

backend be_pp-xctl-https
balance source
server pp-xctl01002-https 172.21.12.8:443

I got the certificate on my server If I use openssl s_client.

Regards,



   Kevin

Re: x-forwarded-for help

2015-10-05 Thread Aleksandar Lazic 

Hi.

Am 05-10-2015 14:29, schrieb Travis Fitch:

Hello,

Some quick background; My current setup is haproxy in front of Apache 
on
the same host. If I send a request to haproxy, I see the 
x-forwarded-for

entry in Apache's logs and also with tcpdump

tcpdump -i any -nn -A - -s  'host x.x.x.51 and port 8880' |
egrep 'X-F'

X-Forwarded-For: x.x.x.207
X-Forwarded-Port: 443
X-Forwarded-Proto: https

We also have  hardware LB in a non in-line configuration  in-front of
HAP. Its configured to send x-forwarded onto haproxy.

My issue is, if I bypass the hardware LB, I see the X-Forwarded-For
header, if I go via the the Hardware LB to haproxy and onto Apache, I
don't see any x-forwarded-for headers in Apaches log files.

If on the other hand I go via the hardware LB directly to Apache (by
passing haproxy) I see the x-forwarded-for header. Any ideas what I am
missing in my config file (i'm testing against privatetest.dom.net

snippet of my haproxy config file looks like this

global
log 127.0.0.1 local0
log-send-hostname app04
maxconn 4096
user haproxy
group haproxy
daemon
stats socket /tmp/haproxy mode 600 level admin
tune.ssl.default-dh-param 1024
ssl-server-verify none

defaults
log global
mode http# Default to L7 proxy service
option httplog# HTTP log format
option dontlognull# Do not log connections with no requests
option contstats# Enable continuous traffic statistics updates
option redispatch# Try another server in case of connection
failure
option http-server-close# Force client side keepalives.
retries 3
maxconn 2000
timeout connect 5s
timeout client 605s# GM: uploads take a while to process in PHP
timeout server 600s# GM: (as above)
timeout http-keep-alive 1s
timeout http-request 10s# slowloris protection


How about to add "option forwardfor .." in the defaults config or at the 
frontend?


http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#4.2-option%20forwardfor


Since this
header is always appended at the end of the existing header list, the 
server
must be configured to always use the last occurrence of this header 
only.



BTW: Please can you also add the output of haproxy -vv thanks.

BR Aleks

Re: Frontend ACL rewrites URL incorrectly to backend

2015-10-05 Thread joris dedieu 
Hi,

2015-10-04 23:33 GMT+02:00 Daren Sefcik :
> I am trying to make some requests go to specific backends but am finding
> that in certain backends that the url gets doubled up or otherwise mangled,
> ie:
>
> request to frontend = http://my.company.com
> what the backend server ends up with =
> http://my.company.comhttp://my.company.com
>
> This does not happen in all of the backends, only a few...a wordpress site

This is typically what append when wordpress is invoked with a wrong
Host header.
It must match WP_SITEURL and WP_HOME

Regards
Joris

> comes to mind as a specific example. Since this does not happen on every
> single backend server I suspect it is instead something happening on the
> receiving server but since it only happens when I put haproxy in front of it
> there is some connection between them.
>
> Can someone help me understand what haproxy is doing or how to fix this from
> happening?
> Before anyone says it is varnish doing it I should say several of the other
> backends using varnish work fine, it is only a few that get the url messed
> up.
>
> TIA
>
> example ACL:
>
> acl   acl_my.company.com hdr(host) -i my.company.com
> use_backend  VARNISH_BKEND if acl_my.company.com

Re: x-forwarded-for help

2015-10-05 Thread Daren Sefcik 
On Mon, Oct 5, 2015 at 5:29 AM, Travis Fitch  wrote:

> My issue is, if I bypass the hardware LB, I see the X-Forwarded-For
> header, if I go via the the Hardware LB to haproxy and onto Apache, I don't
> see any x-forwarded-for headers in Apaches log files.


I am new to haproxy but it sounds like maybe haproxy does not know how to
extract the x-forwarded-for header and pass it on, it is only looking at
the x-client header and adding it to the XFF header.

Re: core dump, lua service, 1.6-dev6 ss-20150930

2015-10-05 Thread Thierry FOURNIER 
Hi,

I process this email later. For waiting, I propose to you to set the
"option http-server-close". Actually, the "services" doesn't support
itself the keepalive, but HAProxy does this job.

The "option http-server-close" expectes a server-close from the service
stream. The front of HAProxy maintains the keep-alive between the
client and the haproxy.

This method embbed a limitation: if some servers are declared in the
backend, the "option http-server-close" forbid the keepalive between
haproxy and the serveur.

Can you test with this option ?

Thierry



On Thu, 1 Oct 2015 23:00:45 +0200
Cyril Bonté  wrote:

> Hi,
> 
> Le 01/10/2015 20:52, PiBa-NL a écrit :
> > Hi List,
> >
> > With the config below while running 'siege' i get a core dump within a
> > few hundreds of requests.. Viewing the stats page from a chrome browser
> > while siege is running seems to crash it sooner..
> >
> > Is below enough to find the cause? Anything else i should try?
> 
> This is embarrassing because with your configuration, I currently can't 
> reproduce a segfault but I can reproduce another issue with HTTP 
> keep-alive requests !
> 
> (details below)
> 
> > Using the haproxy snapshot from: 1.6-dev6 ss-20150930
> > Or perhaps i just did compile it wrong?..
> > make NO_CHECKSUM=yes clean debug=1 reinstall WITH_DEBUG=yes
> >
> > global
> >  stats socket /tmp/hap.socket level admin
> >  maxconn 6
> >  lua-load /haproxy/brute/hello.lua
> >
> > defaults
> >  timeout client 1
> >  timeout connect 1
> >  timeout server 1
> >
> > frontend HAProxyLocalStats
> >  bind :2300 name localstats
> >  mode http
> >  stats enable
> >  stats refresh 1000
> >  stats admin if TRUE
> >  stats uri /
> > frontend http_frt
> >bind :801
> >mode http
> >http-request use-service lua.hello-world
> 
> Here, if I use :
> $ ab -n100 -c1 -k http://127.0.0.1:801/
> There will be a 1ms delay after the first request.
> 
> Or with another test case :
> echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET / 
> HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
> HTTP/1.1 200 OK
> content-type: text/plain
> Transfer-encoding: chunked
> 
> d
> Hello World !
> 0
> 
> => only 1 response
> 
> Now, if I change "frontend http_frt" to "listen http_frt", I get the 
> awaited behaviour.
> 
> The second test case with "listen" :
> echo -ne "GET / HTTP/1.1\r\nHost: localhost\r\n\r\nGET / 
> HTTP/1.1\r\nHost: localhost\r\n\r\n"| nc localhost 801
> HTTP/1.1 200 OK
> content-type: text/plain
> Transfer-encoding: chunked
> 
> d
> Hello World !
> 0
> 
> HTTP/1.1 200 OK
> content-type: text/plain
> Transfer-encoding: chunked
> 
> d
> Hello World !
> 0
> 
> => the 2 responses are returned
> 
> >
> > core.register_service("hello-world", "http", function(applet)
> > local response = "Hello World !"
> > applet:set_status(200)
> > applet:add_header("content-type", "text/plain")
> > applet:start_response()
> > applet:send(response)
> > end )
> >
> > (gdb) bt full
> > #0  0x000801a2da75 in memcpy () from /lib/libc.so.7
> > No symbol table info available.
> > #1  0x00417388 in buffer_slow_realign (buf=0x7d3c90) at
> > src/buffer.c:166
> >  block1 = -3306
> >  block2 = 0
> > #2  0x00480c42 in http_wait_for_request (s=0x80247d600,
> > req=0x80247d610, an_bit=4)
> >  at src/proto_http.c:2686
> >  cur_idx = -6336
> >  sess = (struct session *) 0x80241e400
> >  txn = (struct http_txn *) 0x802bb2140
> >  msg = (struct http_msg *) 0x802bb21a0
> >  ctx = {line = 0x2711079 , idx
> > = 3, val = 0, vlen = 7, tws = 0,
> >del = 33, prev = 0}
> > #3  0x004d55b1 in process_stream (t=0x80244b390) at
> > src/stream.c:1759
> >  max_loops = 199
> >  ana_list = 52
> >  ana_back = 52
> >  flags = 4227584
> >  srv = (struct server *) 0x0
> >  s = (struct stream *) 0x80247d600
> >  sess = (struct session *) 0x80241e400
> >  rqf_last = 8397312
> >  rpf_last = 2248179715
> >  rq_prod_last = 7
> >  rq_cons_last = 9
> >  rp_cons_last = 7
> >  rp_prod_last = 0
> >  req_ana_back = 8192
> >  req = (struct channel *) 0x80247d610
> >  res = (struct channel *) 0x80247d650
> >  si_f = (struct stream_interface *) 0x80247d7f8
> >  si_b = (struct stream_interface *) 0x80247d818
> > #4  0x0041fe78 in process_runnable_tasks () at src/task.c:238
> >  t = (struct task *) 0x80244b390
> >  max_processed = 0
> > #5  0x0040cc4e in run_poll_loop () at src/haproxy.c:1539
> >  next = 549107027
> > #6  0x0040daee in main (argc=4, argv=0x7fffeaf0) at
> > src/haproxy.c:1892
> >  err = 0
> >  retry = 200
> >  limit = {rlim_cur = 120032, rlim_max = 120032}
> >  errmsg =
> >

Re: NOSRV error

2015-10-05 Thread Conrad Hoffmann 
Hi,

(comments inline)

On 10/05/2015 03:23 PM, Kevin COUSIN wrote:
> Hi list
> 
> I want to LB an https backend (Layer 4 LB), but I have a lot of NOSRV errors 
> in log : 
> 
> Oct  5 15:09:38 localhost haproxy[13839]: 10.250.0.4:43318 
> [05/Oct/2015:15:09:38.486] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:09:43 localhost haproxy[13839]: 10.250.0.4:44851 
> [05/Oct/2015:15:09:43.642] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:09:48 localhost haproxy[13839]: 10.250.0.4:29479 
> [05/Oct/2015:15:09:48.761] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:09:53 localhost haproxy[13839]: 10.250.0.4:53748 
> [05/Oct/2015:15:09:53.790] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:09:58 localhost haproxy[13839]: 10.250.0.4:44828 
> [05/Oct/2015:15:09:58.847] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:10:03 localhost haproxy[13839]: 10.250.0.4:51021 
> [05/Oct/2015:15:10:03.937] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:10:08 localhost haproxy[13839]: 10.250.0.4:21815 
> [05/Oct/2015:15:10:08.925] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:10:13 localhost haproxy[13839]: 10.250.0.4:57069 
> [05/Oct/2015:15:10:13.902] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:10:18 localhost haproxy[13839]: 10.250.0.4:42239 
> [05/Oct/2015:15:10:18.873] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:10:23 localhost haproxy[13839]: 10.250.0.4:65477 
> [05/Oct/2015:15:10:23.893] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0
> Oct  5 15:10:28 localhost haproxy[13839]: 10.250.0.4:51091 
> [05/Oct/2015:15:10:28.860] fe_pp-portail-https be_pp-xctl-https/ 
> -1/-1/0 0 -- 0/0/0/0/3 0/0

This usually means that there is no server in the backend because they were
either misconfigured or taken out of the rotation, e.g. due to failed
health checks.

> Here is my configuration (works well with http)
> 
> global
>log 127.0.0.1 local4
>maxconn 65535
>user haproxy
>group haproxy
>daemon
>stats socket /var/lib/haproxy/stats user haproxy group haproxy
>ssl-server-verify none
>ssl-default-bind-ciphers 
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128:AES256:AES:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK
>tune.ssl.default-dh-param 2048

Not sure what exactly you want to achieve here. If you want to loadbalance
on TCP level, HAProxy doesn't need to know anything about any TLS parameters.

> defaults
> log global
> mode tcp
> option tcplog
> option contstats   # Enable continuous traffic Statistics 
> updates
> option redispatch
> timeout client 2h  #alctl: client inactivity timeout
> maxconn 15000
> timeout client-fin 1m   # When connection are close on one 
> side only
> timeout server  60s
> timeout connect 60s
> timeout tunnel 2h   # Set the maximum inactivity time on the 
> client and server side for tunnels.
> default-server inter 2s  fall 3 rise 2 on-marked-down 
> shutdown-sessions
> 
> 
> frontend fe_pp-portail-http
> bind 10.250.0.48:80
> default_backend be_pp-xctl-http
> 
> frontend fe_pp-portail-https
> bind 10.250.0.48:443
> default_backend be_pp-xctl-https
> 
> backend be_pp-xctl-http
> balance source
> server pp-xctl01002-http 172.21.12.8:80 
> 
> backend be_pp-xctl-https
> balance source
> server pp-xctl01002-https 172.21.12.8:443
> 
> I got the certificate on my server If I use openssl s_client.

Can you elaborate on this? Are you connecting with s_client to haproxy or
to your server?
Can you confirm that you want you web server to do the actual TLS handshake
and not HAProxy?

Conrad
-- 
Conrad Hoffmann
Traffic Engineer

SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany

Managing Director: Alexander Ljung | Incorporated in England & Wales
with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
HRB 110657B

OPTIM : IPv6 literal address parsing

2015-10-05 Thread Mildis 

Hi list,

It looks like IPv6 parsing may lead to errors.
The logic cannot distinguish from ‘2001:db8::1234:80’ as :
- a plain IPv6 address 2001:db8::1234:80
- IPv6 2001:db8::1234 on port 80

It always default to the latter, considering any valid word made only of 
digits as a port.

(see https://gist.github.com/mildis/4ab2c3ff3a9ad56c9970)

The proposed patch allows IPv6 literal addresses to be enclose in square 
brackets as per https://www.ietf.org/rfc/rfc2732.txt


MildisFrom 5ab1cdaffbd48d5776dc94365c7581c6b0b84124 Mon Sep 17 00:00:00 2001
From: mildis 
Date: Mon, 5 Oct 2015 09:52:43 +0200
Subject: [PATCH] OPTIM/MINOR: decode IPv6 literal addresses

---
 src/standard.c | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/src/standard.c b/src/standard.c
index b5f4bf4..00af8dc 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -637,11 +637,31 @@ struct sockaddr_storage *str2ip2(const char *str, struct sockaddr_storage *sa, i
 		return sa;
 	}
 
+	/* check IPv6 literal */
+	if (str[0] == '[') {
+		if (strrchr(str, ']') != NULL)
+			sa->ss_family = AF_INET6;
+		else
+			goto fail;
+	}
+
 	/* check for IPv6 first */
-	if ((!sa->ss_family || sa->ss_family == AF_UNSPEC || sa->ss_family == AF_INET6) &&
-	inet_pton(AF_INET6, str, &((struct sockaddr_in6 *)sa)->sin6_addr)) {
-		sa->ss_family = AF_INET6;
-		return sa;
+	if (!sa->ss_family || sa->ss_family == AF_UNSPEC || sa->ss_family == AF_INET6) {
+		/* IPv6 literal with opening and closing bracket ? */
+		if (str[0] == '[' && strchr(str, ']') != NULL) {
+			/* strip the closing bracket */
+			*(strchr(str, ']')) = '\0';
+			/* if inet_pton is OK, it is a valid IPv6 address */
+			if (inet_pton(AF_INET6, str+1, &((struct sockaddr_in6 *)sa)->sin6_addr)) {
+sa->ss_family = AF_INET6;
+return sa;
+			}
+		}
+		/* IPv6 without brackets */
+		else if (inet_pton(AF_INET6, str, &((struct sockaddr_in6 *)sa)->sin6_addr)) {
+			sa->ss_family = AF_INET6;
+			return sa;
+		}
 	}
 
 	/* then check for IPv4 */
-- 
1.8.4

Re: NOSRV error

2015-10-05 Thread Baptiste 
On Mon, Oct 5, 2015 at 5:24 PM, Kevin COUSIN  wrote:
> Hi,
>
> - Mail original -
>> De: "Conrad Hoffmann" 
>> À: "Kevin COUSIN" , haproxy@formilux.org
>> Envoyé: Lundi 5 Octobre 2015 15:49:36
>> Objet: Re: NOSRV error
>
>> Hi,
>>
>> (comments inline)
>>
>> On 10/05/2015 03:23 PM, Kevin COUSIN wrote:
>>> Hi list
>>>
>>
>> This usually means that there is no server in the backend because they were
>> either misconfigured or taken out of the rotation, e.g. due to failed
>> health checks.
>>
>
> We disabled server tests to debug.

Kevin, bear in mind that checks are never the problem, but they are
the solution ;)


>>
>> Not sure what exactly you want to achieve here. If you want to loadbalance
>> on TCP level, HAProxy doesn't need to know anything about any TLS parameters.
>
>
> It's a lab HAproxy instance, the ssl ciphers options are for some other Layer 
> 7 LB configuration.
> 43
>>>
>>> I got the certificate on my server If I use openssl s_client.
>>
>> Can you elaborate on this? Are you connecting with s_client to haproxy or
>> to your server?
>> Can you confirm that you want you web server to do the actual TLS handshake
>> and not HAProxy?
>
> I'm connecting to my server with openssl, from the haproxy (to check if SSL 
> certificate is installed on the target).
>
> Yes, we want the backend server to do the TLS handshake.
>
> We try to LB the Citrix Broker :
>
> User -> Citrix Netscaler Gateway -> HAproxy --> Citrix Brokers
>
> We used the Windows NLB between Citrix NS Gateway and Citrix Brokers and we 
> want to replace it with HAproxy.
> With the HTTP frontend, we can see "HTTP/XML 479 POST /Scripts/CtxSTA.dll 
> HTTP/1.1". It doesn't work with HTTPS, the Netscaler gateway seems to close 
> the connection with FIN,ACK.


Why mixing HAProxy between citrix products?

As Conrad said, there are servers available for your connection. you
should investigate first why the citrix brokers reject the traffic.

Baptiste

Re: NOSRV error

2015-10-05 Thread Kevin COUSIN 
Hi, 

- Mail original -
> De: "Conrad Hoffmann" 
> À: "Kevin COUSIN" , haproxy@formilux.org
> Envoyé: Lundi 5 Octobre 2015 15:49:36
> Objet: Re: NOSRV error

> Hi,
> 
> (comments inline)
> 
> On 10/05/2015 03:23 PM, Kevin COUSIN wrote:
>> Hi list
>> 
> 
> This usually means that there is no server in the backend because they were
> either misconfigured or taken out of the rotation, e.g. due to failed
> health checks.
> 

We disabled server tests to debug.

> 
> Not sure what exactly you want to achieve here. If you want to loadbalance
> on TCP level, HAProxy doesn't need to know anything about any TLS parameters.


It's a lab HAproxy instance, the ssl ciphers options are for some other Layer 7 
LB configuration.
43
>> 
>> I got the certificate on my server If I use openssl s_client.
> 
> Can you elaborate on this? Are you connecting with s_client to haproxy or
> to your server?
> Can you confirm that you want you web server to do the actual TLS handshake
> and not HAProxy?

I'm connecting to my server with openssl, from the haproxy (to check if SSL 
certificate is installed on the target).

Yes, we want the backend server to do the TLS handshake. 

We try to LB the Citrix Broker : 

User -> Citrix Netscaler Gateway -> HAproxy --> Citrix Brokers

We used the Windows NLB between Citrix NS Gateway and Citrix Brokers and we 
want to replace it with HAproxy. 
With the HTTP frontend, we can see "HTTP/XML 479 POST /Scripts/CtxSTA.dll 
HTTP/1.1". It doesn't work with HTTPS, the Netscaler gateway seems to close the 
connection with FIN,ACK. 

> 
> Conrad
> --
> Conrad Hoffmann
> Traffic Engineer
> 
> SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany
> 
> Managing Director: Alexander Ljung | Incorporated in England & Wales
> with Company No. 6343600 | Local Branch Office | AG Charlottenburg |
> HRB 110657B




   Kevin

Re: OPTIM : IPv6 literal address parsing

2015-10-05 Thread David du Colombier 
> It looks like IPv6 parsing may lead to errors.
> The logic cannot distinguish from ‘2001:db8::1234:80’ as :
> - a plain IPv6 address 2001:db8::1234:80
> - IPv6 2001:db8::1234 on port 80

As far I remember, to prevent this confusion, we made the final
colon mandatory on IPv6 addresses. This way, anything before
the final colon is the address.

If you don't want to specify the port explicitly, the address
ends with a colon.

-- 
David du Colombier

Re: [PATCH 1/1] MINOR: cli: Dump all resolvers stats if no resolver

2015-10-05 Thread Andrew Hayworth 
On Mon, Oct 5, 2015 at 7:24 AM, Baptiste  wrote:
> Hi,
>
> No problem for me about the feature itself.
> That said, a few things should be changed in the code:
>
> - use of proxy_find_by_name() instead of parsing the proxy list

I'm fairly certain that 'proxy_find_by_name' does not search the
dns_resolvers list (both from reading the code, and from empirically
testing it). Notably, this looping-through-the-list behavior was
already present in src/dumpstats.c before I touched it, and we also do
the same thing when parsing the config files. I _do_ believe we should
have a nice function for finding a resolvers section by name (either
'resolver_find_by_name' or by extending 'proxy_find_by_name'), but I
don't think this is the commit to do that right before a release.

> - the following statement is hardly readable: "if
> (appctx->ctx.resolvers.ptr != NULL && appctx->ctx.resolvers.ptr !=
> presolvers) continue;"
> Please write "continue" on a new line.

Done.

>
> Please repost an updated patch and I'll give it a try before final approval.
>
> Baptiste

Updated patch below:

>From 190fee509a81755a8be3d9281c2edd7d3f72ff19 Mon Sep 17 00:00:00 2001
From: Andrew Hayworth 
Date: Fri, 2 Oct 2015 20:33:01 +
Subject: [PATCH] MINOR: cli: Dump all resolvers stats if no resolver section
 is given

This commit adds support for dumping all resolver stats. Specifically
if a command 'show stats resolvers' is issued withOUT a resolver section
id, we dump all known resolver sections. If none are configured, a
message is displayed indicating that.
---
 doc/configuration.txt |  6 +++--
 src/dumpstats.c   | 73 +++
 2 files changed, 43 insertions(+), 36 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 3102516..e519662 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -16043,8 +16043,10 @@ show stat [  ]
 A similar empty line appears at the end of the second block (stats) so that
 the reader knows the output has not been truncated.

-show stat resolvers 
-  Dump statistics for the given resolvers section.
+show stat resolvers []
+  Dump statistics for the given resolvers section, or all resolvers sections
+  if no section is supplied.
+
   For each name server, the following counters are reported:
 sent: number of DNS requests sent to this server
 valid: number of DNS valid responses received from this server
diff --git a/src/dumpstats.c b/src/dumpstats.c
index bdfb7e3..ff44120 100644
--- a/src/dumpstats.c
+++ b/src/dumpstats.c
@@ -1166,23 +1166,19 @@ static int stats_sock_parse_request(struct
stream_interface *si, char *line)
  if (strcmp(args[2], "resolvers") == 0) {
  struct dns_resolvers *presolvers;

- if (!*args[3]) {
- appctx->ctx.cli.msg = "Missing resolver section identifier.\n";
- appctx->st0 = STAT_CLI_PRINT;
- return 1;
- }
-
- appctx->ctx.resolvers.ptr = NULL;
- list_for_each_entry(presolvers, _resolvers, list) {
- if (strcmp(presolvers->id, args[3]) == 0) {
- appctx->ctx.resolvers.ptr = presolvers;
- break;
+ if (*args[3]) {
+ appctx->ctx.resolvers.ptr = NULL;
+ list_for_each_entry(presolvers, _resolvers, list) {
+ if (strcmp(presolvers->id, args[3]) == 0) {
+ appctx->ctx.resolvers.ptr = presolvers;
+ break;
+ }
+ }
+ if (appctx->ctx.resolvers.ptr == NULL) {
+ appctx->ctx.cli.msg = "Can't find that resolvers section\n";
+ appctx->st0 = STAT_CLI_PRINT;
+ return 1;
  }
- }
- if (appctx->ctx.resolvers.ptr == NULL) {
- appctx->ctx.cli.msg = "Can't find resolvers section.\n";
- appctx->st0 = STAT_CLI_PRINT;
- return 1;
  }

  appctx->st2 = STAT_ST_INIT;
@@ -6400,24 +6396,33 @@ static int
stats_dump_resolvers_to_buffer(struct stream_interface *si)
  /* fall through */

  case STAT_ST_LIST:
- presolvers = appctx->ctx.resolvers.ptr;
- chunk_appendf(, "Resolvers section %s\n", presolvers->id);
- list_for_each_entry(pnameserver, >nameserver_list, list) {
- chunk_appendf(, " nameserver %s:\n", pnameserver->id);
- chunk_appendf(, "  sent: %ld\n", pnameserver->counters.sent);
- chunk_appendf(, "  valid: %ld\n", pnameserver->counters.valid);
- chunk_appendf(, "  update: %ld\n", pnameserver->counters.update);
- chunk_appendf(, "  cname: %ld\n", pnameserver->counters.cname);
- chunk_appendf(, "  cname_error: %ld\n",
pnameserver->counters.cname_error);
- chunk_appendf(, "  any_err: %ld\n", pnameserver->counters.any_err);
- chunk_appendf(, "  nx: %ld\n", pnameserver->counters.nx);
- chunk_appendf(, "  timeout: %ld\n", pnameserver->counters.timeout);
- chunk_appendf(, "  refused: %ld\n", pnameserver->counters.refused);
- chunk_appendf(, "  other: %ld\n", pnameserver->counters.other);
- chunk_appendf(, "  invalid: %ld\n", pnameserver->counters.invalid);
- chunk_appendf(, "  too_big: %ld\n", pnameserver->counters.too_big);
- chunk_appendf(, "  truncated: %ld\n", pnameserver->counters.truncated);
- chunk_appendf(, "  outdated: %ld\n", pnameserver->counters.outdated);
+ if