You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Nick Allen <ni...@nickallen.org> on 2018/02/05 13:45:38 UTC
[DISCUSS] The requested URL returned error: 404 Not Found
When launching either of the development environments, you are probably
seeing a warning message like this.
Bringing machine 'node1' up with 'virtualbox' provider...
> ...
> ==> node1: There was a problem while downloading the metadata for your box
> ==> node1: to check for updates. This is not an error, since it is usually
> due
> ==> node1: to temporary network problems. This is just a warning. The
> problem
> ==> node1: encountered was:
> ==> node1:
> ==> node1: The requested URL returned error: 404 Not Found
> ==> node1:
> ==> node1: If you want to check for box updates, verify your network
> connection
> ==> node1: is valid and try again.
I believe the problem is that Hashicorp has chosen to no longer host the
base images that we rely on (outside of paying enterprise customers.)
The Packer, Artifact Registry and Terraform Enterprise (Legacy) features of
> Atlas will no longer be actively developed or maintained and will be fully
> decommissioned on Friday, March 30, 2018. Please see our guide on building
> immutable infrastructure with Packer on CI/CD for ideas on implementing
> Packer and Artifact Registry features yourself and the Upgrading From
> Terraform Enterprise (Legacy) guide to migrate to the new Terraform
> Enterprise.
If you already have the base images downloaded, do not delete them! The
development environments will continue to work as long as you have those
images.
The problem is that new users will no longer be able to download these
images. And ultimately I am suspect that future updates will occur on
these base images.
Is everyone experiencing this problem? Does anyone have any other details
to share on this?
I am concerned that this is going to force us into some significant work in
the short-term to ensure that our development environments continue to
work. I have some alternative options to discuss, but I want to make sure
we have all the information on what's happening before discussing those.
Re: [DISCUSS] The requested URL returned error: 404 Not Found
Posted by Michael Miklavcic <mi...@gmail.com>.
Hm, now that is interesting. I'm not clear how they manage their URLs, but
it seems like they may have missed a hardcoded value used by their update
functionality.
On Feb 5, 2018 3:01 PM, "Nick Allen" <ni...@nickallen.org> wrote:
> I was experiencing this issue with both Ansible 1.8.1 and 2.0.2.
>
> I just found that now it seems to only spit out that warning when checking
> for updates; not when downloading new images. If I remove the older image
> to force it to re-download, it does seem to work. But after re-downloading
> the image, it gets an error checking to see if the image is up-to-date.
>
> I have no idea what's going on, but at least it doesn't seem to be
> hindering our development environments... yet.
>
>
> $ cd ~/Development/metron/metron-deployment/development/ubuntu14
> $ vagrant box outdated
> /Users/nallen/Development/metron/metron-deployment/development/ubuntu14/
> Vagrantfile:28:
> warning: constant ::TRUE is deprecated
> Running with ansible-skip-tags: ["sensors"]
> DEPRECATION: The 'sudo' option for the Ansible provisioner is deprecated.
> Please use the 'become' option instead.
> The 'sudo' option will be removed in a future release of Vagrant.
>
> Checking if box 'ubuntu/trusty64' is up to date...
> There was a problem while downloading the metadata for your box
> to check for updates. This is not an error, since it is usually due
> to temporary network problems. This is just a warning. The problem
> encountered was:
>
> The requested URL returned error: 404 Not Found
>
> If you want to check for box updates, verify your network connection
> is valid and try again.
>
>
> $ vagrant box remove ubuntu/trusty64 --all
>
>
> $ vagrant up
> /Users/nallen/Development/metron/metron-deployment/development/ubuntu14/
> Vagrantfile:28:
> warning: constant ::TRUE is deprecated
> Running with ansible-skip-tags: ["sensors"]
> DEPRECATION: The 'sudo' option for the Ansible provisioner is deprecated.
> Please use the 'become' option instead.
> The 'sudo' option will be removed in a future release of Vagrant.
>
> Bringing machine 'node1' up with 'virtualbox' provider...
> ==> node1: Box 'ubuntu/trusty64' could not be found. Attempting to find and
> install...
> node1: Box Provider: virtualbox
> node1: Box Version: >= 0
> ==> node1: Loading metadata for box 'ubuntu/trusty64'
> node1: URL: https://vagrantcloud.com/ubuntu/trusty64
> ==> node1: Adding box 'ubuntu/trusty64' (v20180125.0.0) for provider:
> virtualbox
> node1: Downloading: https://vagrantcloud.com/ubuntu/boxes/trusty64/
> versions/20180125.0.0/providers/virtualbox.box
> ==> node1: Successfully added box 'ubuntu/trusty64' (v20180125.0.0) for
> 'virtualbox'!
> ==> node1: Importing base box 'ubuntu/trusty64'...
> ==> node1: Matching MAC address for NAT networking...
> ==> node1: Checking if box 'ubuntu/trusty64' is up to date...
> ==> node1: There was a problem while downloading the metadata for your box
> ==> node1: to check for updates. This is not an error, since it is usually
> due
> ==> node1: to temporary network problems. This is just a warning. The
> problem
> ==> node1: encountered was:
> ==> node1:
> ==> node1: The requested URL returned error: 503 Service Unavailable
> ==> node1:
> ==> node1: If you want to check for box updates, verify your network
> connection
> ==> node1: is valid and try again.
> ==> node1: Setting the name of the VM: ubuntu14_node1_1517850259612_86441
> ==> node1: Clearing any previously set forwarded ports...
> ==> node1: Clearing any previously set network interfaces...
> ==> node1: Preparing network interfaces based on configuration...
> node1: Adapter 1: nat
> node1: Adapter 2: hostonly
> ==> node1: Forwarding ports...
> node1: 22 (guest) => 2222 (host) (adapter 1)
> ==> node1: Running 'pre-boot' VM customizations...
> ==> node1: Booting VM...
> ==> node1: Waiting for machine to boot. This may take a few minutes...
> node1: SSH address: 127.0.0.1:2222
> node1: SSH username: vagrant
> node1: SSH auth method: private key
>
>
>
>
> On Mon, Feb 5, 2018 at 11:48 AM, Michael Miklavcic <
> michael.miklavcic@gmail.com> wrote:
>
> > I had this problem on a machine running Vagrant 1.8.1. I thought it was
> > only Ubuntu at first, so I removed some additional boxes and found it to
> be
> > a problem for all of them. I didn't see any relevant articles other than
> > some old stuff talking about a bundled curl command being a problem, but
> > that didn't help anything. Not surprising since the URL being attempted
> > with curl didn't work via browser either. 404, as Nick mentioned.
> >
> > {17:08}~ ➭ vagrant box add hashicorp/precise64
> > The box 'hashicorp/precise64' could not be found or
> > could not be accessed in the remote catalog. If this is a private
> > box on HashiCorp's Atlas, please verify you're logged in via
> > `vagrant login`. Also, please double-check the name. The expanded
> > URL and error message are shown below:
> >
> > URL: ["https://atlas.hashicorp.com/hashicorp/precise64"]
> > Error: The requested URL returned error: 404 Not Found
> >
> > My last ditch attempt here was to upgrade Vagrant to 2.0.2. That seems to
> > have fixed it for me, but per their warning message I'm not sure if this
> > new location is permanent or if OSS Hashicorp Vagrant consumers need to
> > find an alternative. The new location appears to be
> > https://vagrantcloud.com
> > .
> >
> > Mike
> >
> >
> >
> > On Mon, Feb 5, 2018 at 6:45 AM, Nick Allen <ni...@nickallen.org> wrote:
> >
> > > When launching either of the development environments, you are probably
> > > seeing a warning message like this.
> > >
> > > Bringing machine 'node1' up with 'virtualbox' provider...
> > > > ...
> > > > ==> node1: There was a problem while downloading the metadata for
> your
> > > box
> > > > ==> node1: to check for updates. This is not an error, since it is
> > > usually
> > > > due
> > > > ==> node1: to temporary network problems. This is just a warning. The
> > > > problem
> > > > ==> node1: encountered was:
> > > > ==> node1:
> > > > ==> node1: The requested URL returned error: 404 Not Found
> > > > ==> node1:
> > > > ==> node1: If you want to check for box updates, verify your network
> > > > connection
> > > > ==> node1: is valid and try again.
> > >
> > >
> > >
> > > I believe the problem is that Hashicorp has chosen to no longer host
> the
> > > base images that we rely on (outside of paying enterprise customers.)
> > >
> > > The Packer, Artifact Registry and Terraform Enterprise (Legacy)
> features
> > of
> > > > Atlas will no longer be actively developed or maintained and will be
> > > fully
> > > > decommissioned on Friday, March 30, 2018. Please see our guide on
> > > building
> > > > immutable infrastructure with Packer on CI/CD for ideas on
> implementing
> > > > Packer and Artifact Registry features yourself and the Upgrading From
> > > > Terraform Enterprise (Legacy) guide to migrate to the new Terraform
> > > > Enterprise.
> > >
> > >
> > >
> > > If you already have the base images downloaded, do not delete them!
> The
> > > development environments will continue to work as long as you have
> those
> > > images.
> > >
> > > The problem is that new users will no longer be able to download these
> > > images. And ultimately I am suspect that future updates will occur on
> > > these base images.
> > >
> > > Is everyone experiencing this problem? Does anyone have any other
> > details
> > > to share on this?
> > >
> > > I am concerned that this is going to force us into some significant
> work
> > in
> > > the short-term to ensure that our development environments continue to
> > > work. I have some alternative options to discuss, but I want to make
> > sure
> > > we have all the information on what's happening before discussing
> those.
> > >
> >
>
Re: [DISCUSS] The requested URL returned error: 404 Not Found
Posted by Nick Allen <ni...@nickallen.org>.
I was experiencing this issue with both Ansible 1.8.1 and 2.0.2.
I just found that now it seems to only spit out that warning when checking
for updates; not when downloading new images. If I remove the older image
to force it to re-download, it does seem to work. But after re-downloading
the image, it gets an error checking to see if the image is up-to-date.
I have no idea what's going on, but at least it doesn't seem to be
hindering our development environments... yet.
$ cd ~/Development/metron/metron-deployment/development/ubuntu14
$ vagrant box outdated
/Users/nallen/Development/metron/metron-deployment/development/ubuntu14/Vagrantfile:28:
warning: constant ::TRUE is deprecated
Running with ansible-skip-tags: ["sensors"]
DEPRECATION: The 'sudo' option for the Ansible provisioner is deprecated.
Please use the 'become' option instead.
The 'sudo' option will be removed in a future release of Vagrant.
Checking if box 'ubuntu/trusty64' is up to date...
There was a problem while downloading the metadata for your box
to check for updates. This is not an error, since it is usually due
to temporary network problems. This is just a warning. The problem
encountered was:
The requested URL returned error: 404 Not Found
If you want to check for box updates, verify your network connection
is valid and try again.
$ vagrant box remove ubuntu/trusty64 --all
$ vagrant up
/Users/nallen/Development/metron/metron-deployment/development/ubuntu14/Vagrantfile:28:
warning: constant ::TRUE is deprecated
Running with ansible-skip-tags: ["sensors"]
DEPRECATION: The 'sudo' option for the Ansible provisioner is deprecated.
Please use the 'become' option instead.
The 'sudo' option will be removed in a future release of Vagrant.
Bringing machine 'node1' up with 'virtualbox' provider...
==> node1: Box 'ubuntu/trusty64' could not be found. Attempting to find and
install...
node1: Box Provider: virtualbox
node1: Box Version: >= 0
==> node1: Loading metadata for box 'ubuntu/trusty64'
node1: URL: https://vagrantcloud.com/ubuntu/trusty64
==> node1: Adding box 'ubuntu/trusty64' (v20180125.0.0) for provider:
virtualbox
node1: Downloading: https://vagrantcloud.com/ubuntu/boxes/trusty64/
versions/20180125.0.0/providers/virtualbox.box
==> node1: Successfully added box 'ubuntu/trusty64' (v20180125.0.0) for
'virtualbox'!
==> node1: Importing base box 'ubuntu/trusty64'...
==> node1: Matching MAC address for NAT networking...
==> node1: Checking if box 'ubuntu/trusty64' is up to date...
==> node1: There was a problem while downloading the metadata for your box
==> node1: to check for updates. This is not an error, since it is usually
due
==> node1: to temporary network problems. This is just a warning. The
problem
==> node1: encountered was:
==> node1:
==> node1: The requested URL returned error: 503 Service Unavailable
==> node1:
==> node1: If you want to check for box updates, verify your network
connection
==> node1: is valid and try again.
==> node1: Setting the name of the VM: ubuntu14_node1_1517850259612_86441
==> node1: Clearing any previously set forwarded ports...
==> node1: Clearing any previously set network interfaces...
==> node1: Preparing network interfaces based on configuration...
node1: Adapter 1: nat
node1: Adapter 2: hostonly
==> node1: Forwarding ports...
node1: 22 (guest) => 2222 (host) (adapter 1)
==> node1: Running 'pre-boot' VM customizations...
==> node1: Booting VM...
==> node1: Waiting for machine to boot. This may take a few minutes...
node1: SSH address: 127.0.0.1:2222
node1: SSH username: vagrant
node1: SSH auth method: private key
On Mon, Feb 5, 2018 at 11:48 AM, Michael Miklavcic <
michael.miklavcic@gmail.com> wrote:
> I had this problem on a machine running Vagrant 1.8.1. I thought it was
> only Ubuntu at first, so I removed some additional boxes and found it to be
> a problem for all of them. I didn't see any relevant articles other than
> some old stuff talking about a bundled curl command being a problem, but
> that didn't help anything. Not surprising since the URL being attempted
> with curl didn't work via browser either. 404, as Nick mentioned.
>
> {17:08}~ ➭ vagrant box add hashicorp/precise64
> The box 'hashicorp/precise64' could not be found or
> could not be accessed in the remote catalog. If this is a private
> box on HashiCorp's Atlas, please verify you're logged in via
> `vagrant login`. Also, please double-check the name. The expanded
> URL and error message are shown below:
>
> URL: ["https://atlas.hashicorp.com/hashicorp/precise64"]
> Error: The requested URL returned error: 404 Not Found
>
> My last ditch attempt here was to upgrade Vagrant to 2.0.2. That seems to
> have fixed it for me, but per their warning message I'm not sure if this
> new location is permanent or if OSS Hashicorp Vagrant consumers need to
> find an alternative. The new location appears to be
> https://vagrantcloud.com
> .
>
> Mike
>
>
>
> On Mon, Feb 5, 2018 at 6:45 AM, Nick Allen <ni...@nickallen.org> wrote:
>
> > When launching either of the development environments, you are probably
> > seeing a warning message like this.
> >
> > Bringing machine 'node1' up with 'virtualbox' provider...
> > > ...
> > > ==> node1: There was a problem while downloading the metadata for your
> > box
> > > ==> node1: to check for updates. This is not an error, since it is
> > usually
> > > due
> > > ==> node1: to temporary network problems. This is just a warning. The
> > > problem
> > > ==> node1: encountered was:
> > > ==> node1:
> > > ==> node1: The requested URL returned error: 404 Not Found
> > > ==> node1:
> > > ==> node1: If you want to check for box updates, verify your network
> > > connection
> > > ==> node1: is valid and try again.
> >
> >
> >
> > I believe the problem is that Hashicorp has chosen to no longer host the
> > base images that we rely on (outside of paying enterprise customers.)
> >
> > The Packer, Artifact Registry and Terraform Enterprise (Legacy) features
> of
> > > Atlas will no longer be actively developed or maintained and will be
> > fully
> > > decommissioned on Friday, March 30, 2018. Please see our guide on
> > building
> > > immutable infrastructure with Packer on CI/CD for ideas on implementing
> > > Packer and Artifact Registry features yourself and the Upgrading From
> > > Terraform Enterprise (Legacy) guide to migrate to the new Terraform
> > > Enterprise.
> >
> >
> >
> > If you already have the base images downloaded, do not delete them! The
> > development environments will continue to work as long as you have those
> > images.
> >
> > The problem is that new users will no longer be able to download these
> > images. And ultimately I am suspect that future updates will occur on
> > these base images.
> >
> > Is everyone experiencing this problem? Does anyone have any other
> details
> > to share on this?
> >
> > I am concerned that this is going to force us into some significant work
> in
> > the short-term to ensure that our development environments continue to
> > work. I have some alternative options to discuss, but I want to make
> sure
> > we have all the information on what's happening before discussing those.
> >
>
Re: [DISCUSS] The requested URL returned error: 404 Not Found
Posted by Michael Miklavcic <mi...@gmail.com>.
I had this problem on a machine running Vagrant 1.8.1. I thought it was
only Ubuntu at first, so I removed some additional boxes and found it to be
a problem for all of them. I didn't see any relevant articles other than
some old stuff talking about a bundled curl command being a problem, but
that didn't help anything. Not surprising since the URL being attempted
with curl didn't work via browser either. 404, as Nick mentioned.
{17:08}~ ➭ vagrant box add hashicorp/precise64
The box 'hashicorp/precise64' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:
URL: ["https://atlas.hashicorp.com/hashicorp/precise64"]
Error: The requested URL returned error: 404 Not Found
My last ditch attempt here was to upgrade Vagrant to 2.0.2. That seems to
have fixed it for me, but per their warning message I'm not sure if this
new location is permanent or if OSS Hashicorp Vagrant consumers need to
find an alternative. The new location appears to be https://vagrantcloud.com
.
Mike
On Mon, Feb 5, 2018 at 6:45 AM, Nick Allen <ni...@nickallen.org> wrote:
> When launching either of the development environments, you are probably
> seeing a warning message like this.
>
> Bringing machine 'node1' up with 'virtualbox' provider...
> > ...
> > ==> node1: There was a problem while downloading the metadata for your
> box
> > ==> node1: to check for updates. This is not an error, since it is
> usually
> > due
> > ==> node1: to temporary network problems. This is just a warning. The
> > problem
> > ==> node1: encountered was:
> > ==> node1:
> > ==> node1: The requested URL returned error: 404 Not Found
> > ==> node1:
> > ==> node1: If you want to check for box updates, verify your network
> > connection
> > ==> node1: is valid and try again.
>
>
>
> I believe the problem is that Hashicorp has chosen to no longer host the
> base images that we rely on (outside of paying enterprise customers.)
>
> The Packer, Artifact Registry and Terraform Enterprise (Legacy) features of
> > Atlas will no longer be actively developed or maintained and will be
> fully
> > decommissioned on Friday, March 30, 2018. Please see our guide on
> building
> > immutable infrastructure with Packer on CI/CD for ideas on implementing
> > Packer and Artifact Registry features yourself and the Upgrading From
> > Terraform Enterprise (Legacy) guide to migrate to the new Terraform
> > Enterprise.
>
>
>
> If you already have the base images downloaded, do not delete them! The
> development environments will continue to work as long as you have those
> images.
>
> The problem is that new users will no longer be able to download these
> images. And ultimately I am suspect that future updates will occur on
> these base images.
>
> Is everyone experiencing this problem? Does anyone have any other details
> to share on this?
>
> I am concerned that this is going to force us into some significant work in
> the short-term to ensure that our development environments continue to
> work. I have some alternative options to discuss, but I want to make sure
> we have all the information on what's happening before discussing those.
>