On 6/22/18 5:21 PM, William Lallemand wrote:
Well, unfortunately haproxy is a very portable software which compiles with a
huge number of openssl and boringssl versions,
Sure. So are a lot of other apps.
> it's complicated to keep everything clean but any help is welcomed.
Step 1 has been
On 6/22/18 6:14 PM, Lukas Tribus wrote:> configuration, removing old
interfaces. Drop it from your openssl
> configuration, and it will work fine.
>
>> particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)",
might be worth a review
>
> Haproxy 1.8 and -dev works fine with both openssl
Hello,
right, your (second) build issue is caused by the --api=1.1.0
configuration, removing old interfaces. Drop it from your openssl
configuration, and it will work fine.
> particularly with tls1.3-capable openssl 1.1.1 "ComingSoon(tm)", might be
> worth a review
Haproxy 1.8 and -dev works
On Fri, Jun 22, 2018 at 05:04:39PM -0700, PGNet Dev wrote:
> fyi,
>
> all the ssl 'magic' for haproxy appears to be in
>
> src/ssl_sock.c
>
> which references
>
>*Acknowledgement:
>* We'd like to specially thank the Stud project authors for a very
> clean
>*
fyi,
all the ssl 'magic' for haproxy appears to be in
src/ssl_sock.c
which references
*Acknowledgement:
* We'd like to specially thank the Stud project authors for a very
clean
* and well documented code which helped us understand how the
OpenSSL API
On 6/22/18 3:55 PM, Lukas Tribus wrote:
> Hello,
>
>
>
> On Fri, 22 Jun 2018 at 22:09, PGNet Dev wrote:
>>> - share the openssl config line and installation commands
>>
>> gcc --version
>> gcc (SUSE Linux) 8.1.1 20180614 [gcc-8-branch revision 261584]
>> which openssl
>>
Hello,
On Fri, 22 Jun 2018 at 22:09, PGNet Dev wrote:
> > - share the openssl config line and installation commands
>
> gcc --version
> gcc (SUSE Linux) 8.1.1 20180614 [gcc-8-branch revision 261584]
> which openssl
> /usr/local/openssl11/bin/openssl
> openssl version
>
Hi
I am setting up haproxy with keepalived and i need to know if is possible pass
client ip for destination log server using haproxy in tcp mode?
Thanks
Best regards
Daniel
On 6/22/18 12:21 PM, Lukas Tribus wrote:
> - share:
> grep OPENSSL_VERSION_TEXT /usr/include/openssl/opensslv.h
> grep OPENSSL_VERSION_TEXT /usr/local/include/openssl/opensslv.h
> grep OPENSSL_VERSION_TEXT /usr/local/openssl11/include/openssl/opensslv.h
grep OPENSSL_VERSION_TEXT
❦ 22 juin 2018 22:03 +0200, Vincent Bernat :
> if (current_child(exitpid)) {
> ha_alert("Current worker %d exited with code
> %d\n", exitpid, status);
This is a lie, but I don't think it matters much. We could (mentally)
translate "with code
Without this patch, when killing the master process, the SIGTERM
signal is forwarded to all children. Last children will likely exit
with "killed by signal SIGTERM" status which would be converted by an
exit with status 143 of the master process.
With this patch, the master process takes note it
On Fri, Jun 22, 2018 at 08:57:03PM +0200, Vincent Bernat wrote:
> The master process will exit with the status of the last worker. When
> the worker is killed with SIGTERM, it is expected to get 143 as an
> exit status. Therefore, we consider this exit status as normal from a
> systemd point of
Hello,
On Fri, 22 Jun 2018 at 20:45, PGNet Dev wrote:
> with 'your' advised "actual paths", and from Makefile
>
> # OpenSSL is packaged in various forms and with various dependencies.
> # In general -lssl is enough, but on some platforms, -lcrypto may be
> needed,
> #
When using core.msleep in lua, the %Tw metric is a negative value.
For example with the following config:
haproxy.cfg:
global
lua-load /tmp/haproxy.lua
frontend f1
mode http
bind :8000
default_backend b1
log
The master process will exit with the status of the last worker. When
the worker is killed with SIGTERM, it is expected to get 143 as an
exit status. Therefore, we consider this exit status as normal from a
systemd point of view. If it happens when not stopping, the systemd
unit is configured to
Hi,
On 6/22/18 10:57 AM, Lukas Tribus wrote:
> SSL_INC and SSL_LIB expect actual paths, not additional commands.
> Replaces both with ADDLIB. Also you don't need to specify -lssl
> -lcrypt, USE_OPENSSL does not for you.
Then a bit confused by what I'm seeing atm.
With 'my' current, if
Trying to compile current master on OS-X, and get:
gcc -Iinclude -Iebtree -Wall -O0 -g -fno-strict-aliasing
-Wdeclaration-after-statement -fwrapv -fno-strict-overflow
-Wno-address-of-packed-member -Wno-null-dereference
-Wno-unused-label -DTPROXY -DUSE_ZLIB -DENABLE_POLL
Hello,
> make V=1 \
> TARGET=linux2628 \
> USE_SYSTEMD=1 \
> USE_OPENSSL=1 \
> SSL_INC=" -I/usr/local/openssl11/include" \
> SSL_LIB=" -L/usr/local/openssl11/lib64
> -Wl,-rpath,/usr/local/openssl11/lib64" \
> ADDLIB="-ldl -lssl
I've enabled stats on haproxy 1.8.10
With
haproxy.conf
...
listen stats
...
bind 192.0.2.1:1234
...
the non-ssl stats web page is fully accessible/functional.
If I enable ssl for it,
> One possible cause could be pcre-config reporting -I/usr and causing
> -I/usr/inc to be included before the SSL_INC path.
fwiw, here, at my shell/env
pcre-config --libs --libs-posix --libs-cpp --cflags --cflags-posix
-L/usr/local/lib64 -lpcre
> Now to track down what's sourcing that "libpcre.so.1 =>
> /usr/lib64/libpcre.so.1"
looks like it's getting pulled in by libselinux & libsystemd ...
for l in $(ldd ./haproxy | awk '{print $3}')
do
echo -e "LIB: ${l}"
ldd ${l} | grep libpcre
done
LIB: /lib64/libcrypt.so.1
On 6/22/18 7:44 AM, Willy Tarreau wrote:
> Did you try to disable or adjust the PCRE flags as I indicated in
> previous e-mail to see if it's the side effect ?
I have _now_ ... needed a few minutes.
> One possible cause could be pcre-config reporting -I/usr and causing
> -I/usr/inc to be
On Fri, Jun 22, 2018 at 07:03:36AM -0700, PGNet Dev wrote:
> Hi
>
> On 6/21/18 10:50 PM, Willy Tarreau wrote:> Well, first please ensure you're
> building latest fixes and not and old
> > version otherwise you'll expose yourself to all these known and now fixed
> > bugs :
>
> oops, missed that!
Hi,
HAProxy 1.8.10 was released on 2018/06/22. It added 40 new commits
after version 1.8.9.
This version fixes several bugs that were crashing haproxy, when using
http-request set-map with a wrong type or with the cirpherlist capture.
Some deadlocks and crashes were also fixed that were provoked
Hi Tait,
There is a first thing you can do to prevent this from happening, but this
might be complicated to implement.
If you force a backend id in the configuration file, the problem won't
exist anymore...
backend be
server-template srv 5 _http._tcp.srv.tld resolvers dnsserver
Hi
On 6/21/18 10:50 PM, Willy Tarreau wrote:> Well, first please ensure you're
building latest fixes and not and old
> version otherwise you'll expose yourself to all these known and now fixed
> bugs :
oops, missed that! :-/
switching to 'latest' in branch, v1.8.9, still see the same in "-vv"
Hi,
Purpose of this flag is to allow IP address duplication in a backend (on a
per server basis) when the runtime resolver is in operation.
By default, the runtime resolver prevent an IP address being affected to 2
servers when they are resolved by the same hostname.
>From the 4 patches in
On Fri, Jun 22, 2018 at 2:28 PM William Lallemand
wrote:
> The seamless reload only transfers the listeners, the remaining connections
> are
> handled in the leaving process. It would be complicated to handle them in a
> new
> process with a different configuration.
Thanks for the
On Fri, Jun 22, 2018 at 02:41:44PM +0200, Christopher Faulet wrote:
> You're right, removing the thread from all_threads_mask when it exits is a
> good idea. Here a patch to do so.
merged as well, thanks!
Willy
Le 20/06/2018 à 18:29, Willy Tarreau a écrit :
On Wed, Jun 20, 2018 at 04:42:58PM +0200, Christopher Faulet wrote:
When HAProxy is shutting down, it exits the polling loop when there is no jobs
anymore (jobs == 0). When there is no thread, it works pretty well, but when
HAProxy is started with
On Fri, Jun 22, 2018 at 12:03:22PM +0200, William Dauchy wrote:
> On Thu, Jun 21, 2018 at 5:21 PM William Lallemand
> wrote:
> > Once you are sure this is not a bug and that a client is still connected,
> > you
> > could use the keyword 'hard-stop-after' to force a hard stop.
>
> After double
On Thu, Jun 21, 2018 at 5:21 PM William Lallemand
wrote:
> Once you are sure this is not a bug and that a client is still connected, you
> could use the keyword 'hard-stop-after' to force a hard stop.
After double checking some cases, indeed there are still a few
remaining established
On Thu, Jun 07, 2018 at 02:47:01PM +0530, Mihir Shirali wrote:
> Hi Alexander,
>
> I have looked at the link. What I am looking for is an answer to the
> difference between maxsslconn and maxsslrate. The former does not result in
> CPU savings while the latter does.
That's expected :
- the
On Thu, Jun 21, 2018 at 05:20:19PM +0200, William Lallemand wrote:
> I'm waiting a few days for your feedback and we will probably release a new
> 1.8
> version including those fixes.
I've merged it in master now.
Willy
2018-06-22 1:13 GMT+10:00 Baptiste :
>
>
> On Thu, Jun 21, 2018 at 8:53 AM, Igor Cicimov com> wrote:
>
>> Hi Dmitriy,
>>
>> On Thu, Jun 21, 2018 at 12:45 PM, Dmitriy Kuzmin
>> wrote:
>>
>>> Greetings
>>>
>>> I’m using haproxy to load balance readonly queries between redis slaves.
>>> I want to
35 matches
Mail list logo
