Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

harbor.yml option for registry http.relativeurls / back-port fix for "unknown blob" issue from helm-chart to photon #12135

Open
problame opened this issue Jun 3, 2020 · 11 comments · May be fixed by #20339
Open

harbor.yml option for registry http.relativeurls / back-port fix for "unknown blob" issue from helm-chart to photon #12135

problame opened this issue Jun 3, 2020 · 11 comments · May be fixed by #20339
Assignees
@xaleeks
Labels
kind/requirement New feature or idea on top of harbor

Comments

@problame
Copy link

problame commented Jun 3, 2020

I am reverse-proxying an http-only deployment of harbor behind a manually-managed nginx proxy.

When pushing existing layers to the registry, I got the unknown blob error.

The workaround posted in goharbor/harbor-helm#174 (comment) is to set common/config/registry/config.yml http.relativeurls=true .

However, those changes get overriden when running ./install.sh.

This issue was previously discovered and fixed in the helm chart:
goharbor/harbor-helm#174 fixes

I think that this should be fixed in the docker-compose.yml deploy as well, either automatically (by detecting if harbor.yml external_url is set, or through another option in harbor.yml.

manually-managed (=external) nginx.conf

...
    location / {
      client_max_body_size 0;
      chunked_transfer_encoding on;
      proxy_buffering off;
      proxy_request_buffering off;
      proxy_http_version 1.1;
      proxy_pass                          http://127.0.0.1:7000;
      proxy_set_header  Host              $http_host;   # required for docker client's sake
      proxy_set_header  X-Real-IP         $remote_addr; # pass on real client's IP
      proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
      proxy_set_header  X-Forwarded-Proto $scheme;
    }
...

harbor.yml

http:
  port: 127.0.0.1:7000                                                                                        

#https:                                                                                                                 
#  # https port for harbor, default is 443                                                                   
#  port: 443                                                                                                        
#  # The path of cert and key files for nginx     
#  certificate: /your/certificate/path
#  private_key: /your/private/key/path         

external_url: https://registry.example.com

harbor release: v2.0.0
@reasonerjt reasonerjt added the needs/triage triage issue before assigning label Jun 5, 2020
@reasonerjt
Copy link
Contributor

I understand the problem and the fix

But I personally think we have to refrain from adding too many options to the installer to satisfy all kinds of customization.

We'll discuss it, but can't commit to fix it in the short term.

@ninjadq ninjadq added kind/requirement New feature or idea on top of harbor and removed needs/triage triage issue before assigning labels Jun 22, 2020
@neur0manc
Copy link

Having harbor (or any kind of service for that matter) behind a proxy or firewall is a really common practice. Thus it really would make sense to add that setting to harbor.yml so our setups don't potentially break every ./prepare run. Of course, there a ways around this, but harbor.yml is objectively the place were this should be handled.

So, please add this feature. 👍

@zimmski
Copy link

zimmski commented Dec 22, 2020

I can only agree that this is a major problem. Basically we have to change the default with every update/upgrade. Why not change it in the default template when there is no downside in setting it? The upside is that it works out-of-the-box for more setups.

The only thing that we needed to add to the "goharbor/registry-photon" container in the docker-compose file:

environment:
  - REGISTRY_HTTP_RELATIVEURLS=true

However, it makes much more sense to add this as an option in case it has some downside. Allowing that in the Helm Chart but not in the docker-compose file looks to me like a mishap because the argument is then invalid to not allow too many options becauase the option is already in the Helm chart but not in the docker-compose file.

Say the word and i will do the PR if that is what is the problem.

@ChristianCiach
Copy link

Maybe this can be fixed in a more abstract manner. For example, maybe install.sh could be given a path to a directory containing .patch files that are automatically applied whenever install.sh runs. This could be used to automate all kinds of customizations.

In this specific case though, I agree that http.relativeurls is such an essential option for people who run their own reverse proxies that this option should be included in harbor.yml, maybe even as a default.

@llitfkitfk
Copy link

llitfkitfk commented Mar 17, 2021 •
edited

resolved v2.2.0
#12959 #12364

I can only agree that this is a major problem. Basically we have to change the default with every update/upgrade. Why not change it in the default template when there is no downside in setting it? The upside is that it works out-of-the-box for more setups.

The only thing that we needed to add to the "goharbor/registry-photon" container in the docker-compose file:

environment:
  - REGISTRY_HTTP_RELATIVEURLS=true

However, it makes much more sense to add this as an option in case it has some downside. Allowing that in the Helm Chart but not in the docker-compose file looks to me like a mishap because the argument is then invalid to not allow too many options becauase the option is already in the Helm chart but not in the docker-compose file.

Say the word and i will do the PR if that is what is the problem.

@ChristianCiach
Copy link

ChristianCiach commented Jul 21, 2021 •
edited

@llitfkitfk How is this resolved? Harbor still doesn't allow us to set http.relativeurls for the registry.

@discostur
Copy link

Just did a new install with harbor v2.4.1 - problem still exists!

@discostur
Copy link

Ok i added the

Header add X-Forwarded-Proto "https"

header to my proxy conf and now everything is working like expected +1

@github-actions
Copy link

github-actions bot commented Jul 7, 2022

This issue is being marked stale due to a period of inactivity. If this issue is still relevant, please comment or remove the stale label. Otherwise, this issue will close in 30 days.

@github-actions github-actions bot added Stale and removed Stale labels Jul 7, 2022
@SinguJ SinguJ mentioned this issue May 29, 2023
Closed
@leowzz
Copy link

leowzz commented Jan 16, 2024

Ok i added the

Header add X-Forwarded-Proto "https"

header to my proxy conf and now everything is working like expected +1

Thanks, I solved my problem by this

@tahacodes tahacodes linked a pull request Apr 23, 2024 that will close this issue
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@xaleeks xaleeks

Labels
kind/requirement New feature or idea on top of harbor
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Support registry http.relativeurls in harbor.yml tahacodes/harbor
11 participants
@neur0manc @problame @ninjadq @zimmski @reasonerjt @llitfkitfk @discostur @ChristianCiach @xaleeks @leowzz and others