Errno 14 404 not found

Support
1

Hola,

I promoted a LCE and when I tried updating the content host attached to it,
I get the error

[Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below knowledge base article

https://access.redhat.com/articles/1320623

If above article doesn't help to resolve this issue please create a bug on
https://bugs.centos.org/

One of the configured repositories failed (client),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the

problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a

working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=PMCC_Katello_client ...

 4. Disable the repository permanently, so yum won't use it by default.

Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:

        yum-config-manager --disable PMCC_Katello_client
    or
        subscription-manager repos --disable=PMCC_Katello_client

 5. Configure the failing repository to be skipped, if it is

unavailable.
Note that yum will try to contact the repo. when it runs most
commands,
so will have to try and fail each time (and thus. yum will be be
much
slower). If it is a very temporary problem though, this is often a
nice
compromise:

Unfortunately, the page listed:
https://access.redhat.com/articles/1320623

is only available to RH subscribers. Is there a non subscriber version of
this page?

Alternatively, how do I fix the problem.

cheers
L.

··· ------ The most dangerous phrase in the language is, "We've always done it this way."
  • Grace Hopper
2

I think I can see what the error is:

we used to have a repo called Katello/client/ which held the client repo.

Then, when I decided to upgrade to 3.2, I renamed the repo to
Katello/client-3.1 and added Katello/client-3.2

This might be the first time that this content host/LCE/Activation key has
been associated with the newly named client repo.

But I don't understand how the .repo file is made nor why the renaming
wouldn't click with any updates - is this a bug?

Note: I'm pretty sure this is exactly what happened as the listed repo in
the error def doesn't work (browser gives 404)

https://vmpr-res-utils.our.domain/pulp/repos/PMCC/Utility_Prod/Utility_Server/custom/Katello/client

but this definitely does show up in a browser (package list in browser)

https://vmpr-res-utils.our.domain/pulp/repos/PMCC/Utility_Prod/Utility_Server/custom/Katello/client-3_2

So - I can fix this by hand, but that is less than ideal. How do I fix it
more permanently?

cheers
L.

··· ------ The most dangerous phrase in the language is, "We've always done it this way."
  • Grace Hopper

On 13 February 2017 at 09:25, Lachlan Musicman datakid@gmail.com wrote:

Hola,

I promoted a LCE and when I tried updating the content host attached to
it, I get the error

[Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below knowledge base article

https://access.redhat.com/articles/1320623

If above article doesn’t help to resolve this issue please create a bug on
https://bugs.centos.org/

One of the configured repositories failed (client),
and yum doesn’t have enough cached data to continue. At this point the
only
safe thing yum can do is fail. There are a few ways to work “fix” this:

 1. Contact the upstream for the repository and get them to fix the

problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a

working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=PMCC_Katello_client ...

 4. Disable the repository permanently, so yum won't use it by

default. Yum
will then just ignore the repository until you permanently enable
it
again or use --enablerepo for temporary usage:

        yum-config-manager --disable PMCC_Katello_client
    or
        subscription-manager repos --disable=PMCC_Katello_client

 5. Configure the failing repository to be skipped, if it is

unavailable.
Note that yum will try to contact the repo. when it runs most
commands,
so will have to try and fail each time (and thus. yum will be be
much
slower). If it is a very temporary problem though, this is often a
nice
compromise:

Unfortunately, the page listed:
https://access.redhat.com/articles/1320623

is only available to RH subscribers. Is there a non subscriber version of
this page?

Alternatively, how do I fix the problem.

cheers
L.

The most dangerous phrase in the language is, “We’ve always done it this
way.”

  • Grace Hopper
3

Hmnm, fixing by hand doesn't work - the /etc/yum.repos.d/redhat.repo
updates/reverts itself every time?

cheers
L.

··· ------ The most dangerous phrase in the language is, "We've always done it this way."
  • Grace Hopper

On 13 February 2017 at 09:39, Lachlan Musicman datakid@gmail.com wrote:

I think I can see what the error is:

we used to have a repo called Katello/client/ which held the client repo.

Then, when I decided to upgrade to 3.2, I renamed the repo to
Katello/client-3.1 and added Katello/client-3.2

This might be the first time that this content host/LCE/Activation key has
been associated with the newly named client repo.

But I don’t understand how the .repo file is made nor why the renaming
wouldn’t click with any updates - is this a bug?

Note: I’m pretty sure this is exactly what happened as the listed repo in
the error def doesn’t work (browser gives 404)

https://vmpr-res-utils.our.domain/pulp/repos/PMCC/
Utility_Prod/Utility_Server/custom/Katello/client

but this definitely does show up in a browser (package list in browser)

https://vmpr-res-utils.our.domain/pulp/repos/PMCC/
Utility_Prod/Utility_Server/custom/Katello/client-3_2

So - I can fix this by hand, but that is less than ideal. How do I fix it
more permanently?

cheers
L.

The most dangerous phrase in the language is, “We’ve always done it this
way.”

  • Grace Hopper

On 13 February 2017 at 09:25, Lachlan Musicman datakid@gmail.com wrote:

Hola,

I promoted a LCE and when I tried updating the content host attached to
it, I get the error

[Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below knowledge base article

https://access.redhat.com/articles/1320623

If above article doesn’t help to resolve this issue please create a bug
on https://bugs.centos.org/

One of the configured repositories failed (client),
and yum doesn’t have enough cached data to continue. At this point the
only
safe thing yum can do is fail. There are a few ways to work “fix” this:

 1. Contact the upstream for the repository and get them to fix the

problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a

working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=PMCC_Katello_client ...

 4. Disable the repository permanently, so yum won't use it by

default. Yum
will then just ignore the repository until you permanently enable
it
again or use --enablerepo for temporary usage:

        yum-config-manager --disable PMCC_Katello_client
    or
        subscription-manager repos --disable=PMCC_Katello_client

 5. Configure the failing repository to be skipped, if it is

unavailable.
Note that yum will try to contact the repo. when it runs most
commands,
so will have to try and fail each time (and thus. yum will be be
much
slower). If it is a very temporary problem though, this is often
a nice
compromise:

Unfortunately, the page listed:
https://access.redhat.com/articles/1320623

is only available to RH subscribers. Is there a non subscriber version of
this page?

Alternatively, how do I fix the problem.

cheers
L.

The most dangerous phrase in the language is, “We’ve always done it this
way.”

  • Grace Hopper
4

This seems to have solved itself when I published a new version and
promoted to that.

cheers
L.

··· ------ The most dangerous phrase in the language is, "We've always done it this way."
  • Grace Hopper

On 13 February 2017 at 09:40, Lachlan Musicman datakid@gmail.com wrote:

Hmnm, fixing by hand doesn’t work - the /etc/yum.repos.d/redhat.repo
updates/reverts itself every time?

cheers
L.

The most dangerous phrase in the language is, “We’ve always done it this
way.”

  • Grace Hopper

On 13 February 2017 at 09:39, Lachlan Musicman datakid@gmail.com wrote:

I think I can see what the error is:

we used to have a repo called Katello/client/ which held the client repo.

Then, when I decided to upgrade to 3.2, I renamed the repo to
Katello/client-3.1 and added Katello/client-3.2

This might be the first time that this content host/LCE/Activation key
has been associated with the newly named client repo.

But I don’t understand how the .repo file is made nor why the renaming
wouldn’t click with any updates - is this a bug?

Note: I’m pretty sure this is exactly what happened as the listed repo in
the error def doesn’t work (browser gives 404)

https://vmpr-res-utils.our.domain/pulp/repos/PMCC/Utility_
Prod/Utility_Server/custom/Katello/client

but this definitely does show up in a browser (package list in browser)

https://vmpr-res-utils.our.domain/pulp/repos/PMCC/Utility_
Prod/Utility_Server/custom/Katello/client-3_2

So - I can fix this by hand, but that is less than ideal. How do I fix it
more permanently?

cheers
L.

The most dangerous phrase in the language is, “We’ve always done it this
way.”

  • Grace Hopper

On 13 February 2017 at 09:25, Lachlan Musicman datakid@gmail.com wrote:

Hola,

I promoted a LCE and when I tried updating the content host attached to
it, I get the error

[Errno 14] HTTPS Error 404 - Not Found
Trying other mirror.
To address this issue please refer to the below knowledge base article

https://access.redhat.com/articles/1320623

If above article doesn’t help to resolve this issue please create a bug
on https://bugs.centos.org/

One of the configured repositories failed (client),
and yum doesn’t have enough cached data to continue. At this point the
only
safe thing yum can do is fail. There are a few ways to work “fix” this:

 1. Contact the upstream for the repository and get them to fix the

problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a

working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).

 3. Run the command with the repository temporarily disabled
        yum --disablerepo=PMCC_Katello_client ...

 4. Disable the repository permanently, so yum won't use it by

default. Yum
will then just ignore the repository until you permanently
enable it
again or use --enablerepo for temporary usage:

        yum-config-manager --disable PMCC_Katello_client
    or
        subscription-manager repos --disable=PMCC_Katello_client

 5. Configure the failing repository to be skipped, if it is

unavailable.
Note that yum will try to contact the repo. when it runs most
commands,
so will have to try and fail each time (and thus. yum will be be
much
slower). If it is a very temporary problem though, this is often
a nice
compromise:

Unfortunately, the page listed:
https://access.redhat.com/articles/1320623

is only available to RH subscribers. Is there a non subscriber version
of this page?

Alternatively, how do I fix the problem.

cheers
L.

The most dangerous phrase in the language is, “We’ve always done it this
way.”

  • Grace Hopper