EPEL Repo Down?

Anyone else having this issue? https://bugs.centos.org/view.php?id=12597

I was installing CentOS 7.4 on a server during my usual onboarding process. I installed EPEL with yum install -y epel-release which I have done countless times (a few times on 7.4) without issue.

This time I get 404 on every EPEL mirror (long list).

I tried yum clean all and removing/reinstalling epel-release. I also tried using baseurl=http://mirror.xnet.co.nz/pub/epel/7/$basearch as suggested in the bug tracker, but no luck.

I tried pinging fedoraproject.org as a sanity check and it was successful.

I just ssh’d into my webserver (running Centos) to give this a go and sure enough I can download from the epel repo.

I spun up a vanilla minimal CentOS 7.4 VM and I don’t have the issue.

I am (trying) to use the DISA STIG via OpenSCAP for general server hardening (over the top, I know), and I think it’s causing the issue. There’s a signing issue on the OpenSCAP github page that looks similar, but you’d think that EPEL would be signed properly… also, why would 404 be the error for a signing issue?

I copied the CentOS bug to epel-release, and am looking into this issue in OpenSCAP. Not sure whose problem it is.


The issue is that EPEL does not support repo_gpgcheck

Solution is to set repo_gpgcheck=0 in yum.conf


That kind of sucks, you’d think RHEL of all organizations would support something like gpg checking the repo.

I guess anyone who wants to be DISA STIG compliant can’t use EPEL.

IIRC EPEL is the ‘extra’ repo.

Is that one of the built in security profiles available on installation?

Yeah, it’s the insane DoD one. The government publishes the standards, the OpenSCAP people try to write up scripts to implement it and RHEL puts it into the installer. You still have to do some things after install though.

I’ve been playing with it for a while and it’s still changing a lot between point releases in CentOS/RHEL. It’s definitely a WIP. At one point in 7.3, it disabled all USB functionality so it was impossible to interact with the computer after reboot unless you had a ps2 port. That somehow even applied to IPMI KVM in my case (I guess Supermicro IPMI simulates a USB device for keyboard/mouse).

Ideally, in the future, it will be an easy way to automatically harden a server, but for now it’s very unreliable. If/when it stabilizes, I’ll do a write up on how to use it.

Currently, the issue is that RHEL doesn’t sign their repo metadata and the DISA STIG dictates that DoD systems can only use signed repos. I have no idea how that is actually playing out in the field, but as is, I’m not sure how they can use RHEL at all.

Well usually, the servers that these run on, don’t ever see the internet.

They pull updates from a local update server, which is what has access to the internet.

Yeah, I’m sure you’re right, although the update server has to pull from somewhere and it would surely need to comply with the STIG.

I’m sure they have something in place that’s functional, but based on the comments on the OpenSCAP github page, a number of people would really appreciate it if RHEL signed their repos…

Looks like its in the plan to fix it. Interim remediation would be to accept the risk on not implementing that STIG option id imagine.

I installed EPEL on my CentOS 6.9 VPS yesterday:

Oct 10 14:01:35 Installed: epel-release-6-8.noarch