Re: [*EXT*] Re: Public-facing haproxy : recommandation about headers
Thanks Tristan.
So typically I’d say to add to every single http frontend:
http-request set-header X-Forwarded-For %[src]
http-request set-header X-Forwarded-Host %[hdr(Host)]
http-request set-header X-Forwarded-Proto %[ssl_fc,iif(https,http)]
http-request set-header Forwarded
"by=${HOSTNAME};for=%[src];host=%[hdr(Host)];proto=%[ssl_fc,iif(https,http)]"
Almost what I already did :)
What about using %[hdr(host,1)] to forcefully use the first Host header if
multiple headers are sent ?
Ionel
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Public-facing haproxy : recommandation about headers
Hi all, Regarding a public facing haproxy, what would you recommend about headers like X-Forwarded-* and Forwarded ? Delete them with http-request del-header ? Replace them with http-request set-header ? Do the options forwardfor and forwarded behave like a set-header or a add-header directive ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Opinions desired on HTTP/2 config simplification
Hi Willy, Agree with that. However, maybe a "common H2 troubleshooting guide" should be provided so options like h2-workaround-bogus-websocket-clients will be highlighted if any trouble arise. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Willy Tarreau" À: "haproxy" Envoyé: Samedi 15 Avril 2023 11:32:49 Objet: [*EXT*] Opinions desired on HTTP/2 config simplification Hi everyone, I was discussing with Tristan a few hours ago about the widespread deployment of H2 and H3, with Cloudflare showing that H1 only accounts for less than 7% of their traffic and H3 getting close to 30% [1], and the fact that on the opposite yesterday I heard someone say "we still have not tried H2, so H3..." (!). Tristan said something along the lines of "if only proxies would enable it by default by now", which resonated to me like when we decided to switch some defaults on (keep-alive, http-reuse, threads, etc). And it's true that at the beginning there was not even a question about enabling H2 by default on the edge, but nowadays it's as reliable as H1 and used by virtually everyone, yet it still requires admins to know about this TLS-specific extension called "ALPN" and the exact syntax of its declaration, in order to enable H2 over TLS, while it's already on by default for clear traffic. Thus you're seeing me coming with my question: does anyone have any objection against turning "alpn h2,http/1.1" on by default for HTTP frontends, and "alpn h3" by default for QUIC frontends, and have a new "no-alpn" option to explicitly turn off ALPN negotiation on HTTP frontends e.g. for debugging ? This would mean that it would no longer be necessary to know the ALPN strings to configure these protocols. I have not looked at the code but I think it should not be too difficult. ALPN is always driven by the client anyway so the option states what we do with it when it's presented, thus it will not make anything magically fail. And if we change this default, do you prefer that we do it for 2.8 that will be an LTS release and most likely to be shipped with next year's LTS distros, or do you prefer that we skip this one and start with 2.9, hence postpone to LTS distros of 2026 ? Even if I wouldn't share my feelings, some would consider that I'm trying to influence their opinion, so I'll share them anyway :-) I think that with the status change from "experimental-but-supported" to "production" for QUIC in 2.8, having to manually and explicitly deal with 3 HTTP versions in modern configs while the default (h1) only corresponds to 7% of what clients prefer is probably an indicator that it's the right moment to simplify these a little bit. But I'm open to any argument in any direction. It would be nice to be able to decide (and implement a change if needed) before next week's dev8, so that it leaves some time to collect feedback before end of May, so please voice in! Thanks! Willy [1] https://radar.cloudflare.com/adoption-and-usage -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] RE: [ANNOUNCE] haproxy-2.4.22
Hi Marc, I guess Vincent choose to use a -2 tag so that users who hold their package on minor version will still get the update. Ionel - Mail original - De: "Marc Gebauer" À: "haproxy" Envoyé: Mardi 14 Février 2023 17:44:49 Objet: [*EXT*] RE: [ANNOUNCE] haproxy-2.4.22 Hello together, we use /etc/apt/sources.list.d/haproxy.list deb http://haproxy.debian.net bullseye-backports-2.4 main and apt list --upgradable shows: Listing... Done haproxy/bullseye-backports-2.4 2.4.21-2~bpo11+1 amd64 [upgradable from: 2.4.21-1~bpo11+1] is this the recommend package to use for Debian (because of the version-number 2.4.21 instead of 2.4.22) or need we to wait for repo to be synced? Greetings, Marc > -Original Message- > From: Willy Tarreau > Sent: Tuesday, February 14, 2023 5:15 PM > To: haproxy@formilux.org > Subject: [ANNOUNCE] haproxy-2.4.22 > > Hi, > > HAProxy 2.4.22 was released on 2023/02/14. It added 11 new commits after > version 2.4.21. > > The main reason for this release today is the availability of a fix for the > vulnerability > explained in the other thread (CVE-2023-25725). > > In addition, this version addresses the following issues: > > - a regression from a previous fix that caused some server-side > connection not to expire if some unsent data are blocked in the > request channel. > > - a 13-years old issue with the expiration of old entries in stick- > tables that slows down eviction at every timer period rollover > (49.7 days), making the table size and memory usage grow for a > while until all of them were either refreshed or expired. I'm > still puzzled that 3 users apparently noticed it at the same time > around last rollover on Jan 30th. > > - a bug in the SSL cache eviction that affected WolfSSL was fixed, but > it's unclear if it could affect other libs (openssl was apparently not > due to fixed-size records) > > - a warning will be emitted when a crt-list line is malformed. > > - minor doc fixes > > The changes are intentionally limited so that all users of 2.4.21 and older > can > update without taking risks. > > Please find the usual URLs below : >Site index : https://www.haproxy.org/ >Documentation: https://docs.haproxy.org/ >Wiki : https://github.com/haproxy/wiki/wiki >Discourse: https://discourse.haproxy.org/ >Slack channel: https://slack.haproxy.org/ >Issue tracker: https://github.com/haproxy/haproxy/issues >Sources : https://www.haproxy.org/download/20230214-cve-2023- > 25725/src/ >Git repository : https://git.haproxy.org/git/haproxy-20230214-cve-2023- > 25725.git/ >Git Web browsing : https://git.haproxy.org/?p=haproxy-20230214-cve-2023- > 25725.git >Changelog: https://www.haproxy.org/download/20230214-cve-2023- > 25725/src/CHANGELOG >Dataplane API: > https://github.com/haproxytech/dataplaneapi/releases/latest >Pending bugs : https://www.haproxy.org/l/pending-bugs >Reviewed bugs: https://www.haproxy.org/l/reviewed-bugs >Code reports : https://www.haproxy.org/l/code-reports >Latest builds: https://www.haproxy.org/l/dev-packages > > Willy > --- > Complete changelog : > Aleksey Ponomaryov (1): > BUG/MEDIUM: stick-table: do not leave entries in end of window during > purge > > Aurelien DARRAGON (3): > BUG/MINOR: fcgi-app: prevent 'use-fcgi-app' in default section > DOC: config: fix option spop-check proxy compatibility > DOC: config: 'http-send-name-header' option may be used in default > section > > Christopher Faulet (1): > BUG/MEDIUM: stconn: Schedule a shutw on shutr if data must be sent first > > William Lallemand (3): > BUG/MEDIUM: ssl: wrong eviction from the session cache tree > BUG/MINOR: ssl/crt-list: warn when a line is malformated > CI: github: don't warn on deprecated openssl functions on windows > > Willy Tarreau (3): > BUG/MEDIUM: cache: use the correct time reference when comparing dates > DOC: proxy-protocol: fix wrong byte in provided example > BUG/CRITICAL: http: properly reject empty http header field names > > --- -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Important HAProxy releases to come next week
That's a pretty sneaky way to ruin one's Valentine dinner. :-D - Mail original - De: "Willy Tarreau" À: "haproxy" Envoyé: Vendredi 10 Février 2023 17:28:27 Objet: [*EXT*] Important HAProxy releases to come next week Hello, we've been notified of a vulnerability in haproxy that will deserve a new series of releases for all branches. As such I'm not going to issue 2.7.3 today and will postpone it a bit to avoid confusion. The releases for 2.7, 2.6, 2.5, 2.4, 2.2, and 2.0 are planned for Tuesday 14th around 5pm CET. We do have a config workaround for the vulnerability that works with all versions, though it's not pretty (as any workaround). I'll share it with the announce on Tuesday, but as always it's better to update rather than start to accumulate config hacks. I wanted to mention this to raise awareness and help to speed up deployment once the issue is fully disclosed. Thanks for your understanding, and have a nice week-end. Willy PS: don't worry, your process will not crash over the week-end :-) -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
That was it : - remove the EXTRAOPTS from /etc/default/haproxy - stop the running process referencing -x /run/haproxy/admin.sock on the CLI - upgrade All is OK. First processes do not list -x on the CLI and a reload spawn a process with -x sockpair@ Thanks for your help. Ionel - Mail original - De: "Vincent Bernat" À: "Ionel GARDAIS" Cc: "Willy Tarreau" , "haproxy" Envoyé: Samedi 20 Août 2022 20:28:21 Objet: Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3 On 2022-08-20 19:15, Ionel GARDAIS wrote: > Below is the systemctl cat haproxy output. > Yes, not responding backends was expected, sorry for not specified it. > "expose-fd listeners" was present in the configuration file. Update fails > even after I removed the two keywords. > I have > EXTRAOPTS="-x /run/haproxy/admin.sock" > defined in /etc/defaults/haproxy > This is the path referenced in the configuration file > stats socket /run/haproxy/admin.sock mode 660 level admin The EXTRAOPTS in /etc/default/haproxy is ignored since quite some time (due to being overrided in the systemd file). -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
Below is the systemctl cat haproxy output. Yes, not responding backends was expected, sorry for not specified it. "expose-fd listeners" was present in the configuration file. Update fails even after I removed the two keywords. I have EXTRAOPTS="-x /run/haproxy/admin.sock" defined in /etc/defaults/haproxy This is the path referenced in the configuration file stats socket /run/haproxy/admin.sock mode 660 level admin However, during the upgrade process, the newly started process is referencing 'sockpair@3' /usr/sbin/haproxy -sf 1016 -x sockpair@3 -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid [Unit] Description=HAProxy Load Balancer Documentation=man:haproxy(1) Documentation=file:/usr/share/doc/haproxy/configuration.txt.gz After=network-online.target rsyslog.service Wants=network-online.target [Service] EnvironmentFile=-/etc/default/haproxy EnvironmentFile=-/etc/sysconfig/haproxy BindReadOnlyPaths=/dev/log:/var/lib/haproxy/dev/log Environment="CONFIG=/etc/haproxy/haproxy.cfg" "PIDFILE=/run/haproxy.pid" "EXTRAOPTS=-S /run/haproxy-master.sock" ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE $EXTRAOPTS ExecReload=/usr/sbin/haproxy -Ws -f $CONFIG -c -q $EXTRAOPTS ExecReload=/bin/kill -USR2 $MAINPID KillMode=mixed Restart=always SuccessExitStatus=143 Type=notify # The following lines leverage SystemD's sandboxing options to provide # defense in depth protection at the expense of restricting some flexibility # in your setup (e.g. placement of your configuration files) or possibly # reduced performance. See systemd.service(5) and systemd.exec(5) for further # information. # NoNewPrivileges=true # ProtectHome=true # If you want to use 'ProtectSystem=strict' you should whitelist the PIDFILE, # any state files and any other files written using 'ReadWritePaths' or # 'RuntimeDirectory'. # ProtectSystem=true # ProtectKernelTunables=true # ProtectKernelModules=true # ProtectControlGroups=true # If your SystemD version supports them, you can add: @reboot, @swap, @sync # SystemCallFilter=~@cpu-emulation @keyring @module @obsolete @raw-io [Install] WantedBy=multi-user.target -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager ----- Mail original - De: "Vincent Bernat" À: "Ionel GARDAIS" Cc: "Willy Tarreau" , "haproxy" Envoyé: Vendredi 19 Août 2022 23:37:47 Objet: Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3 On 2022-08-19 23:09, Ionel GARDAIS wrote: > Aug 19 22:09:09 haproxy-2 haproxy[1280]: [WARNING] (1280) : Failed to > connect to the old process socket '/run/haproxy/admin.sock' > Aug 19 22:09:09 haproxy-2 haproxy[1280]: [ALERT](1280) : Failed to get > the sockets from the old process! There was a change in 2.6.0 (but not in 2.6.3) where "expose-fd listeners" for stats socket is not needed anymore. Is the line present in your configuration? (grep admin.sock /etc/haproxy/haproxy.cfg) What's the output of systemctl cat haproxy? > Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : New worker > (1282) forked > Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : Loading success. > Aug 19 22:09:09 haproxy-2 haproxy[1282]: [WARNING] (1282) : Server > bck-speedtest/go-v6 is DOWN, reason: Layer4 connection problem, info: > "Connection> > Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-speedtest/go-v6 is DOWN, > reason: Layer4 connection problem, info: "Connection refused", check dur> > Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-speedtest/go-v6 is DOWN, > reason: Layer4 connection problem, info: "Connection refused", check dur> > Aug 19 22:09:09 haproxy-2 haproxy[1282]: [WARNING] (1282) : Server > bck-nuxeo-arch/nuxeo-arch is DOWN, reason: Layer4 connection problem, info: > "No r> > Aug 19 22:09:09 haproxy-2 haproxy[1282]: [ALERT](1282) : backend > 'bck-nuxeo-arch' has no server available! > Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-nuxeo-arch/nuxeo-arch is > DOWN, reason: Layer4 connection problem, info: "No route to host", check> > Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-nuxeo-arch/nuxeo-arch is > DOWN, reason: Layer4 connection problem, info: "No route to host", check> > Aug 19 22:09:09 haproxy-2 haproxy[1282]: backend bck-nuxeo-arch has no server > available! > Aug 19 22:09:09 haproxy-2 haproxy[1282]: backend bck-nuxeo-arch has no server > available! > […] // others few backends not responding > // then Are these expected? -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
Yes from haproxy.debian.net Aug 19 22:09:09 haproxy-2 systemd[1]: Starting HAProxy Load Balancer... Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : haproxy version is 2.6.3-1~bpo11+1 Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : path to executable is /usr/sbin/haproxy Aug 19 22:09:09 haproxy-2 haproxy[1280]: [WARNING] (1280) : config : 'option forwardfor' ignored for frontend 'gerrit-ssh' as it requires HTTP mode. Aug 19 22:09:09 haproxy-2 haproxy[1280]: [WARNING] (1280) : config : 'option forwardfor' ignored for backend 'bck-review-ssh' as it requires HTTP mo> Aug 19 22:09:09 haproxy-2 haproxy[1280]: [WARNING] (1280) : Failed to connect to the old process socket '/run/haproxy/admin.sock' Aug 19 22:09:09 haproxy-2 haproxy[1280]: [ALERT](1280) : Failed to get the sockets from the old process! Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : New worker (1282) forked Aug 19 22:09:09 haproxy-2 haproxy[1280]: [NOTICE] (1280) : Loading success. Aug 19 22:09:09 haproxy-2 haproxy[1282]: [WARNING] (1282) : Server bck-speedtest/go-v6 is DOWN, reason: Layer4 connection problem, info: "Connection> Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-speedtest/go-v6 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check dur> Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-speedtest/go-v6 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check dur> Aug 19 22:09:09 haproxy-2 haproxy[1282]: [WARNING] (1282) : Server bck-nuxeo-arch/nuxeo-arch is DOWN, reason: Layer4 connection problem, info: "No r> Aug 19 22:09:09 haproxy-2 haproxy[1282]: [ALERT](1282) : backend 'bck-nuxeo-arch' has no server available! Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-nuxeo-arch/nuxeo-arch is DOWN, reason: Layer4 connection problem, info: "No route to host", check> Aug 19 22:09:09 haproxy-2 haproxy[1282]: Server bck-nuxeo-arch/nuxeo-arch is DOWN, reason: Layer4 connection problem, info: "No route to host", check> Aug 19 22:09:09 haproxy-2 haproxy[1282]: backend bck-nuxeo-arch has no server available! Aug 19 22:09:09 haproxy-2 haproxy[1282]: backend bck-nuxeo-arch has no server available! […] // others few backends not responding // then Aug 19 22:10:39 haproxy-2 systemd[1]: haproxy.service: start operation timed out. Terminating. Aug 19 22:10:39 haproxy-2 systemd[1]: haproxy.service: Killing process 1282 (haproxy) with signal SIGKILL. Aug 19 22:10:39 haproxy-2 systemd[1]: haproxy.service: Failed with result 'timeout'. Aug 19 22:10:39 haproxy-2 systemd[1]: haproxy.service: Unit process 1282 (haproxy) remains running after unit stopped. Aug 19 22:10:39 haproxy-2 systemd[1]: Failed to start HAProxy Load Balancer. Aug 19 22:10:39 haproxy-2 systemd[1]: haproxy.service: Consumed 1min 30.496s CPU time. - Mail original - De: "Vincent Bernat" À: "Ionel GARDAIS" , "Willy Tarreau" Cc: "haproxy" Envoyé: Vendredi 19 Août 2022 22:37:49 Objet: Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3 On 2022-08-19 22:16, Ionel GARDAIS wrote: > I had to rollback to 2.6.2 after having upgrade to 2.6.3 because systemd was > restarting the haproxy process every 1m30s (on an up-to-date Debian 11) > apt upgrade itself hung while doing the upgrade. With Debian packages from haproxy.debian.net? Logs from "journalctl -eu haproxy" should help. -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] [ANNOUNCE] haproxy-2.6.3
Hi Willy,
I had to rollback to 2.6.2 after having upgrade to 2.6.3 because systemd was
restarting the haproxy process every 1m30s (on an up-to-date Debian 11)
apt upgrade itself hung while doing the upgrade.
Regards,
Ionel
- Mail original -
De: "Willy Tarreau"
À: "haproxy"
Envoyé: Vendredi 19 Août 2022 18:51:25
Objet: [*EXT*] [ANNOUNCE] haproxy-2.6.3
Hi,
HAProxy 2.6.3 was released on 2022/08/19. It added 60 new commits
after version 2.6.2.
This release contains assorted fixes for issues discovered after the
previous 2.6.2 release, and there are quite a few annoying ones so I
preferred not to let them rot too long:
- there was an issue with the log-forward section, where a missing
initialization due to code duplication caused some settings from
"bind" lines to be ignored (ssl, thread, a few such things).
- the late cleanup of the CLI keyword processing in 2.6 caused some
breakage when certain commands are chained using a semi-colon, due
to a command context that was not reset between commands and could
then be misused. For example "show version; show sess" could crash
the process.
- some ugly crashes saying "offset > buf->data" were reported when
using the DNS (e.g. issue #1781) , and it was found that it was using
uninitialized fields in a structure. A pool_zalloc() was used to paper
over it, since it's not even impossible that others fields are affected
and that this part requires a deep breath before being dived into.
- there was a logic but in processing of option http-restrict-req-hdr-names
that could cause deletion of a wrong header or a crash when facing
multiple forbidden chars. This was reported in issue #1822, analysed
and fixed by Mateusz Malek.
- an old bug in the H2 mux may cause spurious stream resets when uploading
and downloading at the same time from the same stream, due to the window
update frames having to be delayed when the output is full, and sent
later after the stream ID was reset. Those using POST to servers might
have experienced such occasional issues and might want to check for any
improvement there. This was reported in issue #1830 and diagnosed by
David le Blanc.
- during atomic map updates of entries based on prefix length ("_ip" and
"_beg"), if a new finer entry was added and matched an input before being
committed, it was naturally ignored, but the lookup would continue with
next keys without rechecking the key, possibly returning an incorrect
match. This was reported by Miroslav in issue #1802.
- Tim reported in issue #1799 that upon reload, and old process that failed
to synchronize its tables with the new one could loop for a while without
any pause and waste a lot of CPU doing this.
- the recently added assertion in fd_delete() already spotted a long
existing bug on reload, where the FD that was used by the pipe of an
exiting thread could be instantly reused as a socket by another thread
and be incorrectly inserted in the table. Most of the time it remained
unnoticed as these were mostly health checks on a reloading process, but
since the assertion a few users started to see logs of a crash of the
exiting process. This was reported both by Christian Ruppert in issue
#1807 and by Cedric Paillet.
- there was an undesired sharing of data between default-servers that
could lead to double-frees concretized by crashes when checking the
config. This was reported in issue #1804 by Fabiano Nunes.
- when a server had numerous requests waiting in queue, it was possible
for a thread to spend its time picking requests from this queue while
all other threads were working at refilling it, and the time spent
doing this was unbounded, which could 1) add high processing latencies,
and 2) even trigger the watchdog if the thread worked too long. I could
trigger the watchdog a few times on a 48-thread machine. I think it's
the same issue that was reported 2 years ago by Jaroslaw Rzeszotko in
issue #880.
- the ring section's "size" parser was too lax and would take "1M" for "1"
without even issuing a warning... Also error messages regarding incorrect
values would copy the input string instead of the parsed value, providing
no way to diagnose.
- there was a problem with the ring forwarding that's not very clear to me
(I have no idea about the impact, commit 96417f3 in master).
- I managed to trigger an error on reload where the old process died saying
"t->tid >= 0 && t->tid != tid". This is caused by the deinit code that
needs to stop stuff initialized on other threads, and as such it violates
some consistency checks. The check was relaxed to ignore the stopping
condition.
- reading from the rings could also occasionally freeze at high rate if
the reader had to stop due to a buffer full while the writer had already
stopped due to a ring full.
- Tim reported in issue #1803 that sometimes a new process would fail to
get the sockets from the old one on reload,
Re: [*EXT*] [ANNOUNCE] haproxy-2.6-dev4
Thanks Willy for these updates.
While skimming the result on the interop website, I was surprised that haproxy
is always more than 50% slower than its competitor.
Is it because you've enable lots of traces as part of your debugging process
for the runs ?
Ionel
- Mail original -
De: "Willy Tarreau"
À: "haproxy"
Envoyé: Samedi 26 Mars 2022 10:22:02
Objet: [*EXT*] [ANNOUNCE] haproxy-2.6-dev4
Hi,
HAProxy 2.6-dev4 was released on 2022/03/26. It added 80 new commits
after version 2.6-dev3.
The activity started to calm down a bit, which is good because we're
roughly 2 months before the release and it will become important to avoid
introducing last-minute regressions.
This version mostly integrates fixes for various bugs in various places
like stream-interfaces, QUIC, the HTTP client or the trace subsystem. The
remaining patches are mostly QUIC improvements and code cleanups. In
addition the MQTT protocol parser was extended to also support MQTTv3.1.
A change discussed around previous announce was made in the H2 mux: the
"timeout http-keep-alive" and "timeout http-request" are now respected
and work as documented, so that it will finally be possible to force such
connections to be closed when no request comes even if they're seeing
control traffic such as PING frames. This can typically happen in some
server-to-server communications whereby the client application makes use
of PING frames to make sure the connection is still alive. I intend to
backport this after some time, probably to 2.5 and later 2.4, as I've
got reports about stable versions currently posing this problem.
I'm expecting to see another batch of stream-interface code refactoring
that Christopher is still working on. This is a very boring and tedious
task that should significantly lower the long-term maintenance effort,
so I'm willing to wait a little bit for such changes to be ready. What
this means for users is a reduction of the bugs we've seen over the last
2-3 years alternating between truncated responses and never-dying
connections and that result from the difficulty to propagate certain
events across multiple layers.
Also William still has some updates to finish on the HTTP client
(connection retries, SSL cert verification and host name resolution
mainly). On the paper, each of them is relatively easy, but practically,
since the HTTP client is the first one of its category, each attempt to
progress is stopped by the discovery of a shortcoming or bug that were
not visible before. Thus the progress takes more time than desired but
as a side effect, the core code gets much more reliable by getting rid
of these old issues.
One front that made impressive progress over the last few months is QUIC.
While a few months ago we were counting the number of red boxes on the
interop tests at https://interop.seemann.io/ to figure what to work on as
a top priority, now we're rather counting the number of tests that report
a full-green state, and haproxy is now on par with other servers in these
tests. Thus the idea emerged, in order to continue to make progress on
this front, to start to deploy QUIC on haproxy.org so that interoperability
issues with browsers and real-world traffic can be spotted. A few attempts
were made and already revealed issues so for now it's disabled again. Be
prepared to possibly observe a few occasional hiccups when visiting the
site (and if so, please do complain to us). The range of possible issues
would likely be frozen transfers and truncated responses, but these should
not happen.
>From a technical point, the way it's done is by having a separate haproxy
process listening to QUIC on UDP port 1443, and forwarding HTTP requests
to the existing process. The main process constantly checks the QUIC one,
and when it's seen as operational, it appends an Alt-Svc header that
indicates the client that an HTTP/3 implementation is available on port
1443, and that this announce is valid for a short time (we'll leave it to
one minute only so that issues can resolve quickly, but for now it's only
10s so that quick tests cause no harm):
http-response add-header alt-svc 'h3=":1443"; ma=60' if \
{ var(txn.host) -m end haproxy.org } { nbsrv(quic) gt 0 }
As such, compatible browsers are free to try to connect there or not. Other
tools (such as git clone) will not use it. For those impatient to test it,
the QUIC process' status is reported at the bottom of the stats page here:
http://stats.haproxy.org/. The "quic" socket in the frontend at the top
reports the total traffic received from the QUIC process, so if you're
seeing it increase while you reload the page it's likely that you're using
QUIC to read it. In Firefox I'm having this little plugin loaded:
https://addons.mozilla.org/en-US/firefox/addon/http2-indicator/
It displays a small flash on the URL bar with different colors depending
on the protocol used to load the page (H1/SPDY/H2/H3). When that works it's
green (H3), otherwise it's blue (H2).
At
Re: [*EXT*] Re: host-based be routing with H2
Hi Tim, Noted for SNI and routing. User were not able to reproduce the issue when I've re-enable H2. I've kept the header capture active if I'm ever notified of an issue again. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Tim Düsterhus" À: "Ionel GARDAIS" , "haproxy" Envoyé: Mardi 5 Octobre 2021 21:23:58 Objet: [*EXT*] Re: host-based be routing with H2 Ionel, On 10/5/21 3:56 PM, Ionel GARDAIS wrote: > Currently, backend selection is made with > use_backend %[req.hdr(host),lower] > > Would > use_backend %[ssl_fc_sni,lower] # Layer 5 > or > use_backend %[req.ssl_sni,lower] # Layer 6 > help with H2 ? > That would be a big fat NO. SNI is ***never*** the correct solution to perform routing. In fact it will make the situation even worse for you. - req.hdr(host) is the correct solution and I am surprised that it does not work for you. Consider adding 'capture request header Host len 50' to your frontend and then share the log lines for affected requests. With the httplog format they should then indicate both the host as seen by HAProxy as well as the backed/server selected. Best regards Tim Düsterhus -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
host-based be routing with H2
Hi, I'm having trouble with backend-routing based on host header when H2 is enabled. Frontend is https only and all backends are HTTP1. We're using v2.4.4. When the user browser is directed to app2.example.com, it switches to app1.example.com. There is one public IP address, certificate is wildcard for the domain, so app1 and app2 share the same IP and certificate. When H2 is disabled, all is working fine. Currently, backend selection is made with use_backend %[req.hdr(host),lower] Would use_backend %[ssl_fc_sni,lower] # Layer 5 or use_backend %[req.ssl_sni,lower] # Layer 6 help with H2 ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
session sticking
Hi, I'm running an keycloak cluster behind haproxy. Keycloak sets its own session cookie as AUTH_SESSION_ID with value .. The owner-node-id represents the node that "owns" the session. This node may not be the node that the client connects to, but connecting to it is recommended for performances. Thus, the initial connection could reach node1, the sessions assigned to node2 and haproxy will then stick to node1 whereas it would be optimal to stick to node2. Is there a way for haproxy to stick to a value extracted from a cookie returned by the server, without adding its own stickness informations ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
2Mrps : kudos to the team
Hi team, list, If you haven't already read it, go read this blog article : [ https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance/ | https://www.haproxy.com/blog/haproxy-forwards-over-2-million-http-requests-per-second-on-a-single-aws-arm-instance/ ] Such a milestone ! It's time to take time to thank all the great work achieved by the HAProxy team over the years. Thanks Willy for your vision and to stick with the Unix philosophy : m ake each program do one thing well. Thanks Tim, William, Aleksandar, Lukas, Christopher and all those working day-to-day to make HAProxy such a nice piece of code. *claps claps claps* Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: coredump since 2.2.7 upgrade
Thanks Christopher, that was it.
2.2.7 with 8461b9 reverted is stable for me.
--
Ionel GARDAIS
Tech'Advantage CIO - IT Team manager
- Mail original -
De: "Christopher Faulet"
À: "Ionel GARDAIS" , "haproxy"
Envoyé: Mardi 12 Janvier 2021 16:57:47
Objet: [*EXT*] Re: coredump since 2.2.7 upgrade
Le 12/01/2021 à 16:28, Ionel GARDAIS a écrit :
> Hi,
>
> I'm getting continuous core dump since the upgrade to 2.2.7 on debian 9.
> Where can I send them ?
>
Hi,
If you are using the DNS, there is a bug introduced by a recent change, leading
to a segfault. We reverted the commit but it is not backported yet. In the mean
time, in the 2.2, the commit 8461b9ea78 ("BUG/MINOR: dns: SRV records ignores
duplicated AR records") must be reverted. The commit fixed the issue #971. A
new
fix is under evaluation.
The same bug exists in the 2.3.3. The commit 45b6d2d47 must be reverted.
--
Christopher Faulet
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
coredump since 2.2.7 upgrade
Hi, I'm getting continuous core dump since the upgrade to 2.2.7 on debian 9. Where can I send them ? Jan 12 16:16:12 x haproxy[5204]: *** Error in `/usr/sbin/haproxy': corrupted double-linked list: 0x7f346802a550 *** Jan 12 16:16:12 x haproxy[5204]: === Backtrace: = Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7f34839c5bfb] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7f34839cbfc6] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(+0x7964c)[0x7f34839ce64c] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f34839cff64] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(CRYPTO_zalloc+0xe)[0x7f348455bf5e] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(EVP_DigestInit_ex+0x1b1)[0x7f348453ce21] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(PKCS1_MGF1+0xb4)[0x7f348458c254] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(RSA_padding_add_PKCS1_PSS_mgf1+0x213)[0x7f34845912c3] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x1be683)[0x7f3484590683] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(EVP_DigestSignFinal+0x180)[0x7f34845509e0] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x59bfe)[0x7f3484914bfe] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x4c74b)[0x7f348490774b] Jan 12 16:16:12 x haproxy[5204]: /usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_do_handshake+0x54)[0x7f34848f3d74] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(+0x51c9b)[0x55ce168d8c9b] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(run_tasks_from_lists+0x33d)[0x55ce16a4629d] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(process_runnable_tasks+0x3ac)[0x55ce16a46d4c] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(run_poll_loop+0xaa)[0x55ce169fcd2a] Jan 12 16:16:12 x haproxy[5204]: /usr/sbin/haproxy(+0x176129)[0x55ce169fd129] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4)[0x7f3484b514a4] Jan 12 16:16:12 x haproxy[5204]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f3483a3dd0f] Jan 12 16:16:12 x haproxy[5204]: === Memory map: Jan 12 16:16:13 x haproxy[5204]: [ALERT] 011/161613 (5204) : Current worker #1 (5206) exited with code 134 (Aborted) Jan 12 16:16:13 x haproxy[5204]: [ALERT] 011/161613 (5204) : exit-on-failure: killing every processes with SIGTERM Jan 12 16:16:13 x haproxy[5204]: [WARNING] 011/161613 (5204) : All workers exited. Exiting... (134) -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: haproxy hiding url/minio
I would have add the trailing slash to avoid "/storages" being rewote. 'http-request set-path %[regsub(^/storage/,/minio/)]' -- Ionel - Mail original - De: "Chad Lavoie" À: "haproxy" Cc: "Jonathan Opperman" Envoyé: Jeudi 24 Décembre 2020 02:04:57 Objet: [*EXT*] Re: haproxy hiding url/minio Greetings, On 12/23/2020 7:10 PM, Jonathan Opperman wrote: > > Works perfectly fine, what is the best way to hide /minio so it will > rather say /storage so externally > I hide the fact that we are using minio? You can do that by using 'http-request set-path %[regsub(^/storage,/minio)]' to rewrite the path that the backend sees from what the client sent. - Chad -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: Quick question on atomics on ARM
My bad, I wasn't up to date. Olivier's fix is OK : no more CPU hogging. -- Ionel - Mail original - De: "Willy Tarreau" À: "Ionel GARDAIS" Cc: "David CARLIER" , "haproxy" Envoyé: Mercredi 23 Décembre 2020 14:52:32 Objet: Re: [*EXT*] Re: Quick question on atomics on ARM On Wed, Dec 23, 2020 at 02:48:17PM +0100, Ionel GARDAIS wrote: > For what it's worth, I tried to build haproxy on Apple M1. > It builds OK but at run, it's stuck in the initial pool_flush, hogging 100% > CPU. > > the assembly part of __ha_cas_dw for __aarch64__ seems to be ignored. What version did you try ? Olivier just fixed an issue related to the macos assembler using ';' as a comment, precisely in __ha_cas_dw :-) Please try again with the latest master from right now. Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: Quick question on atomics on ARM
For what it's worth, I tried to build haproxy on Apple M1. It builds OK but at run, it's stuck in the initial pool_flush, hogging 100% CPU. the assembly part of __ha_cas_dw for __aarch64__ seems to be ignored. -- Ionel - Mail original - De: "Willy Tarreau" À: "David CARLIER" Cc: "haproxy" Envoyé: Lundi 21 Décembre 2020 11:16:47 Objet: [*EXT*] Re: Quick question on atomics on ARM Hi David, On Tue, Dec 15, 2020 at 03:54:34PM +, David CARLIER wrote: > Hi, > > I started to look at Haproxy on ARM and stumbled across the > implementation of cpu relax. While it is needed to have such > instruction, I am however wondering if the yield instruction is not > more appropriate than isb in this case ? The use of ISB was suggested by one of the guys in charge of the AWS ARM platform, and in tests it actually performed quite well. It will apparently pause the current CPU for roughly 50 cycles. I have not tested the YIELD instruction however. I suspect based on its description that it's more tailored for some SMT environments (in case that happens one day), and that on other ones it should essentially be a NOP. But this could be tested. Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: Backport ssl_{c,s}_chain_der to 2.2 ?
Thanks Christopher !
--
Ionel
- Mail original -
De: "Christopher Faulet"
À: "Ionel GARDAIS" , "haproxy"
Envoyé: Vendredi 6 Novembre 2020 12:09:07
Objet: [*EXT*] Re: Backport ssl_{c,s}_chain_der to 2.2 ?
Le 06/11/2020 à 11:46, Ionel GARDAIS a écrit :
> Thanks Willy and the team for releasing 2.3 !
>
> Is ssl_{c,s}_chain_der fetch planned to be backported to 2.2 ?
>
Not planned but small enough to be done. Now backported :)
--
Christopher Faulet
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Backport ssl_{c,s}_chain_der to 2.2 ?
Thanks Willy and the team for releasing 2.3 !
Is ssl_{c,s}_chain_der fetch planned to be backported to 2.2 ?
Ionel
--
232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON
Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: http2 smuggling
Hi Willy, Being devil's advocate : isn't the point that even if this is a documented, standardized and intended behavior, users relying on the reverse proxy for security/sanity checks could by tricked by this feature inadvertently ? -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Willy Tarreau" À: "Igor Cicimov" Cc: "haproxy" Envoyé: Vendredi 11 Septembre 2020 08:19:12 Objet: [*EXT*] Re: http2 smuggling On Fri, Sep 11, 2020 at 08:07:02AM +0200, Willy Tarreau wrote: > Sadly, as usual after people discover protocols during the summer, some > journalists will surely want to make noise about this to put some bread > on their table... > > Thanks for the link anyway I had a partial laugh; partial only because > it makes useless noise. And sadly, this one already started to make some noise there about his recent discovery of a 20-years old standard: https://twitter.com/theBumbleSec Had he asked if we supported 101, we could even have saved him time in his HTTP discover test by pointing him to the doc: http://git.haproxy.org/?p=haproxy.git;a=blob;f=doc/configuration.txt;h=c1f6f82;hb=HEAD#l332 Probably that next year he will discover that we also support CONNECT. It's not even funny, the world is really doomed... Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] http/2 fine tuning
That's improvement ! Are there similar settings in haproxy to get these numbers ? Ionel De: " ???" À: "haproxy" Envoyé: Mardi 25 Août 2020 09:25:55 Objet: [*EXT*] http/2 fine tuning just in case someone missed [ https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/ | https://blog.cloudflare.com/delivering-http-2-upload-speed-improvements/ ] -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: max header size
Hi Bruno, Thanks for the pointer : I think I've hit something. I've been able to make it by pushing tune.bufsize to 131072 but as it seems to big to be honest, I tried to tweak the header sent. With the default tune.bufsize (16384), trial-and-error shows the following result : - a long header content with a short header name is OK http-response set-header X-Long-Header "content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent" - the same header content with a long header name breaks haproxy (500 sent with PH--) http-response set-header X-Long-Header-With-Long-Name "content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent content longlonglonglongcontent" - the bigger bufsize is, the more files can be sent until haproxy starts sending 500's Unfortunalty I have no test environment to bisect what is the maximum header name length vs maximum header content and if the two are correlated. Ionel De: "Bruno Henc" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Mercredi 12 Août 2020 18:37:01 Objet: [*EXT*] Re: max header size Hi Ionel, Could you please try setting tune.bufsize 32768 in the global section? (See the associated configuration manual entry for tune.bufsize for a possible answer to both of your questions and for the memory-usage implications). Regards, Bruno ‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, August 12, 2020 6:25 PM, Ionel GARDAIS wrote: Hi list, I've upgrade to 2.2.2 and now haproxy sends HTTP 500 (logged as PH--). 'show errors' displays no error. After further digging, it looks like the content of "http-response set-header" is too big. What is the limit enforced by haproxy as a header size ? Is the limit the same when piling a set-header followed by multiple add-header ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
max header size
Hi list, I've upgrade to 2.2.2 and now haproxy sends HTTP 500 (logged as PH--). 'show errors' displays no error. After further digging, it looks like the content of "http-response set-header" is too big. What is the limit enforced by haproxy as a header size ? Is the limit the same when piling a set-header followed by multiple add-header ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: Pool trash grows quite quickly
> Teachers hate goto because > they don't fix bugs, but when you troubleshoot you quickly hate return :-) Mine was OK with it, as it's just another form of JMP. -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: 404 + VN when enabling h2 in front of keycloak
I give a try to other browsers. Chrome and Brave both fails, even in private browsing. Firefox however succeeded in private browsing but failed in classic browsing, even after clearing all caches. I gave a try to FF75.0 in Windows : it fails both in classic and private browsing. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Ionel GARDAIS" À: "Jarno Huuskonen" Cc: "haproxy" Envoyé: Dimanche 26 Avril 2020 11:13:46 Objet: Re: [*EXT*] Re: 404 + VN when enabling h2 in front of keycloak Hi Jarno, Thanks for these pointers. I'm running 2.1.4. keycloak does not say anything : no warnings nor errors. I give a try to no option http-use-hex with no luck : same issue. However, mystery gets deeper : it works with Safari 11.1.2 (I know, got an old OS X) but fails with Firefox 75.0. Safari calls in H2 return HTTP 200 or HTTP 302 with --VR or --VN. Firefox calls are still returning HTTP 404 with --VN. I'll try to dump header for both callers. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original ----- De: "Jarno Huuskonen" À: "Ionel GARDAIS" , "haproxy" Envoyé: Dimanche 26 Avril 2020 10:43:42 Objet: [*EXT*] Re: 404 + VN when enabling h2 in front of keycloak Hi Ionel, On Sat, 2020-04-25 at 11:22 +0200, Ionel GARDAIS wrote: > I tried to enable h2 in our haproxy setup. What's your haproxy version ? > Most proxied servers work well except Keycloak (SSO solution) > > While everything works fine in HTTP/1.1, Keycloak returns a 404 and > haproxy shows a --VN status in h2. Have tested w/out HTX (no option http-use-htx ( https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#4-option%20http-use-htx )) ? Does keycloak log anything useful ? > As there are two Keycloak servers working in pair, the backend is > defined as > > backend bck-keycloak > cookie AUTH_SESSION_ID prefix > server keycloak 192.168.8.27:8080 check cookie s1 > server keycloak-bck 192.168.8.28:8080 check cookie s2 > > Are their specific tuning required for h2 to work correctly ? Maybe keycloak is case sensitive on some http headers ? Have you tried comparing http/1.1 and http/2 request headers going to keycloak server ? ( https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#h1-case-adjust ) -Jarno -- Jarno Huuskonen -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301 -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: 404 + VN when enabling h2 in front of keycloak
Hi Jarno, Thanks for these pointers. I'm running 2.1.4. keycloak does not say anything : no warnings nor errors. I give a try to no option http-use-hex with no luck : same issue. However, mystery gets deeper : it works with Safari 11.1.2 (I know, got an old OS X) but fails with Firefox 75.0. Safari calls in H2 return HTTP 200 or HTTP 302 with --VR or --VN. Firefox calls are still returning HTTP 404 with --VN. I'll try to dump header for both callers. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Jarno Huuskonen" À: "Ionel GARDAIS" , "haproxy" Envoyé: Dimanche 26 Avril 2020 10:43:42 Objet: [*EXT*] Re: 404 + VN when enabling h2 in front of keycloak Hi Ionel, On Sat, 2020-04-25 at 11:22 +0200, Ionel GARDAIS wrote: > I tried to enable h2 in our haproxy setup. What's your haproxy version ? > Most proxied servers work well except Keycloak (SSO solution) > > While everything works fine in HTTP/1.1, Keycloak returns a 404 and > haproxy shows a --VN status in h2. Have tested w/out HTX (no option http-use-htx ( https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#4-option%20http-use-htx )) ? Does keycloak log anything useful ? > As there are two Keycloak servers working in pair, the backend is > defined as > > backend bck-keycloak > cookie AUTH_SESSION_ID prefix > server keycloak 192.168.8.27:8080 check cookie s1 > server keycloak-bck 192.168.8.28:8080 check cookie s2 > > Are their specific tuning required for h2 to work correctly ? Maybe keycloak is case sensitive on some http headers ? Have you tried comparing http/1.1 and http/2 request headers going to keycloak server ? ( https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#h1-case-adjust ) -Jarno -- Jarno Huuskonen -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
404 + VN when enabling h2 in front of keycloak
Hi list, I tried to enable h2 in our haproxy setup. Most proxied servers work well except Keycloak (SSO solution) While everything works fine in HTTP/1.1, Keycloak returns a 404 and haproxy shows a --VN status in h2. As there are two Keycloak servers working in pair, the backend is defined as backend bck-keycloak cookie AUTH_SESSION_ID prefix server keycloak 192.168.8.27:8080 check cookie s1 server keycloak-bck 192.168.8.28:8080 check cookie s2 Are their specific tuning required for h2 to work correctly ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: Question about demo website
Hi Willy, Thanks for your feedback : I forgot the "option socket-stats" in the frontend. It's all pretty now :) -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Willy Tarreau" À: "Ionel GARDAIS" Cc: "William Lallemand" , "haproxy" Envoyé: Mardi 21 Avril 2020 16:26:33 Objet: Re: [*EXT*] Re: Question about demo website Hi Ionel, On Tue, Apr 21, 2020 at 10:51:24AM +0200, Ionel GARDAIS wrote: > thanks William, > > My fronted definition is : > frontend ft-public > bind ip.v.4.addr:80 name web-v4 > bind [ip:v:6:addr]:80 name web-v6 > > and I'm still seeing only a Frontend entry in the table > > > I also tried to add > > stats show-desc > stats show-legends > stats show-node > > to the dedicated stats listener with no luck. That's what I'm having: frontend http-in option socket-stats bind 10.x.x.x:60080 ... name IPv4-direct bind 10.x.x.x:60081 ... name IPv4-cached bind :::80 ... v6only name IPv6-direct bind 127.0.0.1:60080 name local bind 127.0.0.1:65443 name local-https accept-proxy ssl ... modehttp (...) backend demo mode http stats enable stats show-node 1wt.eu #stats show-legends# shows detailed info (ip, cookies, ...) stats uri / stats scope http-in stats scope www stats scope git stats scope demo As William mentioned, the socket names are those on the "bind" lines. The "option socket-stats" in the frontend is the one allowing to have one stats entry per bind line. Hoping this helps, Willy -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Question about demo website
Hi list, On [ http://demo.haproxy.org/ | http://demo.haproxy.org ] , what does IPv4-Direct, IPv4-cached, IPv6-direct, local, local-https represents in regard to http-in ? http-in looks like a frontend, are the other just "listen" directives ? How do they refer to http-in ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: 503 SC with fcgi
Oh my ! This is a chroot issue. haproxy is running in chroot but the fpm socket is outside. When placing the socket inside the jail, it works with the socket. Does the performance difference between IP and socket is worth the trouble ? -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Aleksandar Lazic" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Mercredi 8 Avril 2020 09:08:59 Objet: Re: [*EXT*] Re: 503 SC with fcgi On 08.04.20 08:52, Ionel GARDAIS wrote: > It works with 127.0.0.1:29001 (the listener I configured for this pool) That's an important successful test. I personally prefer the tcp way to afoid such problems. > About the socket : > - it lives in /run/php with > $ ls -alF /run/php/speedtest-fpm.sock > srw-rw 1 www-data www-data 0 Apr 7 21:11 /run/php/speedtest.sock= > > - /run/php is owned by www-data:www-data with 755 perms > $ ls -alF /run/ | grep php > drwxr-xr-x 2 www-datawww-data 180 Apr 7 21:11 php/ > > - haproxy user is member of www-data group > $ groups haproxy > haproxy : haproxy www-data Please can you share the config of your haproxy. > Debug logs are silent about any permission problem : > > $ egrep -i "(cgi|fpm|sock|perm)" /var/log/haproxy.log > Apr 8 08:42:36 ns3089939 haproxy[1151]: #011[FCGI] fcgi-app > Apr 8 08:42:36 ns3089939 haproxy[1151]: [WARNING] 098/084236 (1151) : Failed > to connect to the old process socket '/run/haproxy/admin.sock' > Apr 8 08:42:36 ns3089939 haproxy[1151]: [ALERT] 098/084236 (1151) : Failed > to get the sockets from the old process! Are you running haproxy with chroot setuped? Can you try to run the following. Stop haproxy. strace -tTfveall -a1024 -s1024 -o haproxy-trace.txt haproxy -f -d Make a request and stop then haproxy. Compress haproxy-trace.txt and share here. > Apr 8 08:42:36 ns3089939 haproxy[1151]: Proxy bck-speed-fpm started. > Apr 8 08:43:00 ns3089939 haproxy[1152]: > 2a01:cb00:663:fd00:20b5:6759:d972:be50:63090 [08/Apr/2020:08:43:00.648] > ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET > /backend/getIP.php?isp=true=km=0.7819314534908071 HTTP/1.1" > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0014:bck-speed-fpm.clicls[0026:0025] > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0014:bck-speed-fpm.closed[0026:0025] > Apr 8 08:43:00 ns3089939 haproxy[1152]: > 2a01:cb00:663:fd00:20b5:6759:d972:be50:63091 [08/Apr/2020:08:43:00.896] > ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET > /backend/empty.php?r=0.7112678877934051 HTTP/1.1" > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0015:bck-speed-fpm.clicls[0025:0026] > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0015:bck-speed-fpm.closed[0025:0026] > Apr 8 08:43:01 ns3089939 haproxy[1152]: > 2a01:cb00:663:fd00:20b5:6759:d972:be50:63092 [08/Apr/2020:08:43:01.724] > ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET > /backend/empty.php?r=0.9895406737322412 HTTP/1.1" > Apr 8 08:43:01 ns3089939 haproxy[1151]: > 0016:bck-speed-fpm.clicls[0025:0026] > Apr 8 08:43:01 ns3089939 haproxy[1151]: > 0016:bck-speed-fpm.closed[0025:0026] > Apr 8 08:43:02 ns3089939 haproxy[1152]: > 2a01:cb00:663:fd00:20b5:6759:d972:be50:63093 [08/Apr/2020:08:43:02.041] > ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET > /backend/empty.php?r=0.7692377905794734 HTTP/1.1" > Apr 8 08:43:02 ns3089939 haproxy[1151]: > 0017:bck-speed-fpm.clicls[0025:0027] > Apr 8 08:43:02 ns3089939 haproxy[1151]: > 0017:bck-speed-fpm.closed[0025:0027] > > > One calling sequence is : > > Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.accept(000b)=0026 > from [2a01:cb00:663:fd00:20b5:6759:d972:be50:63090] ALPN= > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0014:ft-secure.clireq[0026:]: GET > /backend/getIP.php?isp=true=km=0.7819314534908071 HTTP/1.1 > Apr 8 08:43:00 ns3089939 haproxy[1152]: > 2a01:cb00:663:fd00:20b5:6759:d972:be50:63090 [08/Apr/2020:08:43:00.648] > ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET > /backend/getIP.php?isp=true=km=0.7819314534908071 HTTP/1.1" > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0014:ft-secure.clihdr[0026:]: host: server > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0014:ft-secure.clihdr[0026:]: accept-encoding: gzip, deflate > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0014:ft-secure.clihdr[0026:]: cookie: > NG_TRANSLATE_LANG_KEY=%22fr%22 > Apr 8 08:43:00 ns3089939 haproxy[1151]: > 0014:ft-secure.clihdr[0026:]: accept: */* > Apr 8 08:43:00 ns3
Re: [*EXT*] Re: 503 SC with fcgi
It works with 127.0.0.1:29001 (the listener I configured for this pool) About the socket : - it lives in /run/php with $ ls -alF /run/php/speedtest-fpm.sock srw-rw 1 www-data www-data 0 Apr 7 21:11 /run/php/speedtest.sock= - /run/php is owned by www-data:www-data with 755 perms $ ls -alF /run/ | grep php drwxr-xr-x 2 www-datawww-data 180 Apr 7 21:11 php/ - haproxy user is member of www-data group $ groups haproxy haproxy : haproxy www-data Debug logs are silent about any permission problem : $ egrep -i "(cgi|fpm|sock|perm)" /var/log/haproxy.log Apr 8 08:42:36 ns3089939 haproxy[1151]: #011[FCGI] fcgi-app Apr 8 08:42:36 ns3089939 haproxy[1151]: [WARNING] 098/084236 (1151) : Failed to connect to the old process socket '/run/haproxy/admin.sock' Apr 8 08:42:36 ns3089939 haproxy[1151]: [ALERT] 098/084236 (1151) : Failed to get the sockets from the old process! Apr 8 08:42:36 ns3089939 haproxy[1151]: Proxy bck-speed-fpm started. Apr 8 08:43:00 ns3089939 haproxy[1152]: 2a01:cb00:663:fd00:20b5:6759:d972:be50:63090 [08/Apr/2020:08:43:00.648] ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET /backend/getIP.php?isp=true=km=0.7819314534908071 HTTP/1.1" Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:bck-speed-fpm.clicls[0026:0025] Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:bck-speed-fpm.closed[0026:0025] Apr 8 08:43:00 ns3089939 haproxy[1152]: 2a01:cb00:663:fd00:20b5:6759:d972:be50:63091 [08/Apr/2020:08:43:00.896] ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET /backend/empty.php?r=0.7112678877934051 HTTP/1.1" Apr 8 08:43:00 ns3089939 haproxy[1151]: 0015:bck-speed-fpm.clicls[0025:0026] Apr 8 08:43:00 ns3089939 haproxy[1151]: 0015:bck-speed-fpm.closed[0025:0026] Apr 8 08:43:01 ns3089939 haproxy[1152]: 2a01:cb00:663:fd00:20b5:6759:d972:be50:63092 [08/Apr/2020:08:43:01.724] ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET /backend/empty.php?r=0.9895406737322412 HTTP/1.1" Apr 8 08:43:01 ns3089939 haproxy[1151]: 0016:bck-speed-fpm.clicls[0025:0026] Apr 8 08:43:01 ns3089939 haproxy[1151]: 0016:bck-speed-fpm.closed[0025:0026] Apr 8 08:43:02 ns3089939 haproxy[1152]: 2a01:cb00:663:fd00:20b5:6759:d972:be50:63093 [08/Apr/2020:08:43:02.041] ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET /backend/empty.php?r=0.7692377905794734 HTTP/1.1" Apr 8 08:43:02 ns3089939 haproxy[1151]: 0017:bck-speed-fpm.clicls[0025:0027] Apr 8 08:43:02 ns3089939 haproxy[1151]: 0017:bck-speed-fpm.closed[0025:0027] One calling sequence is : Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.accept(000b)=0026 from [2a01:cb00:663:fd00:20b5:6759:d972:be50:63090] ALPN= Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clireq[0026:]: GET /backend/getIP.php?isp=true=km=0.7819314534908071 HTTP/1.1 Apr 8 08:43:00 ns3089939 haproxy[1152]: 2a01:cb00:663:fd00:20b5:6759:d972:be50:63090 [08/Apr/2020:08:43:00.648] ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 2/1/0/0/3 0/0 "GET /backend/getIP.php?isp=true=km=0.7819314534908071 HTTP/1.1" Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: host: server Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: accept-encoding: gzip, deflate Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: cookie: NG_TRANSLATE_LANG_KEY=%22fr%22 Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: accept: */* Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.2 Safari/605.1.15 Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: accept-language: fr-fr Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: referer: https://server/speedtest_worker.js?r=0.5199684076229355 Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:ft-secure.clihdr[0026:]: dnt: 1 Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:bck-speed-fpm.clicls[0026:0025] Apr 8 08:43:00 ns3089939 haproxy[1151]: 0014:bck-speed-fpm.closed[0026:0025] -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager - Mail original - De: "Aleksandar Lazic" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Mardi 7 Avril 2020 23:23:11 Objet: Re: [*EXT*] Re: 503 SC with fcgi On 07.04.20 21:17, Ionel GARDAIS wrote: > Alexander, > > I had it working by using a classic IP:port listener for php-fpm. > neither /run/php/speedtest-fpm.sock nor unix@/run/php/speedtest-fpm.sock > <mailto:unix@/run/php/speedtest-fpm.sock> worked Can you run HAProxy in debug mode? What's the permission for the
Re: [*EXT*] Re: 503 SC with fcgi
Alexander, I had it working by using a classic IP:port listener for php-fpm. neither /run/php/speedtest-fpm.sock nor [ mailto:unix@/run/php/speedtest-fpm.sock | unix@/run/php/speedtest-fpm.sock ] worked -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager De: "Ionel GARDAIS" À: "Aleksandar Lazic" Cc: "haproxy" Envoyé: Mardi 7 Avril 2020 20:23:42 Objet: Re: [*EXT*] Re: 503 SC with fcgi Nothing. Quiet as the streets during COVID-19. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager De: "Aleksandar Lazic" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Mardi 7 Avril 2020 17:58:24 Objet: [*EXT*] Re: 503 SC with fcgi What's in the php error log? Apr 7, 2020 5:18:11 PM Ionel GARDAIS : Hi, I'm giving a try to FCGI. I'm running 2.1.3-3 on debian. I follow https://www.haproxy.com/fr/blog/load-balancing-php-fpm-with-haproxy-and-fastcgi/ Here are the relevant parts of the config : acl to-slash path / acl static_content path_end .ai .css .eot .gz .html .ico .js .json .png .svg .ts .ttf .woff .woff2 use_backend bck-speed-fpm if host-speedtest !to-slash !static_content default_backend bck-nginx backend bck-speed-fpm use-fcgi-app speedtest-fpm server fpm /run/php/speedtest-fpm.sock proto fcgi fcgi-app speedtest-fpm log-stderr global docroot / index index.php path-info ^(/.+\.php)(/.*)?$ # path-info ^(.+?\.php)(/.*)$ FPM runs in a chroot hence the docroot to / Nginx serves correctly static files as expected. Non-static files are handled by the bcc-speed-fpm backend but all I got is ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 1/1/0/0/3 0/0 "GET /info.php HTTP/1.1" haproxy user is part of the www-data group who owns the fpm socket. Am I missing something ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301 -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re: 503 SC with fcgi
Nothing. Quiet as the streets during COVID-19. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager De: "Aleksandar Lazic" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Mardi 7 Avril 2020 17:58:24 Objet: [*EXT*] Re: 503 SC with fcgi What's in the php error log? Apr 7, 2020 5:18:11 PM Ionel GARDAIS : Hi, I'm giving a try to FCGI. I'm running 2.1.3-3 on debian. I follow https://www.haproxy.com/fr/blog/load-balancing-php-fpm-with-haproxy-and-fastcgi/ Here are the relevant parts of the config : acl to-slash path / acl static_content path_end .ai .css .eot .gz .html .ico .js .json .png .svg .ts .ttf .woff .woff2 use_backend bck-speed-fpm if host-speedtest !to-slash !static_content default_backend bck-nginx backend bck-speed-fpm use-fcgi-app speedtest-fpm server fpm /run/php/speedtest-fpm.sock proto fcgi fcgi-app speedtest-fpm log-stderr global docroot / index index.php path-info ^(/.+\.php)(/.*)?$ # path-info ^(.+?\.php)(/.*)$ FPM runs in a chroot hence the docroot to / Nginx serves correctly static files as expected. Non-static files are handled by the bcc-speed-fpm backend but all I got is ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 1/1/0/0/3 0/0 "GET /info.php HTTP/1.1" haproxy user is part of the www-data group who owns the fpm socket. Am I missing something ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301 -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
503 SC with fcgi
Hi, I'm giving a try to FCGI. I'm running 2.1.3-3 on debian. I follow https://www.haproxy.com/fr/blog/load-balancing-php-fpm-with-haproxy-and-fastcgi/ Here are the relevant parts of the config : acl to-slash path / acl static_content path_end .ai .css .eot .gz .html .ico .js .json .png .svg .ts .ttf .woff .woff2 use_backend bck-speed-fpm if host-speedtest !to-slash !static_content default_backend bck-nginx backend bck-speed-fpm use-fcgi-app speedtest-fpm server fpm /run/php/speedtest-fpm.sock proto fcgi fcgi-app speedtest-fpm log-stderr global docroot / index index.php path-info ^(/.+\.php)(/.*)?$ # path-info ^(.+?\.php)(/.*)$ FPM runs in a chroot hence the docroot to / Nginx serves correctly static files as expected. Non-static files are handled by the bcc-speed-fpm backend but all I got is ft-secure~ bck-speed-fpm/fpm 0/0/-1/-1/0 503 9965 - - SC-- 1/1/0/0/3 0/0 "GET /info.php HTTP/1.1" haproxy user is part of the www-data group who owns the fpm socket. Am I missing something ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [*EXT*] Re option forwardfor with IPv6
I'm currently facing a bug in gerrit 3.1.x which strip the last hextet of an IPv6 address. https://bugs.chromium.org/p/gerrit/issues/detail?id=12429#c4 A patch is on its way. Maybe it will make IPv6 logging more consistent. Will post my finding then. -- Ionel GARDAIS - Mail original - De: "Lukas Tribus" À: "Ionel GARDAIS" Cc: "haproxy" Envoyé: Mardi 3 Mars 2020 20:57:45 Objet: [*EXT*] Re option forwardfor with IPv6 Hello, On Tue, 3 Mar 2020 at 19:06, Ionel GARDAIS wrote: > > Hi, > > What is the expected behavior of "option forwardfor" with an IPv6 connection ? > Frontend listen on IPv4 and IPv6. The expected behavior is to insert the IPv6 address into the X-F-F header, and this is exactly what happens in my repro here. > For IPv4 incoming connections, the server correctly displays the original IP > address, wether the haproxy-to-server is made with IPv4 or IPv6. > For IPv6 incoming connections, the server displays the IP of haproxy, wether > the haproxy-to-server is made with IPv4 or IPv6. Ok, but "server displays" is not equivalent with "haproxy sends in the X-Forwarded-For header". Does your server actually support IPv6 addresses in this header? If yes, what do you see in your logs/on your servers, when you make a call directly to it without haproxy in the question? curl -H "X-Forwarded-For: 2001:0db8:85a3:::8a2e:0370:7334" http://direct-backend-server.example.org/testurl Lukas -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
option forwardfor with IPv6
Hi, What is the expected behavior of "option forwardfor" with an IPv6 connection ? Frontend listen on IPv4 and IPv6. For IPv4 incoming connections, the server correctly displays the original IP address, wether the haproxy-to-server is made with IPv4 or IPv6. For IPv6 incoming connections, the server displays the IP of haproxy, wether the haproxy-to-server is made with IPv4 or IPv6. The default section reads option forwardfor except 127.0.0.1/8 and there is no override of this setting. Should I add a line like http-request set-header X-Forwarded-For %[src] instead of using option forwardfor ? Thanks, Ionel -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
Re: [PATCH] compression/lua_validation.vtc depends on "which" utility
It's here on osx 10.11.6 at least. Looks like a sh builtin. -- Ionel GARDAIS Tech'Advantage CIO - IT Team manager De: " ???" À: "Tim Düsterhus" Cc: "haproxy" Envoyé: Dimanche 16 Février 2020 10:13:17 Objet: Re: [PATCH] compression/lua_validation.vtc depends on "which" utility вс, 16 февр. 2020 г. в 01:55, Tim Düsterhus < [ mailto:t...@bastelstu.be | t...@bastelstu.be ] >: Ilya, Am 15.02.20 um 20:38 schrieb Илья Шипицин: > that utility is not available by default in Fedora docker image. I believe we can rewrite that test to use the `type` builtin instead of `which`: is it POSIX ? I've just checked on freebsd, it's there. What about osx, aix, ... ? BQ_BEGIN > $ type -p md5 > $ type -p md5sum > /usr/bin/md5sum > $ md5=$(type -p md5 || type -p md5sum) > $ echo $md5 > /usr/bin/md5sum Best regards Tim Düsterhus BQ_END -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
