Re: external-check stdout ends up in load-balanced traffic, destroying tcp sessions

2016-06-06 Thread Simon Horman
Hi Cyril, Hi Lukas,

On Mon, Jun 06, 2016 at 08:21:46PM +0200, Cyril Bonté wrote:
> Hi Lukas,
> 
> I add Malcolm and Simon to the thread.
> 
> Le 06/06/2016 à 08:36, Lukas Erlacher a écrit :
> >Additional info: The output only ends up in the *first* client connection.
> >
> >Talking about this with some colleagues we're now theorizing that stdout 
> >goes to fd 1 and fd 1 is also the first client connection socket. Might be 
> >helpful for tracking this down.
> 
> After doing a quick test, I can confirm I can reproduce the issue (once
> working in daemon mode).
> 
> Simon, do you have time to work on a fix ? or should someone else do ? (I
> think I'll be available to work on this, but only by the end of the week)
> 
> Also Malcolm, as I remember you are using this feature, be aware that you
> may hit the issue too.

looking over the code a little the theory regarding fd 1 seems entirely
plausible as stdout, along with stdin and stdin, may be be closed 
in haproxy.c:main()

It seems to me that if the case where they were closed, and thus fd 1 and 2
may be used for other purposes, it would be prudent to redirect fd 1 and 2
to "/dev/null".

One problem I see with this is that if haproxy is running in a chroot
and /dev/null is not present then open() will fail.

Lukas, would it be possible for you to test the following
(I have only compile tested it) ?


diff --git a/src/checks.c b/src/checks.c
index c4ac947b6051..eca7df62522f 100644
--- a/src/checks.c
+++ b/src/checks.c
@@ -1836,6 +1836,16 @@ static int connect_proc_chk(struct task *t)
if (pid == 0) {
/* Child */
extern char **environ;
+
+   if ((global.mode & MODE_QUIET) && !(global.mode & 
MODE_VERBOSE)) {
+   close(0);
+   close(1);
+
+   if (open("/dev/null", 0, O_WRONLY) || open("/dev/null", 
0, O_WRONLY)) {
+   exit (-1);
+   }
+   }
+
environ = check->envp;
extchk_setenv(check, EXTCHK_HAPROXY_SERVER_CURCONN, 
ultoa_r(s->cur_sess, buf, sizeof(buf)));
execvp(px->check_command, check->argv);




Re: clang static analysis of haproxy

2016-06-06 Thread Илья Шипицин
like that ?


--- src/proxy.c.orig2016-06-07 00:56:29.001214621 +0500
+++ src/proxy.c2016-06-07 00:59:01.823568543 +0500
@@ -426,11 +426,14 @@
 hdr->index = curpx->nb_req_cap++;
 curpx->req_cap = hdr;
 }
-if (strcmp(args[2], "response") == 0) {
+else if (strcmp(args[2], "response") == 0) {
 hdr->next = curpx->rsp_cap;
 hdr->index = curpx->nb_rsp_cap++;
 curpx->rsp_cap = hdr;
 }
+else {
+free(hdr);
+}
 return 0;
 }
 else {


2016-06-07 0:34 GMT+05:00 Sasha Pachev :

> I took a quick look. The first one I looked at was a minor issue, but
> still legitimate.
>
> http://chipitsine.github.io/haproxy-1.7-dev/report-0bb120.html#EndPath
>
> line 419
>
> hdr should be freed if args[2] is neither "request" nor "response",
> otherwise the allocated address is permanently forgotten.
>
>
> On Mon, Jun 6, 2016 at 12:52 PM, Maciej Katafiasz
>  wrote:
> > On 6 June 2016 at 09:41, Илья Шипицин  wrote:
> >> also, is there some bug tracker ? CI (like travis-ci or jenkins) ?
> >
> > No, this list is the place to report things.
> >
> > Cheers,
> > Maciej
> >
>
>
>
> --
> Sasha Pachev
>
> Fast Running Blog.
> http://fastrunningblog.com
> Run. Blog. Improve. Repeat.
>


Re: clang static analysis of haproxy

2016-06-06 Thread Sasha Pachev
I took a quick look. The first one I looked at was a minor issue, but
still legitimate.

http://chipitsine.github.io/haproxy-1.7-dev/report-0bb120.html#EndPath

line 419

hdr should be freed if args[2] is neither "request" nor "response",
otherwise the allocated address is permanently forgotten.


On Mon, Jun 6, 2016 at 12:52 PM, Maciej Katafiasz
 wrote:
> On 6 June 2016 at 09:41, Илья Шипицин  wrote:
>> also, is there some bug tracker ? CI (like travis-ci or jenkins) ?
>
> No, this list is the place to report things.
>
> Cheers,
> Maciej
>



-- 
Sasha Pachev

Fast Running Blog.
http://fastrunningblog.com
Run. Blog. Improve. Repeat.



Re: clang static analysis of haproxy

2016-06-06 Thread Maciej Katafiasz
On 6 June 2016 at 09:41, Илья Шипицин  wrote:
> also, is there some bug tracker ? CI (like travis-ci or jenkins) ?

No, this list is the place to report things.

Cheers,
Maciej



Re: external-check stdout ends up in load-balanced traffic, destroying tcp sessions

2016-06-06 Thread Cyril Bonté

Hi Lukas,

I add Malcolm and Simon to the thread.

Le 06/06/2016 à 08:36, Lukas Erlacher a écrit :

Additional info: The output only ends up in the *first* client connection.

Talking about this with some colleagues we're now theorizing that stdout goes 
to fd 1 and fd 1 is also the first client connection socket. Might be helpful 
for tracking this down.


After doing a quick test, I can confirm I can reproduce the issue (once 
working in daemon mode).


Simon, do you have time to work on a fix ? or should someone else do ? 
(I think I'll be available to work on this, but only by the end of the week)


Also Malcolm, as I remember you are using this feature, be aware that 
you may hit the issue too.



--
Cyril Bonté



Haproxy with mixed modes: SSL offloading and passthrough

2016-06-06 Thread DjamOlsky
Hi,
I would like to implement the following simple scenario, all the tests I
have done unfortunately have failed (bad SSL requests, error 502...):
- Using SSL passthrough for the top level domain (mydomain.com) as the web
application is already presenting a wildcard SSL certificate for this domain.
- Offloading SSL on haproxy just for the subdomains (a SSL certificate
matching with *.sub01.mydomain.com for example).

Here is a simple configuration example showing the case:

frontend FE-https
bind 1.1.1.1:443 ssl crt /etc/ssl/certs/sub01.mydomain.com.pem
modehttp
acl is_sub01 hdr_end(host) -i sub01.mydomain.com
use_backend BE-sub01 if is_sub01
default_backend BE-default

# SSL Offloading for *.sub01.mydomain.com
backend BE-sub01
modehttp
server  srv1 10.10.10.10:443 

# SSL passthrough for *.mydomain.com
backend BE-default
modehttp
server  srv1 10.10.10.10:443 ssl verify none

To summarize, I would like to provide or not the right SSL certificate per
backend (depending on the url).
Thanks for your help :)





clang static analysis of haproxy

2016-06-06 Thread Илья Шипицин
Hello,

I run scan-build (which is clang static analysis tool) on haproxy git source

here's result

http://chipitsine.github.io/haproxy-1.7-dev/


there some null pointer dereferences and memory leaks, I think worth
looking at them.

also, is there some bug tracker ? CI (like travis-ci or jenkins) ?

Cheers,
Ilya Shipitsin


Re: segfault using wrong table

2016-06-06 Thread Kay
Hi,

2016-06-06 17:19 GMT+02:00 Willy Tarreau:
> Hi guys,
>
> On Mon, Jun 06, 2016 at 04:45:49PM +0200, Thierry FOURNIER wrote:
>> Hi,
>>
>> Thank you for the bug repport. The patch in attachment fix this
>> behaviour. Can you try it ? I join a fix for current dev and 1.6
>> version and other one for the 1.5 version.
>
> That's very interesting. I indeed think it could be the same bug and
> am glad that we finally have an explanation that makes sense! I'm
> quite interested in hearing about the feedback on the patch :-)
>

i can confirm that the patch works as intended. There are no segfaults
anymore. :-) Thank you.

Kay



Re: segfault using wrong table

2016-06-06 Thread Willy Tarreau
On Mon, Jun 06, 2016 at 05:38:58PM +0200, Kay wrote:
> Hi,
> 
> 2016-06-06 17:19 GMT+02:00 Willy Tarreau:
> > Hi guys,
> >
> > On Mon, Jun 06, 2016 at 04:45:49PM +0200, Thierry FOURNIER wrote:
> >> Hi,
> >>
> >> Thank you for the bug repport. The patch in attachment fix this
> >> behaviour. Can you try it ? I join a fix for current dev and 1.6
> >> version and other one for the 1.5 version.
> >
> > That's very interesting. I indeed think it could be the same bug and
> > am glad that we finally have an explanation that makes sense! I'm
> > quite interested in hearing about the feedback on the patch :-)
> >
> 
> i can confirm that the patch works as intended. There are no segfaults
> anymore. :-) Thank you.

Excellent, thanks for the quick test, I'll merge it.

Cheers,
Willy




Re: segfault using wrong table

2016-06-06 Thread Willy Tarreau
Hi guys,

On Mon, Jun 06, 2016 at 04:45:49PM +0200, Thierry FOURNIER wrote:
> Hi,
> 
> Thank you for the bug repport. The patch in attachment fix this
> behaviour. Can you try it ? I join a fix for current dev and 1.6
> version and other one for the 1.5 version.

That's very interesting. I indeed think it could be the same bug and
am glad that we finally have an explanation that makes sense! I'm
quite interested in hearing about the feedback on the patch :-)

Willy



Re: segfault using wrong table

2016-06-06 Thread Thierry FOURNIER
Hi,

Thank you for the bug repport. The patch in attachment fix this
behaviour. Can you try it ? I join a fix for current dev and 1.6
version and other one for the 1.5 version.

Thierry Fournier




On Mon, 6 Jun 2016 11:36:52 +0200
Kay  wrote:

> Hi,
> 
> i've been playing around with stick-tables and seeing a segfault using
> a false table on the first request with the following simplified
> configuration:
> 
> defaults
> mode http
> timeout connect 10s
> timeout client 60s
> timeout server 60s
> 
> frontend www
> bind :8080
> tcp-request content track-sc0 src table IPv4
> default_backend be
> 
> backend be
> acl mark_as_abuser sc0_inc_gpc0(IPv6) gt 0
> http-request allow if mark_as_abuser
> server dummy 127.0.0.1:80
> 
> backend IPv4
> stick-table type ip size 10 expire 60s store gpc0
> backend IPv6
> stick-table type ipv6 size 10 expire 60s store gpc0
> 
> I'm using "HA-Proxy version 1.6.5-4cb6cc-9 2016/05/27" on Debian
> Jessie compiled with "make TARGET=linux2628". I've made a binary
> search with "git bisect" and found commit 0f4eadd as the first "bad"
> commit.
> 
> Maybe it is the same kind of segfault as reported in
> http://comments.gmane.org/gmane.comp.web.haproxy/27228.
> 
> Kay
> 


-- 

>From 1c23bf37deb6c20107d855cbd641e12c40b7f58c Mon Sep 17 00:00:00 2001
From: Thierry Fournier 
Date: Mon, 6 Jun 2016 16:28:05 +0200
Subject: [PATCH] BUG/MINOR: sticktables: segfault if some configuration error
 cases

When a stick table is tracked, and onther one is used later on the
configuration, a segfault occurs.

The function "smp_create_src_stkctr" can return a NULL value, and
its value is not texted, so one other function try to dereference
a NULL pointer. This patch just add a verification of the NULL
pointer.

The problem is reproduced with this configuration:

   listen www
   mode http
   bind :12345
   tcp-request content track-sc0 src table IPv4
   http-request allow if { sc0_inc_gpc0(IPv6) gt 0 }
   server dummy 127.0.0.1:80
   backend IPv4
   stick-table type ip size 10 expire 60s store gpc0
   backend IPv6
   stick-table type ipv6 size 10 expire 60s store gpc0

Thank to ruth gozlan for the bug repport.

This patch must be backported in the 1.6 and 1.5 version.

Conflicts:
	src/stream.c
---
 src/session.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/session.c b/src/session.c
index 4e84803..fbd5094 100644
--- a/src/session.c
+++ b/src/session.c
@@ -2908,7 +2908,7 @@ smp_fetch_sc_inc_gpc0(struct proxy *px, struct session *l4, void *l7, unsigned i
 	smp->flags = SMP_F_VOL_TEST;
 	smp->type = SMP_T_UINT;
 	smp->data.uint = 0;
-	if (stkctr_entry(stkctr) != NULL) {
+	if (stkctr && stkctr_entry(stkctr)) {
 		void *ptr;
 
 		/* First, update gpc0_rate if it's tracked. Second, update its
-- 
2.1.4

>From c32186135af3e5ad6ed76c3b77e010a194f52371 Mon Sep 17 00:00:00 2001
From: Thierry Fournier 
Date: Mon, 6 Jun 2016 16:28:05 +0200
Subject: [PATCH] BUG/MINOR: sticktables: segfault if some configuration error
 cases

When a stick table is tracked, and onther one is used later on the
configuration, a segfault occurs.

The function "smp_create_src_stkctr" can return a NULL value, and
its value is not texted, so one other function try to dereference
a NULL pointer. This patch just add a verification of the NULL
pointer.

The problem is reproduced with this configuration:

   listen www
   mode http
   bind :12345
   tcp-request content track-sc0 src table IPv4
   http-request allow if { sc0_inc_gpc0(IPv6) gt 0 }
   server dummy 127.0.0.1:80
   backend IPv4
   stick-table type ip size 10 expire 60s store gpc0
   backend IPv6
   stick-table type ipv6 size 10 expire 60s store gpc0

Thank to ruth gozlan for the bug repport.

This patch must be backported in the 1.6 and 1.5 version.
---
 src/stream.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/stream.c b/src/stream.c
index 2ca3b36..fc113ec 100644
--- a/src/stream.c
+++ b/src/stream.c
@@ -2821,7 +2821,7 @@ smp_fetch_sc_inc_gpc0(const struct arg *args, struct sample *smp, const char *kw
 	if (stkctr_entry(stkctr) == NULL)
 		stkctr = smp_create_src_stkctr(smp->sess, smp->strm, args, kw);
 
-	if (stkctr_entry(stkctr) != NULL) {
+	if (stkctr && stkctr_entry(stkctr)) {
 		void *ptr1,*ptr2;
 
 		/* First, update gpc0_rate if it's tracked. Second, update its
-- 
2.1.4



segfault using wrong table

2016-06-06 Thread Kay
Hi,

i've been playing around with stick-tables and seeing a segfault using
a false table on the first request with the following simplified
configuration:

defaults
mode http
timeout connect 10s
timeout client 60s
timeout server 60s

frontend www
bind :8080
tcp-request content track-sc0 src table IPv4
default_backend be

backend be
acl mark_as_abuser sc0_inc_gpc0(IPv6) gt 0
http-request allow if mark_as_abuser
server dummy 127.0.0.1:80

backend IPv4
stick-table type ip size 10 expire 60s store gpc0
backend IPv6
stick-table type ipv6 size 10 expire 60s store gpc0

I'm using "HA-Proxy version 1.6.5-4cb6cc-9 2016/05/27" on Debian
Jessie compiled with "make TARGET=linux2628". I've made a binary
search with "git bisect" and found commit 0f4eadd as the first "bad"
commit.

Maybe it is the same kind of segfault as reported in
http://comments.gmane.org/gmane.comp.web.haproxy/27228.

Kay



做外贸用什么方法去主动的开发客户呢?

2016-06-06 Thread p1u7jr . w3l

国际经济发展到今天,做外贸的企业需要靠“搜”而不靠“等”,“主动”才能有客
户,主动才会有出路。
双喜软件,主动式外贸客户开发软件领导品牌:
1、客户搜索不设关键词限制,全球通用的13大通用搜索引擎以及200多个国家的区
域性搜索引擎,3重信息过滤功能,为您的客户客户信息搜索在质与量上保驾护
航,每天可获取【上万】客户信息。
2、内置邮件营销模块,可多账号、多主题、多模板、自动切换ip发送邮件,避免
邮件被服务器归类为垃圾邮件,有效提高邮件的到达率,每天可发送【上万】邮
件。
3、一对一专属客服为您软件的使用提供充分的保障,客服人员不仅熟悉软件,更
是外贸好手,而且具有专八英语水准以及懂的各种小语种,可以为您在客户开发上
提供切实建议。
现外贸旺季,双喜系统主动出击,帮您在全球范围内将产品推广到客户手中,获得
更多优质询盘订单的机会。 详情请家qq咨询的 237 6552 952 在线演示!






I've invited you to fill out the form 做外贸用什么方法去主动的开发客户
呢?. To fill it out, visit:
https://docs.google.com/forms/d/1trDQOozkHE91jEEErx7JUuc510YRCr5h6Y_hhoENv-s/viewform?c=0=1=mail_form_link