Error: Cannot retrieve repository metadata (repomd.xml) for repository: epel. Please verify its path and try again
I tried installing EPEL on a fresh install of RHEL6, and after adding the repo, yum fails with the above error. I have RHEL6.1 (Santiago) and get the above error.
This happens because the RHEL/CentOS installation doesn’t trust the HTTPS certificate used by mirrors.fedoraproject.org, that is issued by “GeoTrust SSL CA“.
In my case the package ca-certificates was not installed and the /etc/pki/tls/certs/ folder didn’t contain any ca-bundle.crt or ca-bundle.trust.crt !
Solution: yum install ca-certificates
(I had to temporarily rpm –erase epel-release first, to get yum working again)
I once got the same error message eventhout ca-certificates was installed and up to date. Then it was a firewall blocking https (port 443) traffic.
I worked around that by changing from https to http in /etc/yum.repos.d/epel.repo
So, you have correct permissions on your home directory and all the way up to /, with no other-writable directories in the path, as well as correct permissions on the .ssh directory in $HOME, and it still doesn’t work? You probably have SELinux, and need to put the newly created files in the correct security context. Do it with restorecon like this:
chmod 700 ~/.ssh
restorecon -R -v
Hi! A close friend has published a new online multiplayer business strategy board game.
The name is a bit corny: Ape Broker, but the idea is really cool. If you remember the old windows game Oil Baron from 1992, Ape Broker is based on the same idea, but instead of being strictly turn-based, and requiring the players to share the same mouse and keyboard, the new addictive game has a bunch of new features, making it playable over the internet.
For the true fans, the author has even made it possible to gamble for real money, by participating in “ante” games, where the winner gets the other players’ anted amount.
Check it out at www.apebroker.com !
As you know, a while ago, an intruder to one of comodos affiliates were able to issue SSL certificates for:
- login.yahoo.com (three different)
- “global trustee”
The reason for the identity theft was probably a dictatorship state planning to implement a man-in-the-middle attack, silently monitoring the HTTPS traffic to the above sites.
It would be possible when you have control over all DNS traffic in and out of the country, to spoof all the DNS replies, so for instance the A record for login.yahoo.com points to your proxy with the bogus certificate installed to decrypt the traffic, and just resending the request to the real https://login.yahoo.com/ site.
My suggestion (at least for security-aware techies): An addition to the web browser that remembers the certificate fingerprint, issuer, and expiry date of your favorite HTTPS sites.
Each time you visit an HTTPS site, a simple local lookup will compare the sites certificate with the remembered value, and if it has changed, present the user with a notice and a choice to cancel or investigate. For instance if mail.google.com changes from a Verisign certificate to a smaller CA (Comodo, StartCom, etc.) long before the expiry date, you may want to think twice before continuing..
See Comodo’s blog for more info.
Comments are always welcome.