From version 4.4.0 of Artifactory, the ‘X-Artifactory-Override-Base-Url’ header is required on a reverse proxy configuration for Docker. The Docker login and other Docker commands will fail to work if the header below is not configured correctly (e.g. missing a port).
The line needs to include the server port number, as such:
proxy_set_header X-Artifactory-Override-Base-Url $http_x_forwarded_proto://$host:$server_port/<public context>;
proxy_set_header X-Artifactory-Override-Base-Url $http_x_forwarded_proto://$host:$server_port
proxy_set_header X-Artifactory-Override-Base-Url $http_x_forwarded_proto://$host:444/artifactory
Thank you so much. We use Apache as proxy and your tip did the trick.
Why aren't criminal changes like this documented in the release notes?
It's in the documentation - but it is not highlighted as a change since last version: Are you expected to read the entire documentation for every minor upgrade and figure out changes since last version by yourself?
If that's the case, I don't think Artifactory will survive for long within our organization...
I'm not in JFrog team, so I can't answer concretely to your question.
But I have signified this lack (about release note v4.4.0 & Apache config) to the JFrog support, I have received that these points will be improved.
About my "dockerHub remote fail ... investigations is progress" in my previous post: The repositories remotes works fine on an Artifactory v4.4.0 "clean" installation.
Perhaps I do something not clear in the upgrade process.
In all case, for users who have the same problem, I advise to redefine the company proxy and association with remote repositories.
Lars, did you ever manage to sort this out fully? I also got caught out with this update where everything else worked perfectly with the old method. I used to have artifactory.local and artifactory2.local, the latter would proxy to 192.168.100.10:8081/artifactory/api/docker/docker-local/
Since 4.3 or 4.4 this is now changed to only work with ports or subdomains. I am trying to work which the ports for simplicity with certs. I managed to get docker login to work as well as docker pull but docker push gives me TLS issues.
The push refers to a repository [artifactory.local:6555/demo/gowebserver] (len: 1)
adcb5120aceb: Pushing 1.024 kB
tls: oversized record received with length 20527
I never tried 4.4.1, but it works again with 4.4.2 - without the extra header.
The header caused endless troubles for us as the Docker client all of a sudden would try to connect to port 8081 (unencrypted) instead of 443 (encrypted). Port 8081 is closed in our internal firewall, so we could not update production servers from our internal Docker repository.
A real mess.
Fortunately, it works again. Let's hope it stays that way for a long time.
Whilst most of these options are mentioned in the Artifactory documentation, the "proxy-sendcl 1" is not as far as I can see. It is important, though, if you want to use your repository with Docker clients < 1.8.
I do not: If you add the header, the Docker client will try to connect directly to the Artifactory server at port 8081. This causes two problems: The traffic is unencrypted, and you need to open port 8081 in the firewall.
If you omit the header, all traffic is forced through the proxy at the SSL port. This gives better security and a port less to administrate in the firewall setup.
The hack was needed with Artifactory 4.4.0, but it appears to work without it again in 4.4.2.
Lars, no matter what I tried I could not get my setup to work. I ended up installing a clean Ubuntu server with 4.3.2 from the Jfrog deb packages and only then was I able to get docker push to work but only with nginx as a reverse proxy. No matter what I try when using apache I get the below error. It must be something I am missing, I've tried your suggestions and some historical ones I found for the docker private registry as well as artifactory.
This resulted in me having to change a lot of the workflows over to the nginx server.
No, I inderstand. Every setup is different, I'll keep at it. I've also gone to 4.4.3 with the new install as the release notes mentioned fixing issues with docker push which seems to have helped my installation just not the Apache part yet.
On Tue, 9 Feb 2016 at 15:34, Lars Skjærlund [via Artifactory] <[hidden email]> wrote:
Well - it works for me, so I'm afraid I cannot help you any further. It's hard to debug an error you cannot reproduce.
BTW, I'm testing 4.4.3 right now and it works with my Apache setup as well.
If you reply to this email, your message will be added to the discussion below: