Re: Wording in home page
Hi Julien, On Wed, Dec 23, 2020 at 04:06:06PM +0100, Julien Pivotto wrote: > Dear list, > > on http://www.haproxy.org/ : > > > We always support at least two active versions in parallel and an extra > > old one in critical fixes mode only. The currently supported versions > > are : > > Then, all releases to 1.5 are listed. I think we don't support 1.5 > anymore :) Indeed :-) > Could someone fix the wording? I'll keep it in mind when issuing the last 1.6. Thanks, Willy
Re: [*EXT*] Re: haproxy hiding url/minio
On Thu, Dec 24, 2020 at 06:04:05PM +0500, ??? wrote: > as far as I recall, AWS4 uses digitally signed several headers. if you > change some of those headers, security is broken so you get 401. > I'm not sure it allows to change URL on the fly or not. > > but I recall proxying S3 pretty complicated task. > > should we document best practices how to reverse proxy S3 ? Probably. Another useful thing to put into the wiki. Willy
Re: haproxy hiding url/minio
Hi Jonathan, On Thu, Dec 24, 2020 at 02:52:23PM +1300, Jonathan Opperman wrote: > > Should it be: > > > > http-request set-path %[url,regsub(^/storage,/minio)] > > > > ? > > > > Cheers > > Jonathan > > > > Answering myself here, it is, and it works :) Be careful, set-path only sets the path component, but "url" returns the URI as received. For H1 you'll most often see the same thing as the path, but you could also have absolute URIs. For H2 you'll always have absolute URIs. I suggest that you use %[path,regsub...] instead. This way you set the path to the previous path on which you apply a transformation, which is what you want to do. Willy
Re: [PATCH] enable coverity daily scan again
I modified patch to run against my own coverity repo 'chipitsine/haproxy'
Tim, can you have a look ?
https://github.com/chipitsine/haproxy/actions/runs/443552484
чт, 24 дек. 2020 г. в 17:41, Илья Шипицин :
> Willy, patch is good. Let us apply that.
>
> чт, 24 дек. 2020 г. в 16:44, Tim Düsterhus :
>
>> Ilya,
>>
>> Am 24.12.20 um 03:53 schrieb Илья Шипицин:
>> > I particularly like this one:
>> >
>> > if: ${{ env.COVERITY_SCAN_TOKEN != '' }}
>> >
>> >
>> > can it be done job wide ? i.e. nothing should start, neither checkout,
>> nor
>> > job itself if token is not set (which is true for forks)
>>
>> Yes, I think it is possible:
>>
>> https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif
>>
>> By the way: I don't think secrets are exposed via environment variables
>> automatically. You would need to pass them explicitly. See:
>>
>> https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets#using-encrypted-secrets-in-a-workflow
>>
>> I've attached an updated patch that I believe does the correct thing:
>>
>> 1. The `if` is on the job level now.
>> 2. It takes the secret from the `secrets` variable and passes it as the
>> `env` for the actual step.
>>
>> Can you test this in your repository, please?
>>
>> >
>> > Also, Tim, I've forgotten to limit builds to "master" branch. Should we
>> > add some condition as well to prevent coverity scan for other branches ?
>> >
>>
>> According to the documentation
>> (
>> https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#schedule
>> )
>> any workflows that are triggered by a schedule will run on the default
>> branch (i.e. `master`). So I don't think we need to change anything for
>> that.
>>
>> Best regards
>> Tim Düsterhus
>>
>
Re: [*EXT*] Re: haproxy hiding url/minio
as far as I recall, AWS4 uses digitally signed several headers. if you change some of those headers, security is broken so you get 401. I'm not sure it allows to change URL on the fly or not. but I recall proxying S3 pretty complicated task. should we document best practices how to reverse proxy S3 ? чт, 24 дек. 2020 г. в 18:01, Ionel GARDAIS : > 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: 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: [PATCH] enable coverity daily scan again
Willy, patch is good. Let us apply that.
чт, 24 дек. 2020 г. в 16:44, Tim Düsterhus :
> Ilya,
>
> Am 24.12.20 um 03:53 schrieb Илья Шипицин:
> > I particularly like this one:
> >
> > if: ${{ env.COVERITY_SCAN_TOKEN != '' }}
> >
> >
> > can it be done job wide ? i.e. nothing should start, neither checkout,
> nor
> > job itself if token is not set (which is true for forks)
>
> Yes, I think it is possible:
>
> https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif
>
> By the way: I don't think secrets are exposed via environment variables
> automatically. You would need to pass them explicitly. See:
>
> https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets#using-encrypted-secrets-in-a-workflow
>
> I've attached an updated patch that I believe does the correct thing:
>
> 1. The `if` is on the job level now.
> 2. It takes the secret from the `secrets` variable and passes it as the
> `env` for the actual step.
>
> Can you test this in your repository, please?
>
> >
> > Also, Tim, I've forgotten to limit builds to "master" branch. Should we
> > add some condition as well to prevent coverity scan for other branches ?
> >
>
> According to the documentation
> (
> https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#schedule
> )
> any workflows that are triggered by a schedule will run on the default
> branch (i.e. `master`). So I don't think we need to change anything for
> that.
>
> Best regards
> Tim Düsterhus
>
Re: [PATCH] enable coverity daily scan again
чт, 24 дек. 2020 г. в 16:44, Tim Düsterhus :
> Ilya,
>
> Am 24.12.20 um 03:53 schrieb Илья Шипицин:
> > I particularly like this one:
> >
> > if: ${{ env.COVERITY_SCAN_TOKEN != '' }}
> >
> >
> > can it be done job wide ? i.e. nothing should start, neither checkout,
> nor
> > job itself if token is not set (which is true for forks)
>
> Yes, I think it is possible:
>
> https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif
>
> By the way: I don't think secrets are exposed via environment variables
> automatically. You would need to pass them explicitly. See:
>
> https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets#using-encrypted-secrets-in-a-workflow
I specified COVERITY_SCAN_TOKEN in my github fork, indeed it was not
exposed.
I thought it might be due to variables are not exposed for forks
(documentation is not very clear).
I tested in my fork using "export COVERITY_SCAN_TOKEN=."
I'm ok with not specifiyn secrets in a file, but in github variables
instead. if so, every fork will skip that pipeline (good thing).
>
>
> I've attached an updated patch that I believe does the correct thing:
>
> 1. The `if` is on the job level now.
> 2. It takes the secret from the `secrets` variable and passes it as the
> `env` for the actual step.
>
> Can you test this in your repository, please?
>
> >
> > Also, Tim, I've forgotten to limit builds to "master" branch. Should we
> > add some condition as well to prevent coverity scan for other branches ?
> >
>
> According to the documentation
> (
> https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#schedule
> )
> any workflows that are triggered by a schedule will run on the default
> branch (i.e. `master`). So I don't think we need to change anything for
> that.
>
> Best regards
> Tim Düsterhus
>
Re: [PATCH] enable coverity daily scan again
Ilya, Am 24.12.20 um 04:13 schrieb Илья Шипицин: > I'm not sure for Github Actions, we use the following in gitlab for > limiting jobs to parent repo only (i.e. no forks allowed). Is there similar > thing in Github Actions ? > > only:refs: - master@haproxy/haproxy > I don't think so. But my understanding is that the job won't run on pull requests and with the new `job` level `if` I added in response to your other mail it should automatically be skipped on forks. So there is no useless running in forks and it will not leak the token either. Best regards Tim Düsterhus
Re: [PATCH] enable coverity daily scan again
Ilya,
Am 24.12.20 um 03:53 schrieb Илья Шипицин:
> I particularly like this one:
>
> if: ${{ env.COVERITY_SCAN_TOKEN != '' }}
>
>
> can it be done job wide ? i.e. nothing should start, neither checkout, nor
> job itself if token is not set (which is true for forks)
Yes, I think it is possible:
https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif
By the way: I don't think secrets are exposed via environment variables
automatically. You would need to pass them explicitly. See:
https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets#using-encrypted-secrets-in-a-workflow
I've attached an updated patch that I believe does the correct thing:
1. The `if` is on the job level now.
2. It takes the secret from the `secrets` variable and passes it as the
`env` for the actual step.
Can you test this in your repository, please?
>
> Also, Tim, I've forgotten to limit builds to "master" branch. Should we
> add some condition as well to prevent coverity scan for other branches ?
>
According to the documentation
(https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#schedule)
any workflows that are triggered by a schedule will run on the default
branch (i.e. `master`). So I don't think we need to change anything for
that.
Best regards
Tim Düsterhus
From 63ed5405668799f45b65a9f3ba4a825c549996d5 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Thu, 24 Dec 2020 01:18:04 +0500
Subject: [PATCH] CI: GitHub Actions: enable daily Coverity scan
That scan was previously implemented on Travis. Let us migrate
it to GitHub Actions.
Co-authored-by: Tim Duesterhus
---
.github/workflows/coverity.yml | 29 +
1 file changed, 29 insertions(+)
create mode 100644 .github/workflows/coverity.yml
diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
new file mode 100644
index 0..0b75ecef2
--- /dev/null
+++ b/.github/workflows/coverity.yml
@@ -0,0 +1,29 @@
+name: Coverity
+
+on:
+ schedule:
+ - cron: "0 0 * * *"
+
+jobs:
+ scan:
+runs-on: ubuntu-latest
+if: ${{ secrets.COVERITY_SCAN_TOKEN != '' }}
+env:
+ COVERITY_SCAN_PROJECT_NAME: 'Haproxy'
+ COVERITY_SCAN_BRANCH_PATTERN: '*'
+ COVERITY_SCAN_NOTIFICATION_EMAIL: 'chipits...@gmail.com'
+ COVERITY_SCAN_BUILD_COMMAND: "make CC=clang DEFINE=-DDEBUG_USE_ABORT TARGET=linux-glibc USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 USE_OPENSSL=1 USE_SYSTEMD=1 USE_WURFL=1 WURFL_INC=contrib/wurfl WURFL_LIB=contrib/wurfl USE_DEVICEATLAS=1 DEVICEATLAS_SRC=contrib/deviceatlas USE_51DEGREES=1 51DEGREES_SRC=contrib/51d/src/pattern DEBUG_STRICT=1"
+steps:
+- uses: actions/checkout@v2
+- name: Install apt dependencies
+ run: |
+sudo apt-get update
+sudo apt-get install -y \
+ liblua5.3-dev \
+ libsystemd-dev
+- name: Run Coverity Scan
+ env:
+COVERITY_SCAN_TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }}
+ run: |
+make -C contrib/wurfl
+curl -fsSL "https://scan.coverity.com/scripts/travisci_build_coverity_scan.sh; | bash
--
2.29.0
