Re: Syslog with systemd

❦ 28 février 2018 17:51 +1100, Igor Cicimov  : >> > ​Actually spoke too soon, still have an issue. One of the servers started >> > logging there but then stopped and on the other the file is still empty.​ >> >> Is the issue fixed just by restarting HAProxy or does

Re: Syslog with systemd

On Wed, Feb 28, 2018 at 5:51 PM, Igor Cicimov < ig...@encompasscorporation.com> wrote: > Hi Vincent, > > On Wed, Feb 28, 2018 at 5:14 PM, Vincent Bernat wrote: > >> ❦ 28 février 2018 15:50 +1100, Igor Cicimov < >> ig...@encompasscorporation.com> : >> >> > ​Actually spoke too

Re: Syslog with systemd

Hi Vincent, On Wed, Feb 28, 2018 at 5:14 PM, Vincent Bernat wrote: > ❦ 28 février 2018 15:50 +1100, Igor Cicimov com> : > > > ​Actually spoke too soon, still have an issue. One of the servers started > > logging there but then stopped and on the

Re: Syslog with systemd

❦ 28 février 2018 15:50 +1100, Igor Cicimov  : > ​Actually spoke too soon, still have an issue. One of the servers started > logging there but then stopped and on the other the file is still empty.​ Is the issue fixed just by restarting HAProxy or does it persist

Re: Syslog with systemd

On Wed, Feb 28, 2018 at 3:33 PM, Igor Cicimov < ig...@encompasscorporation.com> wrote: > > > On Wed, Feb 28, 2018 at 3:28 PM, Igor Cicimov com> wrote: > >> Hi all, >> >> I have haproxy 1.7.10-1ppa1~xenial installed on Ubuntu-16.04 and >> struggling to enable

Re: Syslog with systemd

On Wed, Feb 28, 2018 at 3:28 PM, Igor Cicimov < ig...@encompasscorporation.com> wrote: > Hi all, > > I have haproxy 1.7.10-1ppa1~xenial installed on Ubuntu-16.04 and > struggling to enable rsyslog-ing for the service. > > I have rsyslog running and the following haproxy related config: > > # cat

Re: [PATCH] BUG/MINOR: ssl: return alpn string with NULL terminated

On Tue, Feb 27, 2018 at 04:48:18PM +0100, Emmanuel Hocdet wrote: > > Where exactly did you face the problem ? I'm pretty sure that it's this > > specific place which needs to be fixed. > > > Is for make_tlv with PP2_TYPE_ALPN. I will look at this place. OK, thanks for the pointer. But from what

Syslog with systemd

Hi all, I have haproxy 1.7.10-1ppa1~xenial installed on Ubuntu-16.04 and struggling to enable rsyslog-ing for the service. I have rsyslog running and the following haproxy related config: # cat /etc/rsyslog.d/49-haproxy.conf # Create an additional socket in haproxy's chroot in order to allow

Re: [PATCH v2 0/3] Add SystemD's sandboxing options

On 27/02/2018 08:19 μμ, Tim Duesterhus wrote: > Willy, > > okay. I added an additional comment about the nature of those options in > the first commit and then added the various settings in commented out > versions. For reference, these are the settings I add on top of Debian's > default unit

http/2 PUT's without content-length fail to http 1.1 backend

Hi, I use haproxy (1.8.4) with http/2 support in front of a server that speaks http 1.1. This is working great with one exception. Several http/2 client libraries are sending PUT requests without sending the Content-Length header (as it' not strictly needed due to the framing). The http 1.1

Authentication

Good Afternoon, Is there a way for HAProxy to authenticate users or log any behavior? Thanks, Eric Mates

[PATCH v2 1/3] MINOR: systemd: Add section for SystemD sandboxing to unit file

This commit adds a warning for settings that possibly provide better sandboxing and explains their tradeoffs. --- contrib/systemd/haproxy.service.in | 6 ++ 1 file changed, 6 insertions(+) diff --git a/contrib/systemd/haproxy.service.in b/contrib/systemd/haproxy.service.in index

[PATCH v2 3/3] MINOR: systemd: Add SystemD's SystemCallFilter option to the unit file

This option takes away system calls that are unneeded for haproxy's operation and thus is a good defense in depth measure. --- contrib/systemd/haproxy.service.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contrib/systemd/haproxy.service.in b/contrib/systemd/haproxy.service.in index

[PATCH v2 2/3] MINOR: systemd: Add SystemD's Protect*= options to the unit file

While the haproxy workers usually are running chrooted the master process is not. This patch is a pretty safe defense in depth measure to ensure haproxy cannot touch sensitive parts of the file system. ProtectSystem takes non-boolean arguments in newer SystemD versions, but setting those would

[PATCH v2 0/3] Add SystemD's sandboxing options

Willy, okay. I added an additional comment about the nature of those options in the first commit and then added the various settings in commented out versions. For reference, these are the settings I add on top of Debian's default unit file (haproxy 1.8.4 om Debian Stretch) for one of my

Question about an education post on feedjunkie.com

Hello there, On http://feedjunkie.com/item/26303005/Heres how technology is shaping the future of education you are linking to a post about future of education. I'd like to ask if an article I recently published which is about some of these issues would be of any use to you?. You can see all

Re: [PATCH 0/2] Add SystemD's sandboxing options

On Tue, Feb 27, 2018 at 07:14:19PM +0100, Tim Düsterhus wrote: > Willy, > > Am 27.02.2018 um 18:33 schrieb Willy Tarreau: > > I think it could make sense to add such lines as a comment to the existing > > files so that they serve as illustration of what can be done for users who > > want to go

Re: [PATCH 0/2] Add SystemD's sandboxing options

Willy I was about to suggest the comments in file. You get to keep the great ideas but enable simple defaults for all. On Tue, Feb 27, 2018 at 11:33 AM, Willy Tarreau wrote: > On Tue, Feb 27, 2018 at 05:52:22PM +0100, Vincent Bernat wrote: > > >> Tim Duesterhus (2): > > >>

Re: [PATCH 0/2] Add SystemD's sandboxing options

On Tue, Feb 27, 2018 at 05:52:22PM +0100, Vincent Bernat wrote: > >> Tim Duesterhus (2): > >> MINOR: systemd: Add SystemD's Protect*= options to the unit file > >> MINOR: systemd: Add SystemD's SystemCallFilter option to the unit file > > > > I took a look, but my systemd incompetence limited

Re: [PATCH 0/2] Add SystemD's sandboxing options

❦ 27 février 2018 16:00 +0100, Willy Tarreau  : >> I'm running this exact settings on my Debian Stretch machine using haproxy >> 1.8.x, without issues so far. >> >> The first patch could cause issues for users that store their configuration >> in /home or /root, but I consider this

Re: [PATCH 0/2] Add SystemD's sandboxing options

On 27/02/2018 04:00 μμ, Willy Tarreau wrote: > Hi Tim, > > On Thu, Feb 22, 2018 at 03:03:58PM +0100, Tim Duesterhus wrote: >> I'm running this exact settings on my Debian Stretch machine using haproxy >> 1.8.x, without issues so far. >> >> The first patch could cause issues for users that store

Re: [PATCH] BUG/MINOR: ssl: return alpn string with NULL terminated

Hi Willy > Le 27 févr. 2018 à 15:57, Willy Tarreau a écrit : > > Hi Manu, > > On Mon, Feb 26, 2018 at 12:31:13PM +0100, Emmanuel Hocdet wrote: >> >> Hi, >> >> According to openssl documentation: "SSL_get0_alpn_selected() returns >> a pointer to the selected protocol in data with

Re: [PATCH 0/2] Add SystemD's sandboxing options

Hi Tim, On Thu, Feb 22, 2018 at 03:03:58PM +0100, Tim Duesterhus wrote: > I'm running this exact settings on my Debian Stretch machine using haproxy > 1.8.x, without issues so far. > > The first patch could cause issues for users that store their configuration > in /home or /root, but I consider

Re: [PATCH] BUG/MINOR: ssl: return alpn string with NULL terminated

Hi Manu, On Mon, Feb 26, 2018 at 12:31:13PM +0100, Emmanuel Hocdet wrote: > > Hi, > > According to openssl documentation: "SSL_get0_alpn_selected() returns > a pointer to the selected protocol in data with length len. It is not > NUL-terminated". It consern ssl_sock_get_alpn and

Re: [PATCH] BUG/MEDIUM: buffer: Fix bi/bo_putblk in the wrapping case

On Mon, Feb 26, 2018 at 11:00:28AM +0100, Christopher Faulet wrote: > Hi, > > Here are 2 patches to fix bi_putblk and bo_putblk in the wrapping case. > There are 2 patches because the one about bo_putblk must be backported to > haproxy 1.5 and newer versions while the one about bi_putblk must

Re: Haproxy 1.8.4 crashing workers and increased memory usage

Hi Frank, On Fri, Feb 23, 2018 at 12:10:13PM +, Frank Schreuder wrote: > > Well, at least you don't use threads nor lua nor caching nor HTTP/2 so > > it cannot come from any of those we have identified. It could still come > > from openssl however. > > There are some bugfixes marked as