This evening I decided to do some work on my development C7 system. As I have
not touched it for a while, and wanted to install new services I thought I'd
better yum update first.
I saw that it only did updates from Google and PHP, and none from the system
repo's so I had a closer look. It showed certificate errors on a number of
repo's.
[root at stan2 ~]# yum update
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Could not get metalink
https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 error was
14: curl#60 - "Peer's Certificate issuer is not recognized."
* base: mirrors.clouvider.net
* epel: mirrors.coreix.net
* extras: mirrors.clouvider.net
* remi-php72: mirror.netweaver.uk
* remi-safe: mirror.netweaver.uk
* updates: mirrors.vooservers.com
https://rpm.nodesource.com/pub_6.x/el/7/x86_64/repodata/repomd.xml: [Errno 14]
curl#60 - "Peer's Certificate issuer is not recognized."
Trying other mirror.
It was impossible to connect to the CentOS servers.
This could mean a connectivity issue in your environment, such as the
requirement to configure a proxy,
or a transparent proxy that tampers with TLS security, or an incorrect system
clock.
You can try to solve this issue by using the instructions on
https://wiki.centos.org/yum-errors
If above article doesn't help to resolve this issue please use
https://bugs.centos.org/.
https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/repodata/repomd.xml:
[Errno 14] curl#60 - "Peer's Certificate issuer is not
recognized."
Trying other mirror.
https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/repodata/repomd.xml:
[Errno 14] curl#60 - "Peer's Certificate issuer is not
recognized."
Trying other mirror.
No packages marked for update
[root at stan2 ~]#
I wrongly followed the instructions in https://wiki.centos.org/yum-errors hoping
that it would resolve the problems but it's only made it worse. Now all I
get is:
[root at stan2 ~]# yum clean all
Loaded plugins: fastestmirror, langpacks
Cleaning repos: base epel extras google-chrome nodesource pgdg10 pgdg96
remi-php72 remi-safe updates
Cleaning up list of fastest mirrors
[root at stan2 ~]# rm -rf /var/cache/yum/*
[root at stan2 ~]# yum update
Loaded plugins: fastestmirror, langpacks
Determining fastest mirrors
One of the configured repositories failed (Unknown),
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=<repoid> ...
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 <repoid>
or
subscription-manager repos --disable=<repoid>
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=<repoid>.skip_if_unavailable=true
Cannot retrieve metalink for repository: epel/x86_64. Please verify its path and
try again
[root at stan2 ~]#
I removed and re-installed the epel-release RPM which made no difference.
I've also tried disabling each repo in turn, pgdg10, remi-php72,
nodesource-el, pgdg96, google-chrome but still have no success.
Anyone got any suggestions?
On Aug 28, 2019, at 4:36 PM, Gary Stainburn <gary.stainburn at ringways.co.uk> wrote:> Anyone got any suggestions?If it?s really out of date, you might need to update the ca-certificates package, but that?d have to be a really old system. I?d suggest by checking to make sure the clock on your computer isn?t really out of date. If its right, I?d double-check with ?curl? to see if you aren?t getting a MitM response, where your HTTPS calls are being intercepted and resigned by a CA that isn?t in your CA trust. If that?s the case, you need be very suspicious of your network. -- Jonathan Billings <billings at negate.org>
On Wednesday 28 August 2019 22:41:24 Jonathan Billings wrote:> If it?s really out of date, you might need to update the ca-certificates package, but that?d have to be a really old system. > > I?d suggest by checking to make sure the clock on your computer isn?t really out of date. If its right, I?d double-check with ?curl? to see if you aren?t getting a MitM response, where your HTTPS calls are being intercepted and resigned by a CA that isn?t in your CA trust. If that?s the case, you need be very suspicious of your network.It isn't that out of date. The server is less than a year old, and the last yum update was probably only done about 2 months ago. I checked the system time and it was only a few minutes out. A quick rdate to my local time server sorted that. I ran a yum check which took ages but didn't report any problems. [root at stan2 ~]# yum check Loaded plugins: fastestmirror, langpacks check all [root at stan2 ~]# However, running yum update afterwards came up with the same problem. [root at stan2 ~]# yum update Loaded plugins: fastestmirror, langpacks Determining fastest mirrors One of the configured repositories failed (Unknown), 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=<repoid> ... 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 <repoid> or subscription-manager repos --disable=<repoid> 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=<repoid>.skip_if_unavailable=true Cannot retrieve metalink for repository: epel/x86_64. Please verify its path and try again [root at stan2 ~]# cat /etc/yum.repos.d/epel.repo [epel] name=Extra Packages for Enterprise Linux 7 - $basearch #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 [epel-debuginfo] name=Extra Packages for Enterprise Linux 7 - $basearch - Debug #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch failovermethod=priority enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 gpgcheck=1 [epel-source] name=Extra Packages for Enterprise Linux 7 - $basearch - Source #baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch failovermethod=priority enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 gpgcheck=1 [root at stan2 ~]#