У меня есть два экземпляра EC2, которые очень похожи. Ровно один из них дает мне эту проблему.
Yum работает точно так, как ожидалось, на одном сервере, а на другом я получаю ошибку 401 независимо от того, что я прошу yum сделать для меня.
Вот 1 пример:
yum repolist -v | grep baseurl
который выводит:
https://rhui2-cds01.us-west-2.aws.ce.redhat.com/pulp/repos//rhui-client-config/rhel/server/7/x86_64/os/repodata/repomd.xml: [Errno 14] HTTPS Error 401 - Unauthorized
Trying other mirror.
https://rhui2-cds02.us-west-2.aws.ce.redhat.com/pulp/repos//rhui-client-config/rhel/server/7/x86_64/os/repodata/repomd.xml: [Errno 14] HTTPS Error 401 - Unauthorized
Trying other mirror.
One of the configured repositories failed (Red Hat Update Infrastructure 2.0 Client Configuration Server 7),
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=rhui-REGION-client-config-server-7 ...
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 rhui-REGION-client-config-server-7
or
subscription-manager repos --disable=rhui-REGION-client-config-server-7
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:
yum-config-manager --save --setopt=rhui-REGION-client-config-server-7.skip_if_unavailable=true
failure: repodata/repomd.xml from rhui-REGION-client-config-server-7: [Errno 256] No more mirrors to try.
https://rhui2-cds01.us-west-2.aws.ce.redhat.com/pulp/repos//rhui-client-config/rhel/server/7/x86_64/os/repodata/repomd.xml: [Errno 14] HTTPS Error 401 - Unauthorized
https://rhui2-cds02.us-west-2.aws.ce.redhat.com/pulp/repos//rhui-client-config/rhel/server/7/x86_64/os/repodata/repomd.xml: [Errno 14] HTTPS Error 401 - Unauthorized
Хотя одна и та же команда на другом экземпляре EC2 выводит:
Repo-baseurl : https://rhui2-cds01.us-west-2.aws.ce.redhat.com/pulp/repos//rhui-client-config/rhel/server/7/x86_64/os/
Repo-baseurl : https://rhui2-cds02.us-west-2.aws.ce.redhat.com/pulp/repos//content/dist/rhel/rhui/server/7/7Server/x86_64/os/
Repo-baseurl : https://rhui2-cds02.us-west-2.aws.ce.redhat.com/pulp/repos//content/dist/rhel/rhui/server/7/7Server/x86_64/rh-common/os/
Все предложенное решения в первом выводе не кажутся важными, поскольку репозитории установлены одинаково на обеих машинах.
Это проблема конфигурации SELinux? Я отключил его на рассматриваемой машине.
Мой файл /etc/yum.conf идентичен на обеих машинах:
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
Как я могу решить эту проблему и установить новые пакеты?
Поднялось немного дальше копания сообщение на форуме AWS.
Это связано с тем, что экземпляр каким-то образом теряет биллинг Информация. Вы можете проверить это с помощью следующей команды:
curl http://169.254.169.254/latest/dynamic/instance-identity/document | grep billingProducts
В рабочем экземпляре должен отображаться код продукта, но для моего проблемного экземпляра значение равно null
.
Предложения по этому сообщению на форуме AWS:
To workaround the issue please try one of these two options:
1- From the modified instance ( if you still have it ) create an AMI directly.
2- If the only source that you have is the snapshot then take these steps:
- Launch a new instance from a good RHEL AMI, stop and detach the root EBS volume.
- Stop the broken instance, detach all EBS volumes and attach to the new instance and restart ( remembering to associate the broken instance's EIP if applicable )
- Alternatively you could snap-shot the broken instance's EBS volumes, and attach volumes created from these snapshots to the new instance.
- Verify billingProducts value is present by running
curl http://169.254.169.254/latest/dynamic/instance-identity/document
Для меня первый вариант (создать AMI напрямую) не помог, и у меня все еще не было биллинг, но после второго предложения сработало.
Теперь YUM снова работает нормально.