Re: SV: Config will not start on 2.6.1 on Ubuntu 22.04

2022-07-06 Thread Vincent Bernat 
Running apparmor is not a problem per-se. It may be only if there is a 
profile preventing HAProxy to execute something. Try journalctl -k 
--grep haproxy to double-check.


As I am unable to reproduce on a freshly installed Ubuntu VM, can you 
try to reproduce on a VM on your side?


On 7/6/22 23:05, Henning Svane wrote:

Hi Vincent

I have not by my self installed apparmor, but I can see when I run your 
suggested command (journalctl -k | grep haproxy)


It output all, as my server name is haproxyxmail01, but I piped it to a 
file and looked it over and can find no output from haproxy, but can 
find many lines with apparmor.


I have not installed it and until you asked about it, I did not know 
about apparmor.


I have search on apparmor and can see it is standard installed and 
enabled on Ubuntu


Security - AppArmor | Ubuntu 



To your question “What do you mean by "under load"” I mean under boot of 
the server.


So it must be part of the Ubuntu installation.

Here you can see the output from “journalctl -k | grep apparmor”

Jul 05 20:01:34 haproxymail01a kernel: evm: security.apparmor

Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.636:2): apparmor="STATUS" operation="profile_load"


profile="unconfined" name="lsb_release" pid=741 comm="apparmor_parser"

Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.640:3): apparmor="STATUS" operation="profile_load"


profile="unconfined" name="nvidia_modprobe" pid=742 comm="apparmor_parser"

Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.640:4): apparmor="STATUS" operation="profile_load"


profile="unconfined" name="nvidia_modprobe//kmod" pid=742 
comm="apparmor_parser"


Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.648:5): apparmor="STATUS" operation="profile_load"


profile="unconfined" name="/usr/bin/man" pid=745 comm="apparmor_parser"

Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.648:6): apparmor="STATUS" operation="profile_load"


profile="unconfined" name="man_filter" pid=745 comm="apparmor_parser"

Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.648:7): apparmor="STATUS" operation="profile_load"


profile="unconfined" name="man_groff" pid=745 comm="apparmor_parser"

Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.660:8): apparmor="STATUS" operation="profile_load"


profile="unconfined" name="tcpdump" pid=746 comm="apparmor_parser"

Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.660:9): apparmor="STATUS" operation="profile_load"


profile="unconfined" 
name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=744 
comm="apparmor_parser"


Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.660:10): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" 
pid=744 comm="apparmor_parser"


Jul 05 20:01:35 haproxymail01a kernel: audit: type=1400 
audit(1657044095.660:11): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" 
pid=744 comm="apparmor_parser"


But when I run the same command on the old 20.04 I can see apparmor is 
also enabled, and here haproxy works


sudo nano /etc/haproxy/haproxy.cfg

odin@HAProxy02:~$ journalctl -k | grep apparmor

Jul 05 20:54:09 HAProxy02 kernel: evm: security.apparmor

Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.732:2): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="nvidia_modprobe" pid=786 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.732:3): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="nvidia_modprobe//kmod" pid=786 
comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.744:4): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/sbin/tcpdump" pid=787 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.752:5): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/bin/man" pid=790 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.752:6): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="man_filter" pid=790 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.752:7): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="man_groff" pid=790 comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.756:8): apparmor="STATUS" operation="profile_load" 
profile="unconfined" name="/usr/lib/snapd/snap-confine" pid=791 
comm="apparmor_parser"


Jul 05 20:54:10 HAProxy02 kernel: audit: type=1400 
audit(1657047250.756:9):

Re: Config will not start on 2.6.1 on Ubuntu 22.04

2022-07-06 Thread Vincent Bernat 

On 7/6/22 00:37, Henning Svane wrote:

I get under load of haproxy the following problems for all frontends

What do you mean by "under load"?


Here are two of the errors

for frontend FrontEnd_Xmail_L7_IPv4: cannot bind socket (Permission 
denied) for IPv4 number and port


and

for frontend GLOBAL: cannot bind UNIX socket (Permission denied) 
[/run/haproxy/admin.sock]


global

    maxconn 8000

    log /dev/log local0

    log /dev/log local1 notice

    chroot /var/lib/haproxy

    stats socket /run/haproxy/admin.sock mode 660 level admin 
expose-fd listeners


    stats timeout 30s

    user haproxy

    group haproxy

    daemon

I have compared folder permission /run/haproxy on Ubuntu 20.04.4 with 
Ubuntu 22.04 and the permission looks like this for both.


 [/run/haproxy/admin.sock have these permission

drwxrwsr-x  2 haproxy haproxy   40 Jul  5 20:01 haproxy

I have tried your configuration on a freshly installed Ubuntu 22.04 and 
didn't run into any issue. Are you using apparmor? `journalctl -k | grep 
haproxy` may give a hint if you have a profile for it (not shipped by 
the package nor Ubuntu as far as I can see).

Re: Thoughts on QUIC/HTTP3

2022-07-06 Thread Илья Шипицин 
ср, 6 июл. 2022 г. в 19:11, Shawn Heisey :

> On 5/31/22 08:16, Amaury Denoyelle wrote:
> > Thanks for your continuing your journey on HTTP/3 :)
>
> Yesterday I pulled down the haproxy 2.6 and quictls git repos. The
> branch for quictls was openssl-3.0.4+quic.  I built and installed
> quictls and then haproxy.
>
> This combination is working better than previous combinations.  It does
> look like some of my sites are still having issues on http3, but
> roundcube webmail is working very well, and that was one of the sites
> where I had a LOT of trouble before.
>
> A note for you, which you may already know:  If the openssl-3.0.5+quic
> branch of quictls is installed instead of earlier 3.0.x releases, then
> haproxy will not compile.
>

haproxy is built in CI against latest quictls, for example quictls-3.0.5

https://github.com/haproxy/haproxy/runs/721404?check_suite_focus=true

please open an issue on github with failure details, no known build
failures so far



>
> Thanks,
> Shawn
>
>
>

Re: Thoughts on QUIC/HTTP3

2022-07-06 Thread Shawn Heisey 

On 5/31/22 08:16, Amaury Denoyelle wrote:
Thanks for your continuing your journey on HTTP/3 :) 


Yesterday I pulled down the haproxy 2.6 and quictls git repos. The 
branch for quictls was openssl-3.0.4+quic.  I built and installed 
quictls and then haproxy.


This combination is working better than previous combinations.  It does 
look like some of my sites are still having issues on http3, but 
roundcube webmail is working very well, and that was one of the sites 
where I had a LOT of trouble before.


A note for you, which you may already know:  If the openssl-3.0.5+quic 
branch of quictls is installed instead of earlier 3.0.x releases, then 
haproxy will not compile.


Thanks,
Shawn

Re: Issue - consecutive early-hint defined with "if" condition

2022-07-06 Thread Christopher Faulet 

Le 7/4/22 à 11:19, Christopher Faulet a écrit :

Le 6/30/22 à 11:47, Krzysztof Kozłowski a écrit :

Hi,

I’m struggling with consecutive early-hint statements defined with if condition.

Considering below configuration:

http-request early-hint Link ">; rel="preload"; as="style"" if { path -i -m
beg /test1 }
http-request early-hint Link ">; rel="preload"; as="style"" if { path -i -m
beg /test2 }

I’m not getting HTTP 103 response to 2nd statement.
Response I’m getting with above config:

example.com/test1  response: HTTP/2 103 + HTTP/2 200
example.com/test2  response: HTTP/2 200

However if I add some dummy statement in between those early-hints like this:

http-request early-hint Link ">; rel="preload"; as="style"" if { path -i -m
beg /test1 }
http-request set-header X-Test "test-request"
http-request early-hint Link ">; rel="preload"; as="style"" if { path -i -m
beg /test2 }

I’m receiving HTTP 103 response to both statements as expected.
Response I’m getting with above config:

example.com/test1  response: HTTP/2 103 + HTTP/2 200
example.com/test2  response: HTTP/2 103 + HTTP/2 200

It looks like an issue with parsing early-hint statements which are defined with
"if” statement.

It’s my first message sent to this mailing list - so please excuse me if I miss
any information required to properly identify the problem. If I’m missing
anything - please do let me know.
I would appreciate any help here.

I’m using HAProxy version 2.4.15-7782e23



Thanks ! Indeed, I can confirm the issue. I'll try to fix it soon.



Hi,

It should be fixed now in 2.7-DEV but not backported yet. The commit:

  http://git.haproxy.org/?p=haproxy.git;a=commit;h=4c3d3d2

Thanks !
--
Christopher Faulet