I have a Vagrantfile with config.vm.box_url containing a link to a box in an Artifactory. ATLAS_TOKEN and also VAGRANT_SERVER_URL is set, but I get a 403 while starting vagrant up.
At the logfile, you see that the GET-Request with curl does not contain the token. The previously HEAD-request is successful with the token.
1.8.4
Windows 7
CentOS7-1511
ENV['VAGRANT_SERVER_URL'] = "https://xxx/artifactory/api/vagrant"
ENV['ATLAS_TOKEN'] = "xxxxx"
nodes_config = (JSON.parse(File.read("nodes.json")))['nodes']
Vagrant.configure(2) do |config|
config.vm.box = "box_centos7"
config.vm.box_url = "https://xxx/artifactory/api/vagrant/path/box_centos7-x86_64.box
nodes_config.each do |node|
...
end
end
https://gist.github.com/cogidoo/b981caf24d10f89e77408f93ef36f1e9
Retrieve the box from artifactory and add it to the local repository.
HTTP 403 while downloading the box.
ATLAS_TOKEN and a direct link to the box: config.vm.box_urlHi @cogidoo
Thank you for opening an issue. Are you serving metadata using Artifactory?
Yes, but I thought that this is not relevant because of the direct specification of the config.vm.box_url ?!
Hi @cogidoo
Unfortunately I don't have access to artifactory or the expertise required to set it up. I think we are going to have to rely on the community to test a fix for this.
One thing I forgot to mention:
box add --name my_box http:\\xxx/artifactory/api/vagrant/my_repo/my_box.box
results in the same 403-error. But, with VAGRANT_SERVER_URL and ATLAS_TOKEN set as environment variable, box-adding using the box-name works:
box add my_repo/my_boxname
Unfortunately, when I use my_repo/my_boxname at the Vagrantfile I get this:
Bringing machine 'box' up with 'virtualbox' provider...
==> box: Box 'my_repo/my_boxname' could not be found. Attempting to find and install...
box: Box Provider: virtualbox
box: Box Version: >= 0
==> box: Loading metadata for box 'my_repo/my_boxname'
box: URL: https://xxx/artifactory/api/vagrant/my_repo/my_boxname
The box you're adding has a name different from the name you
requested. For boxes with metadata, you cannot override the name.
If you're adding a box using `vagrant box add`, don't specify
the `--name` parameter. If the box is being added via a Vagrantfile,
change the `config.vm.box` value to match the name below.
Requested name: my_repo/my_boxname
Actual name: my_boxname
So I change the config.vm.box to my_boxname and get this:
Bringing machine 'box' up with 'virtualbox' provider...
==> box: Box 'my_boxname' could not be found. Attempting to find and install...
box: Box Provider: virtualbox
box: Box Version: >= 0
==> box: Box file was not detected as metadata. Adding it directly...
==> box: Adding box 'my_boxname' (v0) for provider: virtualbox
box: Downloading: my_boxname
box:
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.
Couldn't open file /path/to/my/vagrant-file/my_boxname
This is probably due to a bug in Artifactory. You can NOT have any slashes / in your box name with Artifactory. This fails regardless of whether it shows up in the metadata or not, Artifactory tries to interpret the slashes first and fails to "find" the box in the path where it expected it. Your best bet is to use underscores or hyphens to separate the namespaces if you are using Artifactory.
I do not have any slashes within the name of the box or my repository. If there are any slashes in my examples above then they are a part of the path to the box or when I use <repository_name>/<box_name>
I think the problem might be that you have set config.vm.box_url to point directly to a particular box file.
If the direct URL to the box is https://xxx/artifactory/api/vagrant/path/box_centos7-x86_64.box and your box has the name box_centos7, then the value of the config.vm.box_url property should be https://xxx/artifactory/api/vagrant/path/box_centos7.
If you open that URL in a browser, you should get back some JSON which includes a link to the box file itself. I got this to work for me, and I didn't even need to set VAGRANT_SERVER_URL or ATLAS_TOKEN, but that's likely because anonymous users can download boxes from our Artifactory installation
I'm running into this problem as well.
According to https://www.jfrog.com/confluence/display/RTF/Vagrant+Repositories it should be enough to put the base64 encoded username:pass into an environment variable named ATLAS_TOKEN, I've done that and it doesn't work (I'm getting a "401 Unauthorized" reply however).
Looking at the debug log from my vagrant up command, it looks like it's calling cURL but it's doesn't look like it's actually providing any access credentials though. I found a bug about this in the Artifactory JIRA and commented on this there:
https://www.jfrog.com/jira/browse/RTFACT-9843
INFO subprocess: Starting process: ["/opt/vagrant/embedded/bin/curl", "-q", "--fail", "--location", "--max-redirs", "10", "--user-agent", "Vagrant/1.9.5 (+https://www.vagrantup.com; ruby2.2.5)", "--continue-at", "-", "--output", "/Users/stefan/.vagrant.d/tmp/box<boxid>", "https://our.artifactory.server.com/artifactory/vagrant-local/our_virtualbox_file1.0.virtualbox.box"]
Of course, vagrant might just not be logging the credentials out, but I don't think that's the case. At least it doesn't seem to be sending any credentials out with the cURL command because if I run the following command from my terminal, it downloads the artifact just fine:
curl -uusername:password https://our.artifactory.server.com/artifactory/vagrant-local/our_virtualbox_file1.0.virtualbox.box
And just to be clear, I've tested this for both the URL above as well as going through the "API URL":
curl -uusername:password https://our.artifactory.server.com/artifactory/api/vagrant/vagrant-local/our_virtualbox_file1.0.virtualbox.box
Both of the above cURL commands work fine but neither URL works when I put it in my Vagrantfile.
Thank you @marcjay ! That's the solution. With the following lines from my initial comment it works:
config.vm.box = "box_centos7"
config.vm.box_url = "https://xxx/artifactory/api/vagrant/path/box_centos7
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.