Re: Does HAProxy 1.8.0 need new param vs 1.7.9

[Willy Tarreau]

Hi Hemant,

On Mon, Nov 27, 2017 at 12:11:25PM -0600, Coscend@Coscend wrote:
> Dear HAProxy community,
> 
> We have been successfully loading Stats page and other applications via
> HAProxy 1.7.9.  We successfully compiled, installed and ran 1.8.0 as a
> systemd service.  However, with 1.8.0, we are unable to access the same
> stats page or any other application.  We are using the same set of multiple
> HAProxy configuration files for both 1.8.0 and 1.7.9.  Ports on firewalls
> are open and policies are enabled, as verified by a working v. 1.7.9.
> 
> No log is being captured by HAProxy during access to these pages /
> applications.  Router log gives HAProxy is resetting the request.  The Web
> page on browser states "the connection was reset."  
> 
> Would you be kind enough to provide any vectors on what new configuration
> parameter we should add / modify for 1.8.0 (different from 1.7.9)?  

Nothing in theory. Can you check if the process is still present (ps aux) ?
If it is, are the ports properly listening (netstat -ltnp) ?

> Below is haproxy -vv.  Command to start HAProxy:  
> 
> CONFIG=
> 
> ExecStart=/usr/local/sbin/haproxy -Ws -V -C $CONFIG -f $CONFIG -f
> $ -f $ -D -p $PIDFILE 

Just out of curiosity, are you certain that the binary in this
absolute path is the one you expect ? For example if you had
installed it in another place still in your path, haproxy -vv
would find the new one but the one above would be the old one
and would fail on "-Ws". Do you have anything in systemd's logs
related to the startup ?

Regards,
Willy

Re: [1.8] tune.ssl.cachesize

[Willy Tarreau]

Hi Maciej,

On Mon, Nov 27, 2017 at 09:15:22AM +0100, Maciej Zdeb wrote:
> Hi,
> 
> Thank you for your hard work on HAProxy 1.8 - great job!
> 
> I tried to update haproxy from 1.7 on our r machine to 1.8 version
> however stumbled upon problem with tune.ssl.cachesize directive.
> 
> In 1.7.3 with tune.ssl.cachesize = 1000:
> 
> ps aux | grep haproxy
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> haproxy  43863  0.1  0.0 2327496 13052 ?  Ss   08:54   0:00
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D
> 
> Note VSZ is 2327496.
> 
> In 1.8.0 with tune.ssl.cachesize = 1000:
> [ALERT] 330/085923 (30585) : Unable to allocate SSL session cache.
> 
> In 1.8.0 with tune.ssl.cachesize = 300:
> ps aux | grep haprox
> USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> haproxy  34539  0.0  0.4 30342220 163784 ? Ss   09:01   0:00
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid
> 
> Note VSZ is 30342220.
> 
> In docs i don't see any related change:
> http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#3.2-tune.
> ssl.cachesize
> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-tune.
> ssl.cachesize
> 
> What is the proper way to calculate ssl cachesize in 1.8? Is it bug or docs
> need update?

Wow, multiplied by 15! It looks like each entry now takes 3kB instead
of 200 bytes, maybe something has changed with the default block size.
CCing William for advice.

Thanks,
Willy

Re: [BUG] haproxy 1.8-last/master-worker/peers

[Willy Tarreau]

Hi Manu,

On Mon, Nov 27, 2017 at 06:21:50PM +0100, Emmanuel Hocdet wrote:
> Hi Willy,
> 
> > Le 18 nov. 2017 à 12:28, Willy Tarreau  a écrit :
> > 
> > Hi Manu,
> > 
> > On Fri, Nov 17, 2017 at 05:14:11PM +0100, Emmanuel Hocdet wrote:
> >> In master-worker mode with peers, old worker never died after a reload 
> >> (kill -USR2).
> >> 
> >> Tested without traffic, with/without threads.
> >> Without peers, no problems.
> > 
> > Thanks for the report. I'm currently working on an issue causing some
> > streams never to end, and it *could* possibly also affect peers. We'll
> > have to try again once I manage to sort this out.
> 
> same issue with 1.8.0.

Then I'll need a reproducer because I couldn't reproduce it.

Thanks,
Willy

Re: possible use-after-free on v1.9-dev0-3-ge78915a4

[Willy Tarreau]

Hello Ricardo,

On Mon, Nov 27, 2017 at 04:33:45PM -0200, Ricardo Nabinger Sanchez wrote:
> Hello,
> 
> While compile-testing 1.9-dev with Clang/LLVM analyzer, it found the
> following (possible) scenario:
> 
> 1- in function cfg_cache_postparser(), when entering the nested loop in
> line 914, cache_ptr is free()ed and redefined to cache (line 918):
> 
>  914 list_for_each_entry(cache, , list) {
>  915 if (!strcmp(cache->id, cache_ptr)) {
>  916 /* there can be only one filter 
> per cache, so we free it there */
>  917 free(cache_ptr);
>  918 cache_ptr = cache;
>  919 break;
>  920 }
>  921 }
> 
> 
> 2- loop is interrupted on the break in line 919;
> 
> 3- if the test in line 923 passes (testing cache_ptr with the pointer
> fcont->conf), ha_alert() function in line 924 will be called and attempt
> to print/dereference the (recently freed) content pointed by
> fconf->conf:
> 
>  923 if (cache_ptr == fconf->conf) {
>  924 ha_alert("Proxy '%s': unable to find the 
> cache '%s' referenced by the filter 'cache'.\n",
>  925  curproxy->id, (char 
> *)fconf->conf);
>  926 err++;
>  927 }

It doesn't try to print the freed pointer, but the "cache" variable since
it's what it was last assigned to. In practice, what was released was the
new pointer attempting to create the new filter, and what it printed is
the one found to conflict with it, so there is no problem here.

Thanks anyway for your report!
Willy

Re: haproxy-1.8.0, sending a email-alert causes 100% cpu usage, FreeBSD 11.1

[Willy Tarreau]

Hi Pieter,

On Mon, Nov 27, 2017 at 09:43:52PM +0100, PiBa-NL wrote:
> Hi List,
> 
> I thought i 'reasonably' tested some of 1.8.0's options.
> Today i put it into 'production' on my secondary cluster node and notice it
> takes 100% cpu...

G.. bad. This sounds like another case of recursive locking.

> I guess i should have tried such a thing last week.

Don't worry, whatever the amount of tests you run, some bugs will always
slip through.

> Anyhow below some gdb and console output.

Very useful, I found it :

process_chk_conn() takes the lock then calls connect_conn_chk() :
  2114  HA_SPIN_LOCK(SERVER_LOCK, >server->lock);
  2137  ret = connect_conn_chk(t);

connect_conn_chk() then calls tcpcheck_main() :
  1548  tcpcheck_main(check);

And this one takes the lock again :
  2598  HA_SPIN_LOCK(SERVER_LOCK, >server->lock);

CCing Emeric as he's the one who covered the checks so he will know best
how to fix it.

In the mean time, if you don't need threads you can rebuild with "USE_THREAD="
to disable them, but I'd rather wait for a fix. Sorry about that, and thaks
for the report.

Willy

[PR] Fix typo

[PR Bot]

Dear list!

Author: CJ Ting 
Number of patches: 1

This is an automated relay of the Github pull request:
   Fix typo

Patch title(s): 
   Fix typo

Link:
   https://github.com/haproxy/haproxy/pull/81

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/81.patch && vi 81.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/81.patch | git am -

Description:


Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

Re[2]: [ANNOUNCE] haproxy-1.8.0

[Aleksandar Lazic]

Hi Willy.

-- Originalnachricht --
Von: "Willy Tarreau" 
An: "Aleksandar Lazic" 
Cc: haproxy@formilux.org
Gesendet: 27.11.2017 23:54:31
Betreff: Re: [ANNOUNCE] haproxy-1.8.0


Hi Aleks,

On Mon, Nov 27, 2017 at 09:18:35PM +, Aleksandar Lazic wrote:
> I'm pleased to announce that haproxy 1.8.0 is now officially 
released!

Amazing ;-)


So after 15 years working on this project you still manage to be 
amazed,

I'm impressed ;-)

You are right I wanted to say "great".

Note to myself: I should not write mails when I'm in passing mood.

Hm time flies, 15 years and still happy to be part of this great 
project.


Thanks to all of us community members and the company behind the project 
;-)


I hope I'm not to sentimental.


As usual the docker image is also updated.

https://hub.docker.com/r/me2digital/haproxy18/


Thank you for maintaining this!
Willy

Regards
Aleks

Re: [ANNOUNCE] haproxy-1.8.0

[Aleksandar Lazic]

Hi.

-- Originalnachricht --
Von: "Willy Tarreau" 
An: haproxy@formilux.org
Gesendet: 26.11.2017 19:57:35
Betreff: [ANNOUNCE] haproxy-1.8.0


Hi all,

After one year of intense development and almost one month of 
debugging,
polishing, and cross-review work trying to prevent our respective 
coworkers
from winning the first bug award, I'm pleased to announce that haproxy 
1.8.0

is now officially released!

Amazing ;-)

As usual the docker image is also updated.

https://hub.docker.com/r/me2digital/haproxy18/

Best regards
Aleks



Since -rc4, a few last user-visible changes were brought :
 - by default the master worker exits if any of its processes dies. 
This
   is done so that when certain processes are dedicated to certain 
tasks,
   we're not left with some features not working anymore. Imagine 
having
   7 SSL offloaders chaining to 1 HTTP frontend, and the last one 
dying,

   you don't want to keep the 7 useless frontends. By quitting, we give
   a chance to a service manager to detect the problem and 
alert/restart

   the service. The behaviour is configurable though.

 - we were not happy with "thread-map" vs "cpu-map", making these 
difficult
   to configure. Now "thread-map" was removed and the feature was 
merged

   into "cpu-map" which also supports process ranges and cpu ranges for
   easier configuration.

 - haproxy can now be built with native systemd support using 
USE_SYSTEMD=1

   and starting it with -Ws (systemd-aware master-worker mode).

 - HTTP/2 will not schedule a graceful connection shutdown anymore when
   seeing a "Connection: close" header in a response. Instead a new 
HTTP
   action "reject" has been implemented to work like its TCP 
counter-part.


 - the HTTP/2 gateway code now properly reassembles split Cookie 
headers,
   as mandated by the specification. Not doing it was causing some 
issues
   with certain application servers, and absolutely needed to be 
addressed

   before claiming that it works.

And here is a high level overview of the new features contributed to 
1.8

(warning, the list is huge) :

 - JSON stats (Simon Horman) : the stats socket's "show stat" and "show 
info"

   output can now be emitted in a structured JSON format which is more
   convenient than CSV for some modern data processing frameworks.

 - server templates (Frédéric Lécaille) : servers can be 
pre-provisionned

   in backends using a simple directive ("server-template"). It is then
   possible to configure them at runtime over the CLI or DNS, making it
   trivial to add/remove servers at run time without restarting. As a 
side
   effect of implementing this, all "server" keywords are now supported 
on
   the "default-server" line and it's possible to disable any of them 
using
   "no-". All settings changed at runtime are present in the 
state

   file so that upon reload no information is lost.

 - dynamic cookies (Olivier Houchard) : a dynamic cookie can be 
generated
   on the fly based on the transport address of a newly added server. 
This
   is important to be able to use server templates in stateful 
environments.


 - per-certificate "bind" configuration (Emmanuel Hocdet) : all the SSL
   specific settings of the "bind" line may now be set per-certificate 
in
   the crtlist file. A common example involves requiring a client cert 
for
   certain domains only and not for others, all of them running on the 
same

   address:port.

 - pipelined and asynchronous SPOE (Christopher Faulet) : it's an 
important
   improvement to the Stream Processing Offload Engine that allows 
requests
   to be streamed over existing connections without having to wait for 
a
   previous response. It significantly increases the message rate and 
reduces
   the need for parallel connections. Two example WAFs were introduced 
as

   contributions to make use of this improvement (mod_security and
   mod_defender).

 - seamless reloads (Olivier Houchard) : in order to work around some 
issues
   faced on Linux causing a few RST to be emitted for incoming 
connections
   during a reload operations despite SO_REUSEPORT being used, it is 
now
   possible for the new haproxy process to connect to the previous one 
and
   to retrieve existing listening sockets so that they are never 
closed. Now
   no connection breakage will be observed during a reload operation 
anymore.


 - PCRE2 support (David Carlier) : this new version of PCRE seems to be
   making its way in some distros, so now we are compatible with it.

 - hard-stop-after (Cyril Bonté) : this new global setting forces old
   processes to quit after a delay consecutive to a soft reload 
operation.
   This is mostly used to avoid an accumulation of old processes in 
some

   environments where idle connections are kept with large timeouts.

 - support for OpenSSL asynchronous crypto engines (Grant Zhang) : this
   allows haproxy to defer the expensive crypto operations to external
   hardware engines. Not only can it 

haproxy-1.8.0, sending a email-alert causes 100% cpu usage, FreeBSD 11.1

[PiBa-NL]

Hi List,

I thought i 'reasonably' tested some of 1.8.0's options.
Today i put it into 'production' on my secondary cluster node and notice 
it takes 100% cpu... I guess i should have tried such a thing last week.
My regular config with 10 frontends and total 13 servers seems to 
startup fine when 'email-alert level' is set to 'emerg' , doesnt need to 
send a mail then..


Anyhow below some gdb and console output.
Config that reproduces it is pretty simple no new features used or anything.
Though the server is 'down' so it is trying to send a mail for that.. 
that never seems to happen though.. no mail is received.


I tried using nokqueu and nopoll, but that did not result in any 
improvement..


Anything else i can provide?

Regards,
PiBa-NL / Pieter

haproxy -f /root/hap.conf -V
[WARNING] 330/204605 (14771) : config : missing timeouts for frontend 
'TestMailFront'.
   | While not properly invalid, you will certainly encounter various 
problems
   | with such a configuration. To fix this, please ensure that all 
following

   | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
[WARNING] 330/204605 (14771) : config : missing timeouts for backend 
'TestMailBack'.
   | While not properly invalid, you will certainly encounter various 
problems
   | with such a configuration. To fix this, please ensure that all 
following

   | timeouts are set to a non-zero value: 'client', 'connect', 'server'.
Note: setting global.maxconn to 2000.
Available polling systems :
 kqueue : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result FAILED
Total: 3 (2 usable), will use kqueue.

Available filters :
    [TRACE] trace
    [COMP] compression
    [SPOE] spoe
Using kqueue() as the polling mechanism.
[WARNING] 330/204608 (14771) : Server TestMailBack/TestServer is DOWN, 
reason: Layer4 timeout, check duration: 2009ms. 0 active and 0 backup 
servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

[ALERT] 330/204608 (14771) : backend 'TestMailBack' has no server available!

Complete configuration that reproduces the issue:

mailers globalmailers
    mailer ex01 192.168.0.40:25
frontend TestMailFront
    bind :88
    default_backend  TestMailBack
backend TestMailBack
    server TestServer 192.168.0.250:80 check
    email-alert mailers            globalmailers
    email-alert level            info
    email-alert from            haproxy@me.local
    email-alert to            m...@me.tld
    email-alert myhostname        pfs


root@:~ # haproxy -vv
HA-Proxy version 1.8.0 2017/11/26
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = freebsd
  CPU = generic
  CC  = cc
  CFLAGS  = -pipe -g -fstack-protector -fno-strict-aliasing 
-fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-Wno-address-of-packed-member -Wno-null-dereference -Wno-unused-label 
-DFREEBSD_PORTS
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_CPU_AFFINITY=1 
USE_ACCEPT4=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_STATIC_PCRE=1 
USE_PCRE_JIT=1


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

Built with network namespace support.
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), 
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")

Built with PCRE version : 8.40 2017-01-11
Running on PCRE version : 8.40 2017-01-11
PCRE library supports JIT : yes
Built with multi-threading support.
Encrypted password support via crypt(3): yes
Built with transparent proxy support using: IP_BINDANY IPV6_BINDANY
Built with Lua version : Lua 5.3.4
Built with OpenSSL version : OpenSSL 1.0.2k-freebsd  26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k-freebsd  26 Jan 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2

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

Available filters :
    [TRACE] trace
    [COMP] compression
    [SPOE] spoe

root@:~ #

root@:~ # /usr/local/bin/gdb --pid 14771
GNU gdb (GDB) 8.0.1 [GDB v8.0.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd11.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" 

RE: Does HAProxy 1.8.0 need new param vs 1.7.9

[Coscend@HAProxy]

Further, we have added the following new parameters in the configuration
before testing 1.8.0 [{I} -Baptiste Assman's article].  Still the pages /
applications are not accessible via 1.8.0.  What obvious thing could we be
missing with 1.8.0 installation/configuration vs. 1.7.9?  Your vectors to
help find a solution would be appreciated.

 

(i)Used systemd: ExecStart -Ws.

OR

global

master-worker

 

(ii)  frontend webapps-frontend

   bind  *:443 name https ssl crt
"$PATH_TO_&_NAME_OF_SSL_CRT_PATH_FILE" alpn h2,http/1.1

 

The OS is CentOS 7.1 and has systemd and system-devel.

 

[I] https://www.haproxy.com/blog/whats-new-haproxy-1-8/

 

Thank you.

 

Sincerely,

 

Hemant K. Sabat

 

Coscend Communications Solutions

  www.Coscend.com 

--

Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education,
Telepresence Services, on the fly.

--

CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail
Messages from Coscend Communications Solutions' posted at:
http://www.Coscend.com/Anchor/Common/Terms_and_Conditions.html

 

 

From: Coscend@Coscend [mailto:haproxy.insig...@coscend.com] 
Sent: Monday, November 27, 2017 12:11 PM
To: haproxy@formilux.org
Subject: Does HAProxy 1.8.0 need new param vs 1.7.9

 

Dear HAProxy community,

 

We have been successfully loading Stats page and other applications via
HAProxy 1.7.9.  We successfully compiled, installed and ran 1.8.0 as a
systemd service.  However, with 1.8.0, we are unable to access the same
stats page or any other application.  We are using the same set of multiple
HAProxy configuration files for both 1.8.0 and 1.7.9.  Ports on firewalls
are open and policies are enabled, as verified by a working v. 1.7.9.

 

No log is being captured by HAProxy during access to these pages /
applications.  Router log gives HAProxy is resetting the request.  The Web
page on browser states "the connection was reset."  

 

Would you be kind enough to provide any vectors on what new configuration
parameter we should add / modify for 1.8.0 (different from 1.7.9)?  

 

Below is haproxy -vv.  Command to start HAProxy:  

CONFIG=

ExecStart=/usr/local/sbin/haproxy -Ws -V -C $CONFIG -f $CONFIG -f
$ -f $ -D -p $PIDFILE 

ExecReload=/usr/local/sbin/haproxy -C $CONFIG -f $CONFIG -f
$BACKENDS_DEFAULT -f $BACKENDS_SECURITY -f $BACKENDS_COSCENDCC -f
$BACKENDS_PRODUCTS -c -q

ExecReload=/bin/kill -USR2 $MAINPID 

KillMode=mixed

Restart=always

Type=forking

WantedBy=multi-user.target

 

Thank you.



HA-Proxy version 1.8.0 2017/11/26

Copyright 2000-2017 Willy Tarreau  >

 

Build options :

  TARGET  = linux2628

  CPU = native

  CC  = gcc

  CFLAGS  = -m64 -march=x86-64 -O2 -march=native -g -fno-strict-aliasing
-Wdeclaration-after-statement -fwrapv -Wno-unused-label

  OPTIONS = USE_LIBCRYPT=1 USE_CRYPT_H=1 USE_GETADDRINFO=1 USE_ZLIB=1
USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_SYSTEMD=1 USE_PCRE=1
USE_PCRE_JIT=1 USE_TFO=1 USE_NS=1

 

Default settings :

  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

 

Built with OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017

Running on OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017

OpenSSL library supports TLS extensions : yes

OpenSSL library supports SNI : yes

OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2

Built with Lua version : Lua 5.3.1

Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND

Encrypted password support via crypt(3): yes

Built with multi-threading support.

Built with PCRE version : 8.32 2012-11-30

Running on PCRE version : 8.32 2012-11-30

PCRE library supports JIT : yes

Built with zlib version : 1.2.7

Running on zlib version : 1.2.7

Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")

Built with network namespace support.

 

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.

 

Available filters :

[SPOE] spoe

[COMP] compression

  [TRACE] trace

 

Sincerely,

 

Hemant K. Sabat

 

Coscend Communications Solutions

  www.Coscend.com 

--

Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education,
Telepresence Services, on the fly.

--

CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail
Messages from Coscend Communications Solutions' posted at:
http://www.Coscend.com/Anchor/Common/Terms_and_Conditions.html

 

 

 

  

RE: HAProxy 1.7.9 Not Capturing Application Session Cookie

[Coscend@HAProxy]

Hello Moemen,



Thank you and very thoughtful of you to educate us on how HAProxy handles
Websockets and logs cookies.  Guidance such as these have helped us grow
from a rank startup to offer SLA-based healthcare services to disadvantaged
remote areas (where there are no hospitals/clinics) through our Web-based
products.  These patients indirectly benefit from your guidance, besides us
who benefit directly.





Without the cookie in the request of the login page, our users are unable to
login into the product.  Going by your guidance, it would be advisable to
insert the JSESSIONID received in server response back into the client
request.  This will help our product server authenticate users to login.
Are we on the right path?

https://www.haproxy.com/documentation/aloha/8-5/haproxy/traffic-capture/  à
Insert a cookie if none presented by the client



If we need to course correct, please advise alternatives.



As advised, we are using for Websockets

backend subdomain_cc

timeout tunnel  3600s




Thank you.



Sincerely,



Hemant K. Sabat



Coscend Communications Solutions

  www.Coscend.com

--

Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education,
Telepresence Services, on the fly…

--

CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail
Messages from Coscend Communications Solutions' posted at:

http://www.Coscend.com/Anchor/Common/Terms_and_Conditions.html







From: Moemen MHEDHBI [mailto:mmhed...@haproxy.com]
Sent: Monday, November 27, 2017 1:15 PM
To: haproxy@formilux.org
Subject: Re: HAProxy 1.7.9 Not Capturing Application Session Cookie



Hi Hemant,

When using websocket, HAProxy will switch to tunnel mode whenever it detects
the Connection: Upgrade header.

Tunnel mode means that only the first request and response are processed and
logged and everything else will be forwarded with no analysis, I think this
is what happens with your 3.3.2 version. Normally you will only be able to
see the cookie in the log if it is present in the request initiating the
websocket connection.

On the other hand, with your 3.3.0 version, HAProxy works in the default
keep-alive-mode where every request is processed and logged.

++



On 24/11/2017 23:30, Coscend@Coscend wrote:

Hello Moemen,



Thank you for your encouraging insights.  Below is the information you
asked.



>>Also you mentioned  the application extensively uses Websockets. Is it
only 3.3.2 using websockets ? if that is the case this may be a good lead
since HAProxy does not handle websockets traffic in the same way as it does
for normal http traffic.



Yes, only v. 3.3.2 uses Websockets.  (v. 3.3.0 did not use Websockets and
access via HAProxy was seamless.)



Could you please educate us on what configuration changes we need to do for
Websockets traffic (vs. HTTP traffic)?



>>In your first post you said that it is working for 3.3.0 but not 3.3.2,
then maybe this is an application issue. Are you sure 3.3.2 does sent the
JSESSIONID.



Yes.  Please see below JSESSIONID in the login page URL loaded, HAProxy logs
and product log.  Is there any other way to verify whether the v. 3.3.2 is
publishing JSESSIONID?



Through HAProxy, login page URL loads with a JSESSIONID:

https://coscend.com/CoscendCC.Test/signin;jsessionid=E916C54BB7A9EA30E3EC902
1AEF4CB79



HAProxy log has the same JSESSIONID – ONLY in the first two lines -- in
server response:

Nov 23 01:29:59 localhost haproxy[6585]: 192.168.100.152:60014
[23/Nov/2017:01:29:59.588] webapps-frontend~ subdomain_cc/CoscendCC.Test
0/0/0/10/10 302 343 - JSESSIONID=E916C54BB7A9EA30E3EC9021AEF4CB79 
1/1/0/0/0 0/0 {|coscend.com||}
{||0|no-cache||./signin;jsessionid=no-cache|} "GET
/CoscendCC.Test/ HTTP/1.1"

Nov 23 01:29:59 localhost haproxy[6585]: 192.168.100.152:60014
[23/Nov/2017:01:29:59.588] webapps-frontend~ subdomain_cc/CoscendCC.Test
0/0/0/10/10 302 343 - JSESSIONID=E916C54BB7A9EA30E3EC9021AEF4CB79 
1/1/0/0/0 0/0 {|coscend.com||}
{||0|no-cache||./signin;jsessionid=no-cache|} "GET
/CoscendCC.Test/ HTTP/1.1"



Product log:  DEBUG 11-24 15:10:26.951 1341302 145 MainPage
[105-6083-exec-6] - WebSocketBehavior::onConnect [uid:
ded43405-f081-4a04-be0c-b92dd510a94a, session:
6015021798DAE92F2F989D8ED5E0B9DE, key:

org.apache.wicket.protocol.ws.api.registry.PageIdKey@0]





We have also tried the following new configuration, but HAProxy still does
not capture request cookie or response cookie after first two lines.  Thank
you.



HAProxy.cfg

--

frontend webapps-frontend

bind  *:80 name http

bind  *:443 name https 

Re: HAProxy 1.7.9 Not Capturing Application Session Cookie

[Moemen MHEDHBI]

Hi Hemant,

When using websocket, HAProxy will switch to tunnel mode whenever it
detects the Connection: Upgrade header.

Tunnel mode means that only the first request and response are processed
and logged and everything else will be forwarded with no analysis, I
think this is what happens with your 3.3.2 version. Normally you will
only be able to see the cookie in the log if it is present in the
request initiating the websocket connection.

On the other hand, with your 3.3.0 version, HAProxy works in the default
keep-alive-mode where every request is processed and logged.

++


On 24/11/2017 23:30, Coscend@Coscend wrote:
>
> Hello Moemen,
>
>  
>
> Thank you for your encouraging insights.  Below is the information you
> asked. 
>
>  
>
> >>Also you mentioned  the application extensively uses Websockets. Is it
> only 3.3.2 using websockets ? if that is the case this may be a good
> lead since HAProxy does not handle websockets traffic in the same way
> as it does for normal http traffic.
>
>  
>
> Yes, only v. 3.3.2 uses Websockets.  (v. 3.3.0 did not use Websockets
> and access via HAProxy was seamless.)
>
>  
>
> Could you please educate us on what configuration changes we need to
> do for Websockets traffic (vs. HTTP traffic)?
>
>  
>
> >>In your first post you said that it is working for 3.3.0 but not 3.3.2,
> then maybe this is an application issue. Are you sure 3.3.2 does sent
> the JSESSIONID.
>
>  
>
> Yes.  Please see below JSESSIONID in the login page URL loaded,
> HAProxy logs and product log.  Is there any other way to verify
> whether the v. 3.3.2 is publishing JSESSIONID?
>
>  
>
> Through HAProxy, login page URL loads with a JSESSIONID: 
> https://coscend.com/CoscendCC.Test/signin;jsessionid=E916C54BB7A9EA30E3EC9021AEF4CB79
>
>  
>
> HAProxy log has the same JSESSIONID – ONLY in the first two lines --
> in server response:
>
> Nov 23 01:29:59 localhost haproxy[6585]: 192.168.100.152:60014
> [23/Nov/2017:01:29:59.588] webapps-frontend~
> subdomain_cc/CoscendCC.Test 0/0/0/10/10 302 343 -
> JSESSIONID=E916C54BB7A9EA30E3EC9021AEF4CB79  1/1/0/0/0 0/0
> {|coscend.com||}
> {||0|no-cache||./signin;jsessionid=no-cache|} "GET
> /CoscendCC.Test/ HTTP/1.1"
>
> Nov 23 01:29:59 localhost haproxy[6585]: 192.168.100.152:60014
> [23/Nov/2017:01:29:59.588] webapps-frontend~
> subdomain_cc/CoscendCC.Test 0/0/0/10/10 302 343 -
> JSESSIONID=E916C54BB7A9EA30E3EC9021AEF4CB79  1/1/0/0/0 0/0
> {|coscend.com||}
> {||0|no-cache||./signin;jsessionid=no-cache|} "GET
> /CoscendCC.Test/ HTTP/1.1"
>
>  
>
> Product log:  DEBUG 11-24 15:10:26.951 1341302 145 MainPage
> [105-6083-exec-6] - WebSocketBehavior::onConnect [uid:
> ded43405-f081-4a04-be0c-b92dd510a94a, session:
> 6015021798DAE92F2F989D8ED5E0B9DE, key:
> org.apache.wicket.protocol.ws.api.registry.PageIdKey@0]
>
>  
>
>  
>
> We have also tried the following new configuration, but HAProxy still
> does not capture request cookie or response cookie after first two
> lines.  Thank you.
>
>  
>
> HAProxy.cfg
>
> --
>
> frontend webapps-frontend
>
>     bind  *:80 name http 
>
> bind  *:443 name https ssl crt "$SSL_CRT_FILE"
>
>     option    forwardfor  
>
> http-request set-header X-Forwarded-Port %[dst_port] 
>
> http-request set-header X-Forwarded-Proto https if { ssl_fc }   
>
> option    httplog
>
> log   global  
>
> option    log-separate-errors  
>
> …
>
>     capture cookie JSESSIONID len 63   
>
>     capture request  header Host len 64
>
> …
>
>     capture response header Server len 20  
>
> …
>
>     acls…
>
>     acl host_coscend_http    req.hdr(Host) coscend.com
>
>     acl host_coscend_https    req.hdr(Host) coscend.com
>
>     …
>
>     use_backend subdomain_cc …
>
>  
>
> backend subdomain_cc
>
>     timeout tunnel 
> 3600s 
>  
>
>
>     option
> http-buffer-request   
>  
>    
>
> http-request set-header Host bk.coscend.local:6080
>
>     http-request set-header Origin "bk.coscend.local:6080" 
>    
>
> stick on urlp(JSESSIONID)
>
>     stick on urlp(jsessionid)
>
>     stick on cookie(JSESSIONID)
>
>     stick store-response cookie(JSESSIONID)
>
>     stick store-response res.cook(JSESSIONID)
>
>     #stick match req.cook(JSESSIONID)
>
> stick store-request req.cook(JSESSIONID)
>
>     stick store-request cookie(JSESSIONID)
>
>     stick store-request urlp(JSESSIONID)
>
>     stick store-request urlp(jsessionid)
>
>     acl hdr_location res.hdr(Location) -m found
>
>     rspirep ^(Location:)\
> http://bk.coscend.local:6080/CoscendCC.Test/(.*)$
> 

possible use-after-free on v1.9-dev0-3-ge78915a4

[Ricardo Nabinger Sanchez]

Hello,

While compile-testing 1.9-dev with Clang/LLVM analyzer, it found the
following (possible) scenario:

1- in function cfg_cache_postparser(), when entering the nested loop in
line 914, cache_ptr is free()ed and redefined to cache (line 918):

 914 list_for_each_entry(cache, , list) {
 915 if (!strcmp(cache->id, cache_ptr)) {
 916 /* there can be only one filter 
per cache, so we free it there */
 917 free(cache_ptr);
 918 cache_ptr = cache;
 919 break;
 920 }
 921 }


2- loop is interrupted on the break in line 919;

3- if the test in line 923 passes (testing cache_ptr with the pointer
fcont->conf), ha_alert() function in line 924 will be called and attempt
to print/dereference the (recently freed) content pointed by
fconf->conf:

 923 if (cache_ptr == fconf->conf) {
 924 ha_alert("Proxy '%s': unable to find the 
cache '%s' referenced by the filter 'cache'.\n",
 925  curproxy->id, (char 
*)fconf->conf);
 926 err++;
 927 }

I'm not sure how realistic this might be (especially to exploit), but it
feels worthy of reporting.

Cheers,

-- 
Ricardo Nabinger Sanchez http://www.taghos.com.br/

Does HAProxy 1.8.0 need new param vs 1.7.9

[Coscend@Coscend]

Dear HAProxy community,

 

We have been successfully loading Stats page and other applications via
HAProxy 1.7.9.  We successfully compiled, installed and ran 1.8.0 as a
systemd service.  However, with 1.8.0, we are unable to access the same
stats page or any other application.  We are using the same set of multiple
HAProxy configuration files for both 1.8.0 and 1.7.9.  Ports on firewalls
are open and policies are enabled, as verified by a working v. 1.7.9.

 

No log is being captured by HAProxy during access to these pages /
applications.  Router log gives HAProxy is resetting the request.  The Web
page on browser states "the connection was reset."  

 

Would you be kind enough to provide any vectors on what new configuration
parameter we should add / modify for 1.8.0 (different from 1.7.9)?  

 

Below is haproxy -vv.  Command to start HAProxy:  

CONFIG=

ExecStart=/usr/local/sbin/haproxy -Ws -V -C $CONFIG -f $CONFIG -f
$ -f $ -D -p $PIDFILE 

ExecReload=/usr/local/sbin/haproxy -C $CONFIG -f $CONFIG -f
$BACKENDS_DEFAULT -f $BACKENDS_SECURITY -f $BACKENDS_COSCENDCC -f
$BACKENDS_PRODUCTS -c -q

ExecReload=/bin/kill -USR2 $MAINPID 

KillMode=mixed

Restart=always

Type=forking

WantedBy=multi-user.target

 

Thank you.



HA-Proxy version 1.8.0 2017/11/26

Copyright 2000-2017 Willy Tarreau 

 

Build options :

  TARGET  = linux2628

  CPU = native

  CC  = gcc

  CFLAGS  = -m64 -march=x86-64 -O2 -march=native -g -fno-strict-aliasing
-Wdeclaration-after-statement -fwrapv -Wno-unused-label

  OPTIONS = USE_LIBCRYPT=1 USE_CRYPT_H=1 USE_GETADDRINFO=1 USE_ZLIB=1
USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_SYSTEMD=1 USE_PCRE=1
USE_PCRE_JIT=1 USE_TFO=1 USE_NS=1

 

Default settings :

  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

 

Built with OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017

Running on OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017

OpenSSL library supports TLS extensions : yes

OpenSSL library supports SNI : yes

OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2

Built with Lua version : Lua 5.3.1

Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND

Encrypted password support via crypt(3): yes

Built with multi-threading support.

Built with PCRE version : 8.32 2012-11-30

Running on PCRE version : 8.32 2012-11-30

PCRE library supports JIT : yes

Built with zlib version : 1.2.7

Running on zlib version : 1.2.7

Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")

Built with network namespace support.

 

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.

 

Available filters :

[SPOE] spoe

[COMP] compression

  [TRACE] trace

 

Sincerely,

 

Hemant K. Sabat

 

Coscend Communications Solutions

  www.Coscend.com 

--

Real-time, Interactive Video Collaboration, Tele-healthcare, Tele-education,
Telepresence Services, on the fly.

--

CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail
Messages from Coscend Communications Solutions' posted at:

http://www.Coscend.com/Anchor/Common/Terms_and_Conditions.html

 

 



---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: [BUG] haproxy 1.8-last/master-worker/peers

[Emmanuel Hocdet]

Hi Willy,

> Le 18 nov. 2017 à 12:28, Willy Tarreau  a écrit :
> 
> Hi Manu,
> 
> On Fri, Nov 17, 2017 at 05:14:11PM +0100, Emmanuel Hocdet wrote:
>> In master-worker mode with peers, old worker never died after a reload (kill 
>> -USR2).
>> 
>> Tested without traffic, with/without threads.
>> Without peers, no problems.
> 
> Thanks for the report. I'm currently working on an issue causing some
> streams never to end, and it *could* possibly also affect peers. We'll
> have to try again once I manage to sort this out.

same issue with 1.8.0.

++
Manu

Re: [PATCH] BUG/MINOR: ssl: fix CO_FL_EARLY_DATA removal with http mode

[Emmanuel Hocdet]

> Le 27 nov. 2017 à 17:52, Olivier Houchard  a écrit :
> 
> Hi Emmanuel,
> 
> On Mon, Nov 27, 2017 at 05:17:54PM +0100, Emmanuel Hocdet wrote:
>> 
>> Hi,
>> 
>> This patch fix CO_FL_EARLY_DATA removal to have correct ssl_fc_has_early
>> reporting. It work for 'mode http'.
>> 
>> It does not fix ssl_fc_has_early for 'mode tcp'. In this mode 
>> CO_FL_EARLY_DATA
>> should not be removed if early data was accepted.
>> It is possible to check MODE_TCP in mux_pt_recv? Or there is another way of 
>> address this?
>> 
> 

Hi Olivier,

> The first patch seems fine.
> The second breaks wait-for-handshake for me, I guess because recv() is called
In my tests, wake remove the flag before recv (and ssl_fc_has_early call)

> before wake(), and so the flag is removed before that code in 
> stream_interface.c :
>   /* If we had early data, and the handshake ended, then
>* we can remove the flag, and attempt to wake the task up,
>* in the event there's an analyser waiting for the end of
>* the handshake.
>*/
>   if ((conn->flags & (CO_FL_EARLY_DATA | CO_FL_EARLY_SSL_HS)) == 
> CO_FL_EARLY_DATA) {
>   task_wakeup(si_task(si), TASK_WOKEN_MSG);
>   }
> So the stream task is never woken up.
> Maybe the best is to add a new flag per conn_stream, CS_FL_WAITING_FOR_HS or
> something, instead of relying on CO_FL_EARLY_DATA.
> I think I'm going to do something like that.

I think it's a good idea, two different things to deal with one tag.

> That still doesn't help with your problem with TCP mode, though. I still want
> the CO_FL_EARLY_DATA to be removed after the handshake, so that we don't
> add the "Early-Data: 1" header if it is not needed. But it just occured
> to me that I can easily fix that by adding the header, not only if 
> CO_FL_EARLY_DATA is set, but if CO_FL_EARLY_SSL_HS or CO_FL_SSL_WAIT_HS is 
> set.
> That way we will both be happy :)

Indeed :)
Thanks!

Manu

Re: [PATCH] BUG/MINOR: ssl: fix CO_FL_EARLY_DATA removal with http mode

[Olivier Houchard]

Hi Emmanuel,

On Mon, Nov 27, 2017 at 05:17:54PM +0100, Emmanuel Hocdet wrote:
> 
> Hi,
> 
> This patch fix CO_FL_EARLY_DATA removal to have correct ssl_fc_has_early
> reporting. It work for 'mode http'.
> 
> It does not fix ssl_fc_has_early for 'mode tcp'. In this mode CO_FL_EARLY_DATA
> should not be removed if early data was accepted.
> It is possible to check MODE_TCP in mux_pt_recv? Or there is another way of 
> address this?
> 

The first patch seems fine.
The second breaks wait-for-handshake for me, I guess because recv() is called
before wake(), and so the flag is removed before that code in 
stream_interface.c :
/* If we had early data, and the handshake ended, then
 * we can remove the flag, and attempt to wake the task up,
 * in the event there's an analyser waiting for the end of
 * the handshake.
 */
if ((conn->flags & (CO_FL_EARLY_DATA | CO_FL_EARLY_SSL_HS)) == 
CO_FL_EARLY_DATA) {
task_wakeup(si_task(si), TASK_WOKEN_MSG);
}
So the stream task is never woken up.
Maybe the best is to add a new flag per conn_stream, CS_FL_WAITING_FOR_HS or
something, instead of relying on CO_FL_EARLY_DATA.
I think I'm going to do something like that.
That still doesn't help with your problem with TCP mode, though. I still want
the CO_FL_EARLY_DATA to be removed after the handshake, so that we don't
add the "Early-Data: 1" header if it is not needed. But it just occured
to me that I can easily fix that by adding the header, not only if 
CO_FL_EARLY_DATA is set, but if CO_FL_EARLY_SSL_HS or CO_FL_SSL_WAIT_HS is set.
That way we will both be happy :)

Regards,

Olivier

[PATCH] BUG/MINOR: ssl: fix CO_FL_EARLY_DATA removal with http mode

[Emmanuel Hocdet]

Hi,

This patch fix CO_FL_EARLY_DATA removal to have correct ssl_fc_has_early
reporting. It work for 'mode http'.

It does not fix ssl_fc_has_early for 'mode tcp'. In this mode CO_FL_EARLY_DATA
should not be removed if early data was accepted.
It is possible to check MODE_TCP in mux_pt_recv? Or there is another way of 
address this?

Thanks

++
Manu




0001-BUG-MINOR-ssl-CO_FL_EARLY_DATA-removal-is-managed-by.patch
Description: Binary data


0002-BUG-MINOR-ssl-fix-CO_FL_EARLY_DATA-removal-with-http.patch
Description: Binary data

Re: [ANNOUNCE] haproxy-1.8.0

[Alex Evonosky]

Congratulations!

On Mon, Nov 27, 2017 at 8:41 AM, Arnall  wrote:

> Le 26/11/2017 à 19:57, Willy Tarreau a écrit :
>
>> Hi all,
>>
>> After one year of intense development and almost one month of debugging,
>> polishing, and cross-review work trying to prevent our respective
>> coworkers
>> from winning the first bug award, I'm pleased to announce that haproxy
>> 1.8.0
>> is now officially released!
>>
>
> Congratulations to everyone involved  !
>
> Haproxy is trully a great product.
>
>
>

Link Question

[Jack Russell]

Hi,

I am interested in having a link on your website much like others have on your 
site here;

http://hnpaper.forge.partlab.io/u/flibble

Please could you let me know the costs for this?

Many Thanks,
Jack Russell

Re: [ANNOUNCE] haproxy-1.8.0

[Arnall]

Le 26/11/2017 à 19:57, Willy Tarreau a écrit :

Hi all,

After one year of intense development and almost one month of debugging,
polishing, and cross-review work trying to prevent our respective coworkers
from winning the first bug award, I'm pleased to announce that haproxy 1.8.0
is now officially released!


Congratulations to everyone involved  !

Haproxy is trully a great product.

Re: [PATCH]: BUILD : deviceatlas allow MT support

[Willy TARREAU]

On Mon, Nov 27, 2017 at 12:53:27PM +, David Carlier wrote:
> Following up the 1.8 release, deviceatlas being MT safe, we enable this new
> Haproxy feature from this module.
> 
> Needs to be backported to 1.8 branch.

Thanks very much for testing David, now merged in master an 1.8.

Willy

[PATCH]: BUILD : deviceatlas allow MT support

[David Carlier]

Hi,

Following up the 1.8 release, deviceatlas being MT safe, we enable this new
Haproxy feature from this module.

Needs to be backported to 1.8 branch.

Thanks in advance.

Regards.
From b2e649193e5707244638122d3df04e1224bd060d Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Mon, 27 Nov 2017 11:55:59 +
Subject: [PATCH] BUILD/MINOR: deviceatlas: enable thread support

DeviceAtlas detection being multi-thread safe, we enable the
new thread feature support.
Needs to be backported to 1.8 branch.
---
 src/da.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/da.c b/src/da.c
index 0669cba2..685a79d1 100644
--- a/src/da.c
+++ b/src/da.c
@@ -121,12 +121,6 @@ static int init_deviceatlas(void)
 		size_t atlasimglen;
 		da_status_t status;
 
-		if (global.nbthread > 1) {
-			ha_alert("deviceatlas: multithreading is not supported for now.\n");
-			err_code |= ERR_ALERT | ERR_FATAL;
-			goto out;
-		}
-
 		jsonp = fopen(global_deviceatlas.jsonpath, "r");
 		if (jsonp == 0) {
 			ha_alert("deviceatlas : '%s' json file has invalid path or is not readable.\n",
-- 
2.14.1

Re: [ANNOUNCE] haproxy-1.8.0

[Pavlos Parissis]

On 26/11/2017 07:57 μμ, Willy Tarreau wrote:
> Hi all,
> 
> After one year of intense development and almost one month of debugging,
> polishing, and cross-review work trying to prevent our respective coworkers
> from winning the first bug award, I'm pleased to announce that haproxy 1.8.0
> is now officially released!
> 

Congratulations to everyone involved in releasing HAProxy 1.8 version.

Well done and keep up the hard and good work.

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature

Re: [docs] about master-worker mode

[William Lallemand]

Hi,

On Mon, Nov 27, 2017 at 06:58:06AM -0200, Joao Morais wrote:
> 
> Hi, from nbproc doc[1]: "This requires the 'daemon' mode”, but this is also 
> the way to start more than one worker on master-worker mode, right?
>

You can have several workers with the master-worker in foreground mode, the doc
need to be updated there!
 
> Still on the same doc: "USING MULTIPLE PROCESSES IS HARDER TO DEBUG AND IS 
> REALLY DISCOURAGED”, is this still valid on master-worker? Both "harder to 
> debug" and "is really discouraged" parts.

It depends of your use case, HAProxy doesn't share stick-table, statistics and
can't do peers with nbproc, however you can do that with nbthread!


> From the blog post[2]: "Start the haproxy process with the command line 
> argument -W <# of processes>" - is this <# of procs> correct? Couldn’t use 
> this on the command line.
> 

That's an error, -W doesn't take a process argument, it's only a flag. The
master-worker only simplify the reload and the supervision of HAProxy.

> ~jm
> 
> [1] http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#3.1-nbproc
> [2] https://www.haproxy.com/blog/whats-new-haproxy-1-8/
> 
> 

Thanks for the reports.

-- 
William Lallemand

[docs] about master-worker mode

[Joao Morais]

Hi, from nbproc doc[1]: "This requires the 'daemon' mode”, but this is also the 
way to start more than one worker on master-worker mode, right?

Still on the same doc: "USING MULTIPLE PROCESSES IS HARDER TO DEBUG AND IS 
REALLY DISCOURAGED”, is this still valid on master-worker? Both "harder to 
debug" and "is really discouraged" parts.

From the blog post[2]: "Start the haproxy process with the command line 
argument -W <# of processes>" - is this <# of procs> correct? Couldn’t use this 
on the command line.

~jm

[1] http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#3.1-nbproc
[2] https://www.haproxy.com/blog/whats-new-haproxy-1-8/

Placement On cbsinteractive.com betthelines.com

[ads]

 Hi,

Greetings!

​​
This is Shweta Dubey Freelancer services provider. Current working for
a​ ​client who is interested in buying paid advertising articles
with links on​ ​good finance, Forex, casino, gambling, sports
betting sites (if you allow), news and other relevant sites. So, if you
are interested in selling article placement on sites so please ​send
me your websites URL with price to have an article with my website​
​links.

Looking for a good business relationship.

Other than that b​​eing a freelancer The provided services by me
are:

·Content writing,
·Web Design/HTML/Animation
·SEO, SMM,
·Media Buying,
·Facebook,
·Facebook likes,
·Twitter working,

I have 10 years experience in this field. Currently I am searching
fo​r some more clients. ​​Please let me know if you are interested
in my services.​ ​Looking forward to hearing from you.

​
​

[1.8] tune.ssl.cachesize

[Maciej Zdeb]

Hi,

Thank you for your hard work on HAProxy 1.8 - great job!

I tried to update haproxy from 1.7 on our r machine to 1.8 version
however stumbled upon problem with tune.ssl.cachesize directive.

In 1.7.3 with tune.ssl.cachesize = 1000:

ps aux | grep haproxy
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
haproxy  43863  0.1  0.0 2327496 13052 ?  Ss   08:54   0:00
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -D

Note VSZ is 2327496.

In 1.8.0 with tune.ssl.cachesize = 1000:
[ALERT] 330/085923 (30585) : Unable to allocate SSL session cache.

In 1.8.0 with tune.ssl.cachesize = 300:
ps aux | grep haprox
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
haproxy  34539  0.0  0.4 30342220 163784 ? Ss   09:01   0:00
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -D -p /var/run/haproxy.pid

Note VSZ is 30342220.

In docs i don't see any related change:
http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#3.2-tune.
ssl.cachesize
http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-tune.
ssl.cachesize

What is the proper way to calculate ssl cachesize in 1.8? Is it bug or docs
need update?