Re: [PATCH 1/3] MINOR: add list_append_word function

[Willy Tarreau]

I've merged all the series, thank you Maxime!

Willy

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Willy Tarreau]

Hi Maxime,

On Sat, May 14, 2016 at 12:09:07AM +0200, Maxime de Roucy wrote:
> Hello Willy,
> 
> Le vendredi 13 mai 2016 à 19:22 +0200, Willy Tarreau a écrit :
> > Maxime, could you please add a call to setlocale(LC_ALL, "") as
> > suggested by Nenad before starting to scan the directories ? If
> > something isn't 100% clear to you, do not hesitate to ask for more
> > details, you won't look stupid, I did before you :-)
> 
> It's clear.
> I didn't know either that I had to call setlocale to get the locale
> from the environment. I read the man strcoll and thought it would use
> LC_COLLATE (from the environment) without other call.

That's the benefit of posting patches to the list as you can see :-)

> I add the setlocale call in the main function because it doesn't set
> any haproxy variable. But "init" also sound like a good place.
> Let me know if you prefer to move setlocale from main.

Let's leave it there at least we can't miss it if we look for it. It's
easy to move if someone is unhappy with it.

Thanks!
Willy

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Maxime de Roucy]

Hello Willy,

Le vendredi 13 mai 2016 à 19:22 +0200, Willy Tarreau a écrit :
> Maxime, could you please add a call to setlocale(LC_ALL, "") as
> suggested by Nenad before starting to scan the directories ? If
> something isn't 100% clear to you, do not hesitate to ask for more
> details, you won't look stupid, I did before you :-)

It's clear.
I didn't know either that I had to call setlocale to get the locale
from the environment. I read the man strcoll and thought it would use
LC_COLLATE (from the environment) without other call.

I add the setlocale call in the main function because it doesn't set
any haproxy variable. But "init" also sound like a good place.
Let me know if you prefer to move setlocale from main.

$ LC_COLLATE='fr_FR.utf8' ls -l rootdir/aaa
total 0
-rw-r--r-- 1 max users 0 13 mai   22:17 a.cfg
-rw-r--r-- 1 max users 0 13 mai   22:18 A.cfg
-rw-r--r-- 1 max users 0 13 mai   22:17 à.cfg
-rw-r--r-- 1 max users 0 13 mai   22:18 À.cfg
-rw-r--r-- 1 max users 0 13 mai   22:17 â.cfg
-rw-r--r-- 1 max users 0 13 mai   22:18 Â.cfg
$ LC_COLLATE='fr_FR.utf8' ./haproxy -C rootdir -f aaa 
aaa/a.cfg
aaa/A.cfg
aaa/à.cfg
aaa/À.cfg
aaa/â.cfg
aaa/Â.cfg
$ LC_COLLATE=C ./haproxy -C rootdir -f aaa 
aaa/A.cfg
aaa/a.cfg
aaa/À.cfg
aaa/Â.cfg
aaa/à.cfg
aaa/â.cfg

-- 
Regards
Maxime de Roucy

signature.asc
Description: This is a digitally signed message part

[PATCH 1/3] MINOR: add list_append_word function

[Maxime de Roucy]

int list_append_word(struct list *li, const char *str, char **err)

Append a copy of string  (inside a wordlist) at the end of
the list .
The caller is responsible for freeing the  and  copy memory
area using free().

On failure : return 0 and  filled with an error message.
---
 include/common/standard.h |  8 
 src/standard.c| 32 
 2 files changed, 40 insertions(+)

diff --git a/include/common/standard.h b/include/common/standard.h
index cd2208c..f123f1a 100644
--- a/include/common/standard.h
+++ b/include/common/standard.h
@@ -1089,4 +1089,12 @@ static inline unsigned long long rdtsc()
 }
 #endif
 
+/* append a copy of string  (in a wordlist) at the end of the list 
+ * On failure : return 0 and  filled with an error message.
+ * The caller is responsible for freeing the  and  copy
+ * memory area using free()
+ */
+struct list;
+int list_append_word(struct list *li, const char *str, char **err);
+
 #endif /* _COMMON_STANDARD_H */
diff --git a/src/standard.c b/src/standard.c
index a4d2097..cfed94d 100644
--- a/src/standard.c
+++ b/src/standard.c
@@ -3439,6 +3439,38 @@ unsigned char utf8_next(const char *s, int len, unsigned 
int *c)
return code | ((p-(unsigned char *)s)&0x0f);
 }
 
+/* append a copy of string  (in a wordlist) at the end of the list 
+ * On failure : return 0 and  filled with an error message.
+ * The caller is responsible for freeing the  and  copy
+ * memory area using free()
+ */
+int list_append_word(struct list *li, const char *str, char **err)
+{
+   struct wordlist *wl;
+
+   wl = calloc(1, sizeof(*wl));
+   if (!wl) {
+   memprintf(err, "out of memory");
+   goto fail_wl;
+   }
+
+   wl->s = strdup(str);
+   if (!wl->s) {
+   memprintf(err, "out of memory");
+   goto fail_wl_s;
+   }
+
+   LIST_ADDQ(li, >list);
+
+   return 1;
+
+fail_wl_s:
+   free(wl->s);
+fail_wl:
+   free(wl);
+   return 0;
+}
+
 /*
  * Local variables:
  *  c-indent-level: 8
-- 
2.8.2

[PATCH 2/3] MEDIUM: init: use list_append_word in haproxy.c

[Maxime de Roucy]

replace LIST_ADDQ with list_append_word
---
 src/haproxy.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index bfd542c..3166bba 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -561,6 +561,7 @@ void init(int argc, char **argv)
char *tmp;
char *cfg_pidfile = NULL;
int err_code = 0;
+   char *err_msg = NULL;
struct wordlist *wl;
char *progname;
char *change_dir = NULL;
@@ -713,13 +714,12 @@ void init(int argc, char **argv)
/* now that's a cfgfile list */
argv++; argc--;
while (argc > 0) {
-   wl = calloc(1, sizeof(*wl));
-   if (!wl) {
-   Alert("Cannot load 
configuration file %s : out of memory.\n", *argv);
+   if (!list_append_word(_cfgfiles, 
*argv, _msg)) {
+   Alert("Cannot load 
configuration file/directory %s : %s\n",
+ *argv,
+ err_msg);
exit(1);
}
-   wl->s = *argv;
-   LIST_ADDQ(_cfgfiles, >list);
argv++; argc--;
}
break;
@@ -736,13 +736,12 @@ void init(int argc, char **argv)
case 'N' : cfg_maxpconn = atol(*argv); break;
case 'L' : strncpy(localpeer, *argv, 
sizeof(localpeer) - 1); break;
case 'f' :
-   wl = calloc(1, sizeof(*wl));
-   if (!wl) {
-   Alert("Cannot load 
configuration file %s : out of memory.\n", *argv);
+   if (!list_append_word(_cfgfiles, 
*argv, _msg)) {
+   Alert("Cannot load 
configuration file/directory %s : %s\n",
+ *argv,
+ err_msg);
exit(1);
}
-   wl->s = *argv;
-   LIST_ADDQ(_cfgfiles, >list);
break;
case 'p' : cfg_pidfile = *argv; break;
default: usage(progname);
@@ -1160,6 +1159,8 @@ void init(int argc, char **argv)
/* initialize structures for name resolution */
if (!dns_init_resolvers())
exit(1);
+
+   free(err_msg);
 }
 
 static void deinit_acl_cond(struct acl_cond *cond)
@@ -1550,6 +1551,7 @@ void deinit(void)
free(log);
}
list_for_each_entry_safe(wl, wlb, _cfgfiles, list) {
+   free(wl->s);
LIST_DEL(>list);
free(wl);
}
-- 
2.8.2

[PATCH 3/3] MEDIUM: init: allow directory as argument of -f

[Maxime de Roucy]

If -f argument is a directory add all the files (and only files) it
containes to the config files list.
These files are added in lexical order (respecting LC_COLLATE).
Only files with ".cfg" extension are added.
Only non hidden files (not prefixed with ".") are added.
Symlink are followed.
The -f order is still respected:

$ tree -a rootdir
rootdir
├── dir1
│   ├── 1.cfg
│   ├── 2
│   ├── 3.cfg
│   ├── 4.cfg -> 1.cfg
│   ├── 5 -> 1.cfg
│   ├── .6.cfg
│   ├── 7.cfg -> .
│   └── dir4
│   └── 8.cfg
├── dir2
│   ├── 10.cfg
│   └── 9.cfg
├── dir3
│   └── 11.cfg
├── link -> dir3/
├── root1
├── root2
└── root3

$ ./haproxy -C rootdir -f root2 -f dir2 -f root3 -f dir1 \
   -f link -f root1
root2
dir2/10.cfg
dir2/9.cfg
root3
dir1/1.cfg
dir1/3.cfg
dir1/4.cfg
link/11.cfg
root1

This can be useful on systemd where you can't change the haproxy
commande line options on service reload.
---
 doc/haproxy.1  |   8 ++--
 doc/management.txt |  44 +++--
 src/haproxy.c  | 110 +++--
 3 files changed, 135 insertions(+), 27 deletions(-)

diff --git a/doc/haproxy.1 b/doc/haproxy.1
index a836d5d..cc9c702 100644
--- a/doc/haproxy.1
+++ b/doc/haproxy.1
@@ -6,7 +6,7 @@ HAProxy \- fast and reliable http reverse proxy and load 
balancer
 
 .SH SYNOPSIS
 
-haproxy \-f  [\-L\ ] [\-n\ maxconn] [\-N\ maxconn] 
[\-C\ ] [\-v|\-vv] [\-d] [\-D] [\-q] [\-V] [\-c] [\-p\ ] [\-dk] 
[\-ds] [\-de] [\-dp] [\-db] [\-dM[]] [\-m\ ] [{\-sf|\-st}\ 
pidlist...]
+haproxy \-f  [\-L\ ] [\-n\ maxconn] [\-N\ 
maxconn] [\-C\ ] [\-v|\-vv] [\-d] [\-D] [\-q] [\-V] [\-c] [\-p\ ] 
[\-dk] [\-ds] [\-de] [\-dp] [\-db] [\-dM[]] [\-m\ ] [{\-sf|\-st}\ 
pidlist...]
 
 .SH DESCRIPTION
 
@@ -33,8 +33,10 @@ instances without risking the system's stability.
 .SH OPTIONS
 
 .TP
-\fB\-f \fP
-Specify configuration file path.
+\fB\-f \fP
+Specify configuration file or directory path. If the argument is a directory
+the files (and only files) it containes are added in lexical order (respecting
+LC_COLLATE) ; only non hidden files with ".cfg" extension are added.
 
 .TP
 \fB\-L \fP
diff --git a/doc/management.txt b/doc/management.txt
index e0469aa..4f0af10 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -124,26 +124,30 @@ enforce some settings without touching the configuration 
files. The current
 list of options is :
 
   -- * : all the arguments following "--" are paths to configuration
-file to be loaded and processed in the declaration order. It is mostly
-useful when relying on the shell to load many files that are numerically
-ordered. See also "-f". The difference between "--" and "-f" is that one
-"-f" must be placed before each file name, while a single "--" is needed
-before all file names. Both options can be used together, the command line
-ordering still applies. When more than one file is specified, each file
-must start on a section boundary, so the first keyword of each file must be
-one of "global", "defaults", "peers", "listen", "frontend", "backend", and
-so on. A file cannot contain just a server list for example.
-
-  -f  : adds  to the list of configuration files to be
-loaded. Configuration files are loaded and processed in their declaration
-order. This option may be specified multiple times to load multiple files.
-See also "--". The difference between "--" and "-f" is that one "-f" must
-be placed before each file name, while a single "--" is needed before all
-file names. Both options can be used together, the command line ordering
-still applies. When more than one file is specified, each file must start
-on a section boundary, so the first keyword of each file must be one of
-"global", "defaults", "peers", "listen", "frontend", "backend", and so
-on. A file cannot contain just a server list for example.
+file/directory to be loaded and processed in the declaration order. It is
+mostly useful when relying on the shell to load many files that are
+numerically ordered. See also "-f". The difference between "--" and "-f" is
+that one "-f" must be placed before each file name, while a single "--" is
+needed before all file names. Both options can be used together, the
+command line ordering still applies. When more than one file is specified,
+each file must start on a section boundary, so the first keyword of each
+file must be one of "global", "defaults", "peers", "listen", "frontend",
+"backend", and so on. A file cannot contain just a server list for example.
+
+  -f  : adds  to the list of configuration files to be
+loaded. If  

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 11:25:28PM +0200, Cyril Bonté wrote:
> > In the mean time, there may be a -fsomething option to disable a
> > bogus optimization which causes this, but that's not easy to spot
> > as it will depend on any side effect of other code :-/
> 
> I was trying to identify one, and indeed, once I add "-fno-tree-sra", it
> works as expected.

This one already exists in gcc 4 and 5, so its implementation might be bogus
in 6. The doc says :

   -ftree-sra
   Perform scalar replacement of aggregates.  This pass replaces
   structure references with scalars to prevent committing structures
   to memory too early.  This flag is enabled by default at -O and
   higher.

Thus I suspect that by delaying memory references a bit too much they end
up completely forgetting to commit the changes :-/

Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Le 13/05/2016 23:20, Willy Tarreau a écrit :

On Fri, May 13, 2016 at 11:07:18PM +0200, Cyril Bonté wrote:

At this point, I have an issue in the function str2listener() [cfgparse.c]

In the port loop :
   for (; port <= end; port++) {
 [...]
 if (l->addr.ss_family == AF_INET) {
   [...]
Here, if I print the content of :
   ((struct sockaddr_in *)(>addr))->sin_addr.s_addr [1]
I obtain 0 while I specified a "bind 127.0.0.1:10001".

But if first, I print the content of :
   ((struct sockaddr_in *)())->sin_addr.s_addr [2]
Both [1] and [2] will have the right value.

Once I compile with -O0, the issue disappears.
I also don't have the issue if I replace :
   ss = *ss2;
with :
   memcpy(, ss2, sizeof(struct sockaddr_storage));


Wow that looks horribly messy! It seems like it's doing some mess
with structure alignments, padding, offsets or anything, but anyway
it's doing something wrong if it doesn't let us write valid C code
anymore. What is worse is that it produces bogus code, that's much
worse than refusing to build. The simple fact that it totally
changes the behaviour if you insert a line before indicates a bug
to me. It's been a very long time since I've met such a beast. I
think it should be reported, but for this a simple reproducer needs
to be found otherwise the authors will not be able to work on it,
which is understandable.

In the mean time, there may be a -fsomething option to disable a
bogus optimization which causes this, but that's not easy to spot
as it will depend on any side effect of other code :-/


I was trying to identify one, and indeed, once I add "-fno-tree-sra", it 
works as expected.




So I'd strongly suggest that people don't use gcc6 for now. We may
add a check with a #error in compiler.h if that can protect users.

Thanks,
Willy




--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 11:07:18PM +0200, Cyril Bonté wrote:
> At this point, I have an issue in the function str2listener() [cfgparse.c]
> 
> In the port loop :
>   for (; port <= end; port++) {
> [...]
> if (l->addr.ss_family == AF_INET) {
>   [...]
> Here, if I print the content of :
>   ((struct sockaddr_in *)(>addr))->sin_addr.s_addr [1]
> I obtain 0 while I specified a "bind 127.0.0.1:10001".
> 
> But if first, I print the content of :
>   ((struct sockaddr_in *)())->sin_addr.s_addr [2]
> Both [1] and [2] will have the right value.
> 
> Once I compile with -O0, the issue disappears.
> I also don't have the issue if I replace :
>   ss = *ss2;
> with :
>   memcpy(, ss2, sizeof(struct sockaddr_storage));

Wow that looks horribly messy! It seems like it's doing some mess
with structure alignments, padding, offsets or anything, but anyway
it's doing something wrong if it doesn't let us write valid C code
anymore. What is worse is that it produces bogus code, that's much
worse than refusing to build. The simple fact that it totally
changes the behaviour if you insert a line before indicates a bug
to me. It's been a very long time since I've met such a beast. I
think it should be reported, but for this a simple reproducer needs
to be found otherwise the authors will not be able to work on it,
which is understandable.

In the mean time, there may be a -fsomething option to disable a
bogus optimization which causes this, but that's not easy to spot
as it will depend on any side effect of other code :-/

So I'd strongly suggest that people don't use gcc6 for now. We may
add a check with a #error in compiler.h if that can protect users.

Thanks,
Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Le 13/05/2016 22:14, Cyril Bonté a écrit :

Hi all,

Le 13/05/2016 21:24, Willy Tarreau a écrit :

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:

I will attach 2 traces, for 1.6.4 and for 1.6.5.


So indeed in your traces, we see that 1.6.5 does bind(port=443,
addr=0.0.0.0)
while 1.6.4 has the correct address. At this point your kernel is
innocent.
I don't see what could cause this in haproxy and I can't reproduce it.
Thus
I'd really favor the switch to gcc 6 as a primary cause. I fear that
we'll
discover something not fun...


I've just installed gcc 6 and compiled haproxy with it and can confirm I
observe the same issue. Now, I'll try to investigate why.


At this point, I have an issue in the function str2listener() [cfgparse.c]

In the port loop :
  for (; port <= end; port++) {
[...]
if (l->addr.ss_family == AF_INET) {
  [...]
Here, if I print the content of :
  ((struct sockaddr_in *)(>addr))->sin_addr.s_addr [1]
I obtain 0 while I specified a "bind 127.0.0.1:10001".

But if first, I print the content of :
  ((struct sockaddr_in *)())->sin_addr.s_addr [2]
Both [1] and [2] will have the right value.

Once I compile with -O0, the issue disappears.
I also don't have the issue if I replace :
  ss = *ss2;
with :
  memcpy(, ss2, sizeof(struct sockaddr_storage));


--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Hi all,

Le 13/05/2016 21:24, Willy Tarreau a écrit :

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:

I will attach 2 traces, for 1.6.4 and for 1.6.5.


So indeed in your traces, we see that 1.6.5 does bind(port=443, addr=0.0.0.0)
while 1.6.4 has the correct address. At this point your kernel is innocent.
I don't see what could cause this in haproxy and I can't reproduce it. Thus
I'd really favor the switch to gcc 6 as a primary cause. I fear that we'll
discover something not fun...


I've just installed gcc 6 and compiled haproxy with it and can confirm I 
observe the same issue. Now, I'll try to investigate why.



--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:
> I will attach 2 traces, for 1.6.4 and for 1.6.5.

So indeed in your traces, we see that 1.6.5 does bind(port=443, addr=0.0.0.0)
while 1.6.4 has the correct address. At this point your kernel is innocent.
I don't see what could cause this in haproxy and I can't reproduce it. Thus
I'd really favor the switch to gcc 6 as a primary cause. I fear that we'll
discover something not fun...

Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:
> În ziua de vineri, 13 mai 2016, la 19:12:23 EEST, Willy Tarreau a scris:
> > On Fri, May 13, 2016 at 06:59:49PM +0300, Arthur ??i??eic?? wrote:
> > > I already went back and forth between the 2 versions to confirm that it's
> > > still working fine in 1.6.4.
> > 
> > But using a version that you rebuilt for this or the version that you had
> > built some time ago ? I just want to ensure that your build environment
> > still produces valid executables in fact (as I trust it used to do last
> > time you built a working 1.6.4).
> 
> They are distro packages. As much as I can see they are built the same. I 
> will 
> put the output of '-vv' at the end the email.
> 
> However, one major change might be that 1.6.4 was built with gcc 5 and 
> haproxy 
> 1.6.5 is built with gcc 6.

OK, one more reason for first trying to build 1.6.4 from sources using the
same procedure you use for 1.6.5, and verifying if it has the same issue.

> > Let's do the strace first :-)
> > 
> 
> I hope you don't mind if I send the traces off-list. I'm not sure how much 
> private info is in there.

Definitely!

> I will attach 2 traces, for 1.6.4 and for 1.6.5.

Thanks.

willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

În ziua de vineri, 13 mai 2016, la 19:12:23 EEST, Willy Tarreau a scris:
> On Fri, May 13, 2016 at 06:59:49PM +0300, Arthur ??i??eic?? wrote:
> > I already went back and forth between the 2 versions to confirm that it's
> > still working fine in 1.6.4.
> 
> But using a version that you rebuilt for this or the version that you had
> built some time ago ? I just want to ensure that your build environment
> still produces valid executables in fact (as I trust it used to do last
> time you built a working 1.6.4).

They are distro packages. As much as I can see they are built the same. I will 
put the output of '-vv' at the end the email.

However, one major change might be that 1.6.4 was built with gcc 5 and haproxy 
1.6.5 is built with gcc 6.


> Let's do the strace first :-)
> 

I hope you don't mind if I send the traces off-list. I'm not sure how much 
private info is in there.

I will attach 2 traces, for 1.6.4 and for 1.6.5.

Thanks




# haproxy -vv
HA-Proxy version 1.6.5 2016/05/10
Copyright 2000-2016 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 
USE_PCRE_JIT=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2h  3 May 2016
Running on OpenSSL version : OpenSSL 1.0.2h  3 May 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.38 2015-11-23
PCRE library supports JIT : yes
Built with Lua version : Lua 5.3.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Willy Tarreau]

On Fri, May 13, 2016 at 07:15:11PM +0200, Nenad Merdanovic wrote:
> Hello Willy,
> 
> On 5/13/2016 7:04 PM, Willy Tarreau wrote:
> > I don't know, I'm not fond of setting things in the back of the user like
> > this. I don't even know if we have other parts that are currently sensitive
> > to the locale and which could be affected. Wouldn't it be better to simply
> > add this piece of information to the doc instead so that users know if they
> > need to specially tweak their locale ?
> 
> If we don't call 'setlocale', the tweaks will have no effect and we have
> a difference in behavior between this way and the '-- foo/*.cfg',
> because the latter will get expended by the shell in the ordered
> specified by LC_COLLATE while the new way will order the files as if
> LC_COLLATE was set to 'C'.

Ah OK that's what I did't know, that was not obvious from my reading of
the doc, thank you.

> Unless you are thinking of asking the user through the doc to adapt
> their filenames so that they are not affected by the locale differences.

No of course you're right, for me the purpose of the doc here was to let
the user know we respect the locale and that it's his problem to ensure
his sorting options are correct in his locale and match his shell for
instance. But of course if for this to work we have to do something we
must do it.

Maxime, could you please add a call to setlocale(LC_ALL, "") as suggested
by Nenad before starting to scan the directories ? If something isn't 100%
clear to you, do not hesitate to ask for more details, you won't look
stupid, I did before you :-)

Thanks,
Willy

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Nenad Merdanovic]

Hello Willy,

On 5/13/2016 7:04 PM, Willy Tarreau wrote:
> I don't know, I'm not fond of setting things in the back of the user like
> this. I don't even know if we have other parts that are currently sensitive
> to the locale and which could be affected. Wouldn't it be better to simply
> add this piece of information to the doc instead so that users know if they
> need to specially tweak their locale ?

If we don't call 'setlocale', the tweaks will have no effect and we have
a difference in behavior between this way and the '-- foo/*.cfg',
because the latter will get expended by the shell in the ordered
specified by LC_COLLATE while the new way will order the files as if
LC_COLLATE was set to 'C'.

Unless you are thinking of asking the user through the doc to adapt
their filenames so that they are not affected by the locale differences.

> Do not hesitate to tell me if I'm
> wrong on something, I always try to stay away from locale manipulation
> because I know how painful everything becomes once you start to break the
> fragile equilibrium!

Agree there 100%, but all this is to follow up that we might be changing
the order the files are loaded, so we either address this in the code or
in the docs.

Thanks,
Nenad

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 06:59:49PM +0300, Arthur ??i??eic?? wrote:
> I already went back and forth between the 2 versions to confirm that it's
> still working fine in 1.6.4.

But using a version that you rebuilt for this or the version that you had
built some time ago ? I just want to ensure that your build environment
still produces valid executables in fact (as I trust it used to do last
time you built a working 1.6.4).

> When I get home I will try to start haproxy in debug mode and I will try to
> strace it (any help on this would be appreciated).

OK thanks. For this, just run ps auxw|grep haproxy, then copy-paste the exact
command line, kill it, and run :

   strace -tts200 -o haproxy.trace [paste-exact-command-line-here]

Once you're confident that it has finished starting, you can press Ctrl-C
(or killall haproxy from another window), and everything will be in
haproxy.trace.

> If all fails I will reboot the server in a non-grsec kernel (4.5.2 btw).

Let's do the strace first :-)

Thanks,
Willy

Re: 100% cpu , epoll_wait()

[Willy Tarreau]

Hi Lukas,

On Fri, May 13, 2016 at 06:36:38PM +0200, Lukas Tribus wrote:
> Not sure if that's what you meant by the other issue, but if there are still
> buffer issues it may also caused the reported crash in zlib (since 1.6.4 but
> also affects 1.6.5), that would be thread "Crash with kernel error", where
> we are waiting for the OP to provide a stack trace.

You're absolutely right. I analysed this one (when the crash moved to glibc)
and found in another RHEL6's libc that the instruction pointer was suspiciously
close to memcpy(), and there are indeed memcpy() calls in the compression path.
So assuming we get a negative length somewhere, all of this could be tied to
a single bug having various effects depending on the version, config and
environment. Now the question is : what could cause this ? We have Sasha's
dump which will help figure in what state his sessions are and see in the
code 1) if it's normal to end up in this state, and 2) if/why there is no
way to leave this state.

Willy

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Willy Tarreau]

On Fri, May 13, 2016 at 06:38:06PM +0200, Nenad Merdanovic wrote:
> Hello Willy,
> 
> On 5/13/2016 12:54 PM, Willy Tarreau wrote:
> > Wait a minute, what do you mean by "different lower/upper case sorting" ?
> > Do you mean that alphasort() ignores the case ? I'm seeing no mention about
> > it in the man page, so I'm confused. If this is the case, it can be annoying
> > for the same reason.
> 
> Sorry for my vagueness, was writing a response in a hurry so didn't
> explain it well. The thing is, we don't set the locale anywhere within
> HAproxy, as far as I am aware at least. The shell expansion will honor
> LC_COLLATE, while the ordering of scandir's alphasort will default to C.

OK, thanks for clarifying.

> Maybe it would be worth adding 'setlocale(LC_ALL, "")' before, so we
> pick up the user's environment?

I don't know, I'm not fond of setting things in the back of the user like
this. I don't even know if we have other parts that are currently sensitive
to the locale and which could be affected. Wouldn't it be better to simply
add this piece of information to the doc instead so that users know if they
need to specially tweak their locale ? Do not hesitate to tell me if I'm
wrong on something, I always try to stay away from locale manipulation
because I know how painful everything becomes once you start to break the
fragile equilibrium!

Thanks,
Willy

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Nenad Merdanovic]

Hello Willy,

On 5/13/2016 12:54 PM, Willy Tarreau wrote:
> Wait a minute, what do you mean by "different lower/upper case sorting" ?
> Do you mean that alphasort() ignores the case ? I'm seeing no mention about
> it in the man page, so I'm confused. If this is the case, it can be annoying
> for the same reason.

Sorry for my vagueness, was writing a response in a hurry so didn't
explain it well. The thing is, we don't set the locale anywhere within
HAproxy, as far as I am aware at least. The shell expansion will honor
LC_COLLATE, while the ordering of scandir's alphasort will default to C.

Maybe it would be worth adding 'setlocale(LC_ALL, "")' before, so we
pick up the user's environment?

Regards,
Nenad

Re: 100% cpu , epoll_wait()

[Lukas Tribus]

Hi Willy,


Am 13.05.2016 um 17:01 schrieb Willy Tarreau:

Hi Sebastian,

On Thu, May 12, 2016 at 09:58:22AM +0200, Sebastian Heid wrote:

Hi Lukas,

starting from around 200mbit/s in, haproxy processes (nbproc 6) are hitting 
100% cpu regularly (noticed up to 3 processes at the same time with 100%), but 
recover again on its own after some time.

stracing such a process yesterday showed the following:
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 0)   = 0
  
Unfortunately I can't do any more debugging in this setup. HAproxy 1.5.14 is never near to 10% cpu usage with way higher bandwidth.

So we still have another situation making haproxy think it can receive while
it cannot. There's a report of another issue possibly related to this on 1.6,
so let me try to understand it then I'll check if it may cause this behaviour
on 1.5 (assuming it's present there as well). Don't take risks for now.


Not sure if that's what you meant by the other issue, but if there are 
still buffer issues it may also caused the reported crash in zlib (since 
1.6.4 but also affects 1.6.5), that would be thread "Crash with kernel 
error", where we are waiting for the OP to provide a stack trace.



cheers,
Lukas

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

I already went back and forth between the 2 versions to confirm that it's
still working fine in 1.6.4.

When I get home I will try to start haproxy in debug mode and I will try to
strace it (any help on this would be appreciated).

If all fails I will reboot the server in a non-grsec kernel (4.5.2 btw).
Pe 13 mai 2016 6:51 p.m., "Willy Tarreau"  a scris:

> On Fri, May 13, 2016 at 06:30:35PM +0300, Arthur ??i??eic?? wrote:
> > Hi,
> >
> > 1.6.4 worked fine with the same config.
> >
> > I noticed this because I have the same port bound on 127.0.0.1 too and
> > haproxy refused to start after upgrade.
> >
> > Another curious thing is that with haproxy bind on *two* ipv4 addresses I
> > also see two *:143 in the 'ss' output.
> >
> > This is not specific to the listen directive. It happens on all ipv4
> > addresses with 'frontend' or 'listen' both TCP and HTTP.
>
> Thus it sounds like something changed in the address parser and affected
> you. The problem is that I'm not seeing any such change.
>
> It would be interesting to try to rebuild 1.6.4 on the same machine to
> see if it suddenly fails, possibly indicating something else has changed
> (eg: libc update, build options, etc).
>
> Thanks
> willy
>
>

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 06:30:35PM +0300, Arthur ??i??eic?? wrote:
> Hi,
> 
> 1.6.4 worked fine with the same config.
> 
> I noticed this because I have the same port bound on 127.0.0.1 too and
> haproxy refused to start after upgrade.
> 
> Another curious thing is that with haproxy bind on *two* ipv4 addresses I
> also see two *:143 in the 'ss' output.
>
> This is not specific to the listen directive. It happens on all ipv4
> addresses with 'frontend' or 'listen' both TCP and HTTP.

Thus it sounds like something changed in the address parser and affected
you. The problem is that I'm not seeing any such change.

It would be interesting to try to rebuild 1.6.4 on the same machine to
see if it suddenly fails, possibly indicating something else has changed
(eg: libc update, build options, etc).

Thanks
willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Pavlos Parissis]

On 13/05/2016 04:41 μμ, Arthur Țițeică wrote:
> Hi,
> 
> With the 1.6.5 upgrade I see that a configuration like this
> 
> listen tcp-imap
>   bind 1.2.3.4:143 name imap-v4
> 
> will make haproxy listen on all ipv4 addresses instead.
> 
> # ss -ltnp | column -t| grep 143
> LISTEN  0   50  *:143 *:* users:(("haproxy",pid=13010,fd=19))
> 
> IPv6 works as advertised.
> 
> ​Thanks​
> 

I *can't* reproduce this on 1.6.5


% sudo haproxytool haproxy -F /var/lib/haproxy/stats --release-date
2016/05/10


% sudo haproxytool haproxy -F /var/lib/haproxy/stats --uptime-secs
189253


%sudo haproxytool haproxy -F /var/lib/haproxy/stats --hap-version
1.6.5


% grep bind /etc/haproxy/haproxy.cfg
bind :8080
bind 10.252.12.1:80
bind 10.252.12.1:443 ssl crt /etc/ssl/certs/foo
bind 10.252.12.2:80
bind 10.252.12.2:443 ssl crt /etc/ssl/certs/foo
bind 10.252.12.3:80
bind 10.252.12.3:443 ssl crt /etc/ssl/certs/foo



% sudo ss -ltnp|egrep '80|443'|column -t
LISTEN  0  2048  10.252.12.3:80 *:*  users:(("haproxy",49818,11))
LISTEN  0  2048  10.252.12.2:80 *:*  users:(("haproxy",49818,9))
LISTEN  0  2048  10.252.12.1:80 *:*  users:(("haproxy",49818,6))
LISTEN  0  2048  *:8080 *:*  users:(("haproxy",49818,5))
LISTEN  0  2048  10.252.12.3:443*:*  users:(("haproxy",49818,12))
LISTEN  0  2048  10.252.12.2:443*:*  users:(("haproxy",49818,10))
LISTEN  0  2048  10.252.12.1:443*:*  users:(("haproxy",49818,8))
LISTEN  0  1024  10.196.180.4:2812  *:*  users:(("monit",8746,6))

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

Hi,

1.6.4 worked fine with the same config.

I noticed this because I have the same port bound on 127.0.0.1 too and
haproxy refused to start after upgrade.

Another curious thing is that with haproxy bind on *two* ipv4 addresses I
also see two *:143 in the 'ss' output.

This is not specific to the listen directive. It happens on all ipv4
addresses with 'frontend' or 'listen' both TCP and HTTP.

Thanks
Pe 13 mai 2016 6:14 p.m., "Willy Tarreau"  a scris:

> Hi Arthur,
>
> On Fri, May 13, 2016 at 05:41:50PM +0300, Arthur ??i??eic?? wrote:
> > Hi,
> >
> > With the 1.6.5 upgrade I see that a configuration like this
> >
> > listen tcp-imap
> >   bind 1.2.3.4:143name imap-v4
> >
> > will make haproxy listen on all ipv4 addresses instead.
> >
> > # ss -ltnp | column -t| grep 143
> > LISTEN  0   50  *:143 *:* users:(("haproxy",pid=13010,fd=19))
> >
> > IPv6 works as advertised.
>
> I can't reproduce this behaviour :
>
> $ ss -ltnp | grep 1143|column -t
> LISTEN  0  128  1.2.3.4:1143  *:*  users:(("haproxy",pid=7547,fd=4))
>
> Are you certain you didn't change the bind address without restarting
> or anything like this ? I guess so but I'm trying to find a rationale
> reason. What version did not exhibit this behaviour previously ?
>
> Thanks,
> Willy
>

Re: Adding backend server name as request header

[Willy Tarreau]

On Thu, May 12, 2016 at 11:09:09PM +0200, Dennis Jacobfeuerborn wrote:
> Hi,
> remember that this directive adds a request header and not a response
> header i.e. you will not see this header in the response in the browser
> but only in the request on the backend server that will serve the
> request. There you can copy that information into a response header if
> you want.

If you want it in the response, it's much easier :

  http-response add-header x-foo-server-name %s

Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

Hi Arthur,

On Fri, May 13, 2016 at 05:41:50PM +0300, Arthur ??i??eic?? wrote:
> Hi,
> 
> With the 1.6.5 upgrade I see that a configuration like this
> 
> listen tcp-imap
>   bind 1.2.3.4:143name imap-v4
> 
> will make haproxy listen on all ipv4 addresses instead.
> 
> # ss -ltnp | column -t| grep 143
> LISTEN  0   50  *:143 *:* users:(("haproxy",pid=13010,fd=19))
> 
> IPv6 works as advertised.

I can't reproduce this behaviour :

$ ss -ltnp | grep 1143|column -t
LISTEN  0  128  1.2.3.4:1143  *:*  users:(("haproxy",pid=7547,fd=4))

Are you certain you didn't change the bind address without restarting
or anything like this ? I guess so but I'm trying to find a rationale
reason. What version did not exhibit this behaviour previously ?

Thanks,
Willy

Re: Regarding http basic authentication in haproxy

[Willy Tarreau]

On Fri, May 13, 2016 at 08:38:50AM +1000, Igor Cicimov wrote:
> On 13 May 2016 4:19 am, "bln prasad"  wrote:
> >
> > Hi,
> >   I've setup basic http authentication in the frontend. I'm finding that
> it's asking for authentication for first time only when i access from the
> browser. Once it succeeds it's alway bypasses authentication even if i
> access it from other tabs or  re access from sam tab.
> >
> > Is it expected?
> 
> Yes it is expected
> 
> If yes then can you please let me know how do i force authentication on
> every new tab or from same tab.
> >
> 
> Only way is to close the browser. Nothing specific to haproxy thats how the
> basic auth works.

And to go further, this point was discussed 1 or 2 years ago on the HTTP
working group at the IETF with the browser people (eg: have a button to
make the browser forget the credentials) and from what I remember it's
not easy to do without adding a certain level of confusion to the user.
And that's in part why basic auth is rarely used nowadays...

Willy

Re: Managing `Expect: 100-continue` in HAProxy?

[Willy Tarreau]

Hi James,

On Fri, May 06, 2016 at 02:41:12PM -0700, James Brown wrote:
> We've got HAProxy sitting in front of a menagerie of web servers, none
> of which handle `Expect: 100-continue` in any way, shape, or form.
> When someone hits us with a POST from cURL, there's a kind of
> irritating 1 second delay while cURL waits for the "HTTP/1.1 100
> Continue" response. Rather than try to solve it in every application
> server, I was wondering if there's any way to force HAProxy to send a
> "100 Continue" response when it gets a POST with "Expect:
> 100-continue" (and then delete the Expect from the proxied request, of
> course).
> 
> It seems like there's already code for sending a 100 Continue if the
> `http-buffer-request` option is set, so I guess I'm just asking about
> the feasibility of making that behavior a stand-alone option without
> having to put the whole request in RAM.

It's not the whole request that fits in RAM, it's always limited to the
size of a buffer (typically 16kB). So you shouldn't worry at all, this
option will definitely help you without adding any extra cost.
 
Regards,
Willy

Re: 100% cpu , epoll_wait()

[Willy Tarreau]

Hi Sebastian,

On Thu, May 12, 2016 at 09:58:22AM +0200, Sebastian Heid wrote:
> Hi Lukas,
> 
> starting from around 200mbit/s in, haproxy processes (nbproc 6) are 
> hitting 100% cpu regularly (noticed up to 3 processes at the same time with 
> 100%), but recover again on its own after some time. 
> 
> stracing such a process yesterday showed the following:
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
> epoll_wait(0, {}, 200, 0)   = 0
>  
> Unfortunately I can't do any more debugging in this setup. HAproxy 1.5.14 is 
> never near to 10% cpu usage with way higher bandwidth.

So we still have another situation making haproxy think it can receive while
it cannot. There's a report of another issue possibly related to this on 1.6,
so let me try to understand it then I'll check if it may cause this behaviour
on 1.5 (assuming it's present there as well). Don't take risks for now.

Thanks,
Willy

胶东大樱桃，顺丰空运！

[胶东大樱桃]

淘宝链接: https://item.taobao.com/item.htm?id=531564140475
胶东大樱桃，顺丰空运！
小女子的樱桃店新开张优惠多多!
你敢买我就敢减！
前100名订单再优惠10元！ 
淘宝链接: https://item.taobao.com/item.htm?id=531564140475
<<< image/jpeg; name="大樱桃.jpg": Unrecognized >>>

Re: Haproxy running on 100% CPU and slow downloads

[Willy Tarreau]

On Fri, May 13, 2016 at 07:32:36PM +0530, Sachin Shetty wrote:
> In 24 hours all servers had connections growing, we have reverted the
> patch for now.
> 
> I have the show sess all output if you would like to see.

Interestingly in the "show sess all" from yesterday I'm seeing only
negative "tofwd" values for stuck sessions. Exactly the type of thing
which is supposedly fixed now (it's the problem with 2-4GB transfers).
I don't understand since I tested the backport and had the confirmation
from another user that it was OK for him. Maybe there's a corner case I
haven't figure which may depend on certain options.

Could you please send me privately your config (remove the confidential
stuff) ? I think you gave it to me a few times already but I don't want
to keep those you know.

Thanks,
Willy

Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

Hi,

With the 1.6.5 upgrade I see that a configuration like this

listen tcp-imap
  bind 1.2.3.4:143name imap-v4

will make haproxy listen on all ipv4 addresses instead.

# ss -ltnp | column -t| grep 143
LISTEN  0   50  *:143 *:* users:(("haproxy",pid=13010,fd=19))

IPv6 works as advertised.

​Thanks​

Re: Haproxy running on 100% CPU and slow downloads

[Willy Tarreau]

Hi Sachin,

On Fri, May 13, 2016 at 07:32:36PM +0530, Sachin Shetty wrote:
> In 24 hours all servers had connections growing, we have reverted the
> patch for now.
> 
> I have the show sess all output if you would like to see.

Thank you very much, that's extremely useful. I'll probably get back to
you in the next few days if I find that I need more information. Indeed,
do not take risks on your production, our development model makes it
easy for you to limit the risks by switching back, so stay safe!

Best regards,
Willy

Re: Haproxy running on 100% CPU and slow downloads

[Sachin Shetty]

In 24 hours all servers had connections growing, we have reverted the
patch for now.

I have the show sess all output if you would like to see.

Thanks
Sachin

On 5/12/16, 10:08 PM, "Sachin Shetty"  wrote:

>Hi Lukas,
>
>Attached output.
>
>Thanks
>Sachin
>
>On 5/12/16, 7:41 PM, "Lukas Tribus"  wrote:
>
>>Hi,
>>
>>
>>Am 12.05.2016 um 14:37 schrieb Sachin Shetty:
>>> Hi Willy,
>>>
>>> We are seeing a strange problem  on the patched server. We have several
>>> haproxy servers running but only one with the latest patch, and this
>>> haproxy has frozen twice in last two days, basically it hits max open
>>> connections 2000 on frontend and then stalls. From the logs it has 1999
>>> connections on one of the backends which is nginx, but nginx_status
>>>shows
>>> me only a few active connections. It only happens on the patched
>>>haproxy
>>> server and does not happen anywhere else. Interesting thing is this
>>> haproxy is not the one doing SSL, we have two haproxies on the same box
>>> with the latest binary, the SSL one seems ok but the non SSL one keeps
>>>on
>>> accumulating connections.
>>>
>>> Right now, I see connections building on one backend hitting 150 in the
>>> last few hours, but the backend nginx only shows about 20 active
>>> connections.
>>
>>Can you collect "show sess all" output from the admin socket?
>>
>>Lukas

Re: dynamically choosing back-end port

[William Lallemand]

Hi Derek,

I have the same need and I'm working on the 'http-request set-dst' and
'http-request set-dst-port' actions to cover it.

It would work in the same way as 'http-request set-src' do with the evaluation
of an expression.


On Thu, May 12, 2016 at 12:15:48PM -0700, Derek Brown wrote:
> Hi-
> 
> I'm wondering if you need any additional information, or if I can provide
> any clarification, to get a response to my query.
> 
> Thanks, in advance
> Derek
> 

-- 
William Lallemand

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Willy Tarreau]

On Fri, May 13, 2016 at 11:18:23AM +0200, Nenad Merdanovic wrote:
> >> If the .cnf files contain rules that are sensitive to ordering, this
> >> could be problematic. I am not saying we should change it, just to
> >> consider it :)
> > 
> > I've thought about this as well but figured that we'd rather not change
> > the ordering of what people used to get with "-- dir/*.cfg". Changing
> > the sort algorithm would make a difference here and it might not encourage
> > people to use directories. I could be wrong of course, but that's my 
> > feeling.
> > 
> 
> I figured that since we are changing behavior already with different
> lowercase/uppercase sorting, this might be less of an issue. But you are
> right, the less behavior changes we do, the better.

Wait a minute, what do you mean by "different lower/upper case sorting" ?
Do you mean that alphasort() ignores the case ? I'm seeing no mention about
it in the man page, so I'm confused. If this is the case, it can be annoying
for the same reason.

Thanks,
Willy

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Cyril Bonté]

Hi all,

Le 13/05/2016 08:07, Willy Tarreau a écrit :

Hi Maxime,

On Fri, May 13, 2016 at 12:48:43AM +0200, Maxime de Roucy wrote:

If -f argument is a directory add all the files (and only files) it
containes to the config files list.
These files are added in lexical order (man alphasort).
Only files with ".cfg" extension are added.
Only non hidden files (not prefixed with ".") are added.
Symlink are followed.
The -f order is still respected:

$ tree -a rootdir
rootdir
? dir1
???   ? 1.cfg
???   ? 2
???   ? 3.cfg
???   ? 4.cfg -> 1.cfg
???   ? 5 -> 1.cfg
???   ? .6.cfg
???   ? 7.cfg -> .
???   ? dir4
???   ? 8.cfg
? dir2
???   ? 10.cfg
???   ? 9.cfg
? dir3
???   ? 11.cfg
? link -> dir3/
? root1
? root2
? root3

$ ./haproxy -C rootdir -f root2 -f dir2 -f root3 -f dir1 \
   -f link -f root1
root2
dir2/10.cfg
dir2/9.cfg
root3
dir1/1.cfg
dir1/3.cfg
dir1/4.cfg
link/11.cfg
root1

This can be useful on systemd where you can't change the haproxy
commande line options on service reload.


I think I'm fine with this one (I'll still wait a bit to let others respond).


From the commit message, it looks OK for me too, thanks ;-)


--
Cyril Bonté

Architectural Rendering - Architectural stories though images

[SA Digital]

Introducing you great architectural visualization company.
View this email in your browser 
(http://us13.campaign-archive2.com/?u=8a11ba767c0a3d6cbbd1cf745=496793bc91=67ca1c05f0)
Hi,

I'm Tom Yang from Guangzhou Sea-Art Digital Technology Co., Ltd. We are a group 
of highly skilled experts from the fields of architecture, design and 
technology.

Our team professionally envisions the unbuilt architecture, and creates 
high-end narrative and atmospheric environments. Going beyond mere 
representation and thus deeply engaging the viewer wih the architecture design 
– this is our ultimate goal.

We have 10 years experience working with clients from USA, Europe, UAE , KSA 
and Asia. Please check out our work below and find out more on Behance: 
http://sa-cn.us13.list-manage.com/track/click?u=8a11ba767c0a3d6cbbd1cf745=73f572957f=67ca1c05f0

If you have any ongoing projects which require high-end rendering, please do 
not hesitate to contact me.

Best regards,
Tom


** BEHANCE GALLERY

http://sa-cn.us13.list-manage.com/track/click?u=8a11ba767c0a3d6cbbd1cf745=4ce75190ee=67ca1c05f0
Rendering | Animation | Multi-media |

Email: sadigita...@sa-cn.com
Mobile: 86-156 2619 8250
(WhatsApp, Viber, Wechat)
Skype: live:sadigital03
CONTACT NOW 
(mailto:sadigita...@sa-cn.com?subject=I%20would%20like%20to%20know%20more%20about%20you)


** KEEP IN TOUCH

http://sa-cn.us13.list-manage.com/track/click?u=8a11ba767c0a3d6cbbd1cf745=bbfa278fb2=67ca1c05f0
 C O N N E C T on L I N K E D I N 
(http://sa-cn.us13.list-manage.com/track/click?u=8a11ba767c0a3d6cbbd1cf745=1d7a682170=67ca1c05f0)
http://sa-cn.us13.list-manage.com/track/click?u=8a11ba767c0a3d6cbbd1cf745=8bcb469d05=67ca1c05f0
 V I E W our W E B S I T E 
(http://sa-cn.us13.list-manage.com/track/click?u=8a11ba767c0a3d6cbbd1cf745=68b41c6d97=67ca1c05f0)


Copyright © 2016 Guangzhou Sea-Art Digital Technology Co.,Ltd., All rights 
reserved.
 To be honest, we get your email from Google. We know it's a bit rude to add 
you to this list without permission. If it's unrelated your business or you 
feel bothered, please accept my sincere apology and just unsubscribe us.

Our mailing address is:
Guangzhou Sea-Art Digital Technology Co.,Ltd.
Room1804 King Platinum International
Dongfeng Dong Rd, Yuexiu District, Guangzhou, China
Guangzhou, 44 51
China
Want to change how you receive these emails?
You can ** update your preferences 
(http://sa-cn.us13.list-manage1.com/profile?u=8a11ba767c0a3d6cbbd1cf745=1bd2f04b49=67ca1c05f0)
or ** unsubscribe from this list 
(http://sa-cn.us13.list-manage2.com/unsubscribe?u=8a11ba767c0a3d6cbbd1cf745=1bd2f04b49=67ca1c05f0=496793bc91)
 Email Marketing Powered by MailChimp
http://www.mailchimp.com/monkey-rewards/?utm_source=freemium_newsletter_medium=email_campaign=monkey_rewards=8a11ba767c0a3d6cbbd1cf745=1

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Nenad Merdanovic]

Hello Willy,

On 5/13/2016 11:04 AM, Willy Tarreau wrote:
> Hi Nenad,
> 
> On Fri, May 13, 2016 at 11:02:01AM +0200, Nenad Merdanovic wrote:
>> Hello,
>>
>> On 5/13/2016 8:07 AM, Willy Tarreau wrote:
>>> I think I'm fine with this one (I'll still wait a bit to let others 
>>> respond).
>>> I just have one small request, please move the addition of 
>>> list_append_word()
>>> to its own patch : if later we use it to fix a bug which needs to be
>>> backported, we'll be able to simply pick it for the backport as well.
>>
>> I'd just like to ask for consideration between alphasort and
>> versionsort. I've seen people have a (bad) habit of naming files like:
>> 1-first.cnf
>> 2-second.cnf
>> ...
>> 10-tenth.cnf
>>
>> If the .cnf files contain rules that are sensitive to ordering, this
>> could be problematic. I am not saying we should change it, just to
>> consider it :)
> 
> I've thought about this as well but figured that we'd rather not change
> the ordering of what people used to get with "-- dir/*.cfg". Changing
> the sort algorithm would make a difference here and it might not encourage
> people to use directories. I could be wrong of course, but that's my feeling.
> 

I figured that since we are changing behavior already with different
lowercase/uppercase sorting, this might be less of an issue. But you are
right, the less behavior changes we do, the better.

Cheers,
Nenad

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Willy Tarreau]

Hi Nenad,

On Fri, May 13, 2016 at 11:02:01AM +0200, Nenad Merdanovic wrote:
> Hello,
> 
> On 5/13/2016 8:07 AM, Willy Tarreau wrote:
> > I think I'm fine with this one (I'll still wait a bit to let others 
> > respond).
> > I just have one small request, please move the addition of 
> > list_append_word()
> > to its own patch : if later we use it to fix a bug which needs to be
> > backported, we'll be able to simply pick it for the backport as well.
> 
> I'd just like to ask for consideration between alphasort and
> versionsort. I've seen people have a (bad) habit of naming files like:
> 1-first.cnf
> 2-second.cnf
> ...
> 10-tenth.cnf
> 
> If the .cnf files contain rules that are sensitive to ordering, this
> could be problematic. I am not saying we should change it, just to
> consider it :)

I've thought about this as well but figured that we'd rather not change
the ordering of what people used to get with "-- dir/*.cfg". Changing
the sort algorithm would make a difference here and it might not encourage
people to use directories. I could be wrong of course, but that's my feeling.

Willy

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Nenad Merdanovic]

Hello,

On 5/13/2016 8:07 AM, Willy Tarreau wrote:
> I think I'm fine with this one (I'll still wait a bit to let others respond).
> I just have one small request, please move the addition of list_append_word()
> to its own patch : if later we use it to fix a bug which needs to be
> backported, we'll be able to simply pick it for the backport as well.

I'd just like to ask for consideration between alphasort and
versionsort. I've seen people have a (bad) habit of naming files like:
1-first.cnf
2-second.cnf
...
10-tenth.cnf

If the .cnf files contain rules that are sensitive to ordering, this
could be problematic. I am not saying we should change it, just to
consider it :)

Cheers,
Nenad

> 
> Thanks,
> Willy
> 
> 

Re: [PATCH] MEDIUM: init: allow directory as argument of -f

[Willy Tarreau]

Hi Maxime,

On Fri, May 13, 2016 at 12:48:43AM +0200, Maxime de Roucy wrote:
> If -f argument is a directory add all the files (and only files) it
> containes to the config files list.
> These files are added in lexical order (man alphasort).
> Only files with ".cfg" extension are added.
> Only non hidden files (not prefixed with ".") are added.
> Symlink are followed.
> The -f order is still respected:
> 
>   $ tree -a rootdir
>   rootdir
>   ? dir1
>   ???   ? 1.cfg
>   ???   ? 2
>   ???   ? 3.cfg
>   ???   ? 4.cfg -> 1.cfg
>   ???   ? 5 -> 1.cfg
>   ???   ? .6.cfg
>   ???   ? 7.cfg -> .
>   ???   ? dir4
>   ???   ? 8.cfg
>   ? dir2
>   ???   ? 10.cfg
>   ???   ? 9.cfg
>   ? dir3
>   ???   ? 11.cfg
>   ? link -> dir3/
>   ? root1
>   ? root2
>   ? root3
> 
>   $ ./haproxy -C rootdir -f root2 -f dir2 -f root3 -f dir1 \
>  -f link -f root1
>   root2
>   dir2/10.cfg
>   dir2/9.cfg
>   root3
>   dir1/1.cfg
>   dir1/3.cfg
>   dir1/4.cfg
>   link/11.cfg
>   root1
> 
> This can be useful on systemd where you can't change the haproxy
> commande line options on service reload.

I think I'm fine with this one (I'll still wait a bit to let others respond).
I just have one small request, please move the addition of list_append_word()
to its own patch : if later we use it to fix a bug which needs to be
backported, we'll be able to simply pick it for the backport as well.

Thanks,
Willy