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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>>>
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to