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
Re: mirroragent (haproxy)
Dear Christopher Configuration`s and info about haproxy and spoa version in attachment. > * If possible, info about the mirror requests Requests coming to haproxy should go to a specific IP, as well as duplicated in our parser located on another IP address. On the parser’s machine, we don’t see any incoming requests from the SPOA, even when removing tcpdump. The connection between the servers is stable. -- Best regards. Tuktamyshev A.N. ph. +7-965-243-99-81 03.03.2020, 18:21, "Christopher Faulet" : > Le 03/03/2020 à 14:39, Tuktamyshev Ainur a écrit : >> Dear, Collegues. >> >> There was a problem when mirroring traffic through Haproxy. >> >> In our spoa-mirror logs next mistakes: >> [ 0][ 0.000600] --- start --- 2020-03-03 15:48:30 - >> [ 1][ 318.942594] <1:26> (E) Failed to receive frame data: Stale file handle >> [ 2][ 416.600422] <2:26> (E) Failed to send frame length: Broken pipe >> [ 8][ 698.488390] <8:29> (E) Failed to send frame length: Broken pipe >> [ 5][ 698.677793] <5:26> (E) Failed to send frame length: Broken pipe >> [ 9][ 698.871186] <9:30> (E) Failed to send frame length: Broken pipe >> [ 7][ 699.071718] <7:28> (E) Failed to send frame length: Broken pipe >> [10][ 699.391399] <10:31> (E) Failed to send frame length: Broken pipe >> [ 6][ 699.585724] <6:27> (E) Failed to send frame length: Broken pipe >> [ 1][ 699.791090] <11:32> (E) Failed to send frame length: Broken pipe >> >> Haproxy version: "HA-Proxy version 2.1.0 2019/11/25" >> >> Can you help with this? >> If necessary, provide additional information. > > Hi, > > First of all, could you provide following info please ? > > * "haproxy -vv" output > * haproxy configuration > * spoa-mirror version > * spoa-mirror configuration > * If possible, info about the mirror requests > > -- > Christopher Faulet<>
Re: Segfault on 2.1.3
❦ 3 mars 2020 15:34 -07, Sean Reifschneider : > We've been running haproxy 1.8 series for quite a while. We're currently > in the process of updating to 2.1, and have installed from the vbernat PPA > on Ubuntu 18.04 using the same old config file. > > Now we are seeing segfaults a few times a day: You can easily collect core information if you install systemd-coredump. Then, use "coredumpctl list" to locate the collected core, then "coredumpctl info XXX" to get some stack traces. If you install the -dbgsym package, you can also use "coredumpctl debug XXX" then use "bt full" and send the output. -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger)
[PR] Add missing string length for lua sticktable lookup
Dear list! Author: Nathan Neulinger Number of patches: 1 This is an automated relay of the Github pull request: Add missing string length for lua sticktable lookup Patch title(s): Add missing string length for lua sticktable lookup Link: https://github.com/haproxy/haproxy/pull/530 Edit locally: wget https://github.com/haproxy/haproxy/pull/530.patch && vi 530.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/530.patch | git am - Description: Consider moving this to smp_to_stkey - or at least adding a: ```if ( smp->data.u.str.data == 0 ) { static_table_key.key_len = strlen(smp->data.u.str.key); }``` equivalent to smp_to_stkey Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
stable-bot: Bugfixes waiting for a release 2.1 (17), 2.0 (13)
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 2.1.3 was issued on 2020-02-12. There are currently 17 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2020-02-21 - 4 MEDIUM, first one merged on 2020-02-21 - 12 MINOR, first one merged on 2020-02-21 Thus the computed ideal release date for 2.1.4 would be 2020-03-06, which is in one week or less. Last release 2.0.13 was issued on 2020-02-13. There are currently 13 patches in the queue cut down this way: - 1 MAJOR, first one merged on 2020-02-21 - 4 MEDIUM, first one merged on 2020-02-21 - 8 MINOR, first one merged on 2020-02-21 Thus the computed ideal release date for 2.0.14 would be 2020-03-06, which is in one week or less. The current list of patches in the queue is: - 2.0, 2.1 - MAJOR : http-ana: Always abort the request when a tarpit is triggered - 2.0, 2.1 - MEDIUM : muxes: Use the right argument when calling the destroy method. - 2.0, 2.1 - MEDIUM : shctx: make sure to keep all blocks aligned - 2.0, 2.1 - MEDIUM : ebtree: don't set attribute packed without unaligned access support - 2.0, 2.1 - MEDIUM : ssl: fix several bad pointer aliases in a few sample fetch functions - 2.0, 2.1 - MINOR : http: http-request replace-path duplicates the query string - 2.0, 2.1 - MINOR : http-ana: Matching on monitor-uri should be case-sensitive - 2.0, 2.1 - MINOR : sample: Make sure to return stable IDs in the unique-id fetch - 2.0, 2.1 - MINOR : namespace: avoid closing fd when socket failed in my_socketat - 2.0, 2.1 - MINOR : sample: fix the json converter's endian-sensitivity - 2.1 - MINOR : mux-fcgi: Forbid special characters when matching PATH_INFO param - 2.1 - MINOR : http-htx: Don't return error if authority is updated without changes - 2.0, 2.1 - MINOR : filters: Count HTTP headers as filtered data but don't forward them - 2.1 - MINOR : http-htx: Do case-insensive comparisons on Host header name - 2.0, 2.1 - MINOR : dns: ignore trailing dot - 2.0, 2.1 - MINOR : connection: make sure to correctly tag local PROXY connections - 2.1 - MINOR : h2: reject again empty :path pseudo-headers -- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Segfault on 2.1.3
We've been running haproxy 1.8 series for quite a while. We're currently in the process of updating to 2.1, and have installed from the vbernat PPA on Ubuntu 18.04 using the same old config file. Now we are seeing segfaults a few times a day: Mar 03 14:53:52 fw1.dev.realgo.com kernel: haproxy[8654]: segfault at 18 ip 56389a674d08 sp 7fac18dba030 error 4 in haproxy[56389a52b000+235000] Mar 03 14:53:52 fw1.dev.realgo.com haproxy[8649]: [ALERT] 062/145352 (8649) : Current worker #1 (8653) exited with code 139 (Segmentation fault) Mar 03 14:53:52 fw1.dev.realgo.com haproxy[8649]: [ALERT] 062/145352 (8649) : exit-on-failure: killing every processes with SIGTERM Mar 03 14:53:52 fw1.dev.realgo.com haproxy[8649]: [WARNING] 062/145352 (8649) : All workers exited. Exiting... (139) Mar 03 14:53:52 fw1.dev.realgo.com systemd[1]: haproxy.service: Main process exited, code=exited, status=139/n/a Mar 03 14:53:52 fw1.dev.realgo.com systemd[1]: haproxy.service: Failed with result 'exit-code'. Looks like it is restarting 5-10 times a day during the work week, less during the weekend where only our monitoring system is hitting it. I haven't tried disabling htx, which the other recent Segfault thread said resolved it. I'm currently trying reverting down to 2.0.13. I'm happy to provide the config if that helps. It's 419 lines. Sean
[PATCH] limit cirrus-ci to stable freebsd images only
Hello, "snap" images are not usable. they break all the time. let us switch to freebsd-12.1 (the only available stable image) Cheers, Ilya Shipitcin From 19206e40c7f7d7bbef014a660fc2060f3882a9de Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Wed, 4 Mar 2020 01:18:02 +0500 Subject: [PATCH] BUILD: cirrus-ci: get rid of unstable freebsd images the only stable available freebsd image on cirrus is 12.1 let us drop all "snap" images, they are unusable for running tests because of being fragile --- .cirrus.yml | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/.cirrus.yml b/.cirrus.yml index 86b404782..982773467 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -1,14 +1,10 @@ FreeBSD_task: freebsd_instance: matrix: - image_family: freebsd-13-0-snap - image_family: freebsd-12-1-snap - image_family: freebsd-11-3-snap + image_family: freebsd-12-1 only_if: $CIRRUS_BRANCH =~ 'master|next' - env: -IGNORE_OSVERSION: yes # supress package installation error on FreeBSD-13 install_script: -- pkg update -f && pkg upgrade -y && pkg install -y openssl git gmake lua53 socat +- pkg update -f && pkg upgrade -y && pkg install -y openssl111 git gmake lua53 socat script: - git clone https://github.com/VTest/VTest.git ../vtest - make -C ../vtest -- 2.24.1
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
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: Log IP and port from haproxy to server
Thanks I was not looking at the proper documentation. El mar., 3 mar. 2020 a las 17:33, Tim Düsterhus () escribió: > > Pepe, > > Am 03.03.20 um 17:28 schrieb Pepe Charli: > > In "mode tcp", Is it possible to log the IP and port from haproxy to > > server (haproxyIP and haproxPort)? > > > > clientIP:ClientPort- > frontendIP:frontendPort > > haproxyIP:haproxyPort -> serverIP:serverPort > > %ci:%cp %fi:%fp > > %??:%?? %si:%sp > > > > This should be possible with %bi and %bp: > > > | | %bi | backend_source_ip (connecting address) | IP | > > | | %bp | backend_source_port (connecting address) | numeric | > (from http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#8.2.4) > > Best regards > Tim Düsterhus
Re: Log IP and port from haproxy to server
Pepe, Am 03.03.20 um 17:28 schrieb Pepe Charli: > In "mode tcp", Is it possible to log the IP and port from haproxy to > server (haproxyIP and haproxPort)? > > clientIP:ClientPort- > frontendIP:frontendPort > haproxyIP:haproxyPort -> serverIP:serverPort > %ci:%cp %fi:%fp > %??:%?? %si:%sp > This should be possible with %bi and %bp: > | | %bi | backend_source_ip (connecting address) | IP | > | | %bp | backend_source_port (connecting address) | numeric | (from http://cbonte.github.io/haproxy-dconv/2.1/configuration.html#8.2.4) Best regards Tim Düsterhus
Log IP and port from haproxy to server
In "mode tcp", Is it possible to log the IP and port from haproxy to server (haproxyIP and haproxPort)? clientIP:ClientPort- > frontendIP:frontendPort haproxyIP:haproxyPort -> serverIP:serverPort %ci:%cp %fi:%fp %??:%?? %si:%sp Thanks,
Re: mirroragent (haproxy)
Le 03/03/2020 à 14:39, Tuktamyshev Ainur a écrit : Dear, Collegues. There was a problem when mirroring traffic through Haproxy. In our spoa-mirror logs next mistakes: [ 0][0.000600] --- start --- 2020-03-03 15:48:30 - [ 1][ 318.942594] <1:26> (E) Failed to receive frame data: Stale file handle [ 2][ 416.600422] <2:26> (E) Failed to send frame length: Broken pipe [ 8][ 698.488390] <8:29> (E) Failed to send frame length: Broken pipe [ 5][ 698.677793] <5:26> (E) Failed to send frame length: Broken pipe [ 9][ 698.871186] <9:30> (E) Failed to send frame length: Broken pipe [ 7][ 699.071718] <7:28> (E) Failed to send frame length: Broken pipe [10][ 699.391399] <10:31> (E) Failed to send frame length: Broken pipe [ 6][ 699.585724] <6:27> (E) Failed to send frame length: Broken pipe [ 1][ 699.791090] <11:32> (E) Failed to send frame length: Broken pipe Haproxy version: "HA-Proxy version 2.1.0 2019/11/25" Can you help with this? If necessary, provide additional information. Hi, First of all, could you provide following info please ? * "haproxy -vv" output * haproxy configuration * spoa-mirror version * spoa-mirror configuration * If possible, info about the mirror requests -- Christopher Faulet
[PATCH] MINOR: ssl: add "ca-no-names-file" directive
rebase from dev branch:(https://github.com/haproxy/haproxy/issues/404)++ManuLe 20 déc. 2019 à 17:00, Emmanuel Hocdeta écrit :patch update,Le 19 déc. 2019 à 17:08, Emmanuel Hocdet a écrit :With this proposition, ca-root-file should be rename to something like ca-end-file.Refer to https://github.com/haproxy/haproxy/issues/404 discussion.Le 19 déc. 2019 à 13:10, Emmanuel Hocdet a écrit :Hi,The purpose of this patch is to fix #404 and keep compatibility with actual"ca-file » directive for bind line. 0001-MINOR-ssl-add-ca-no-names-file-directive.patch Description: Binary data
interpreting haproxy 2.1 EOL statement
Hi, >From the following: $ ~/git.haproxy.org/haproxy-2.1/haproxy -v HA-Proxy version 2.1.3-ce757f-13 2020/02/21 - https://haproxy.org/ Status: stable branch - will stop receiving fixes around Q1 2021. Known bugs: http://www.haproxy.org/bugs/bugs-2.1.3.html that EOL is around Q1 2021. Broadly, when is that? Jan-March 2021? TIA
mirroragent (haproxy)
Dear, Collegues. There was a problem when mirroring traffic through Haproxy. In our spoa-mirror logs next mistakes: [ 0][0.000600] --- start --- 2020-03-03 15:48:30 - [ 1][ 318.942594] <1:26> (E) Failed to receive frame data: Stale file handle [ 2][ 416.600422] <2:26> (E) Failed to send frame length: Broken pipe [ 8][ 698.488390] <8:29> (E) Failed to send frame length: Broken pipe [ 5][ 698.677793] <5:26> (E) Failed to send frame length: Broken pipe [ 9][ 698.871186] <9:30> (E) Failed to send frame length: Broken pipe [ 7][ 699.071718] <7:28> (E) Failed to send frame length: Broken pipe [10][ 699.391399] <10:31> (E) Failed to send frame length: Broken pipe [ 6][ 699.585724] <6:27> (E) Failed to send frame length: Broken pipe [ 1][ 699.791090] <11:32> (E) Failed to send frame length: Broken pipe Haproxy version: "HA-Proxy version 2.1.0 2019/11/25" Can you help with this? If necessary, provide additional information. -- Best regards. Tuktamyshev A.N. ph. +7-965-243-99-81
Re: Let's Encrypt ca-file for check-ssl on server line
Hi all. Thanks for help. Regards Aleks On 02.03.20 23:25, Tim Düsterhus wrote: Aleks, Am 02.03.20 um 23:19 schrieb Aleksandar Lazic: I think I found the solution. ``` curl -vO https://letsencrypt.org/certs/isrgrootx1.pem.txt curl -vo https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt curl -vO https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt cat letsencryptauthorityx3.pem.txt lets-encrypt-x3-cross-signed.pem.txt isrgrootx1.pem.txt > /etc/haproxy/letsencryptauthorityx3.pem ``` Now the server line is this. ``` server static_stor storage.sbg.cloud.ovh.net:443 resolvers mydns check check-ssl check-sni storage.sbg.cloud.ovh.net sni str(storage.sbg.cloud.ovh.net) ca-file /etc/haproxy/letsencryptauthorityx3.pem backup ``` No more SSL Handshake errors. Yes. The certificate chain OVH uses is the one chaining to IdenTrust (DST), not the one to ISRG. You can easily check this by looking up the TLS details within your favorite web browser. Best regards Tim Düsterhus