A still-running CentOS 7 server fails every `yum install` with "Could not resolve host: mirrorlist.centos.org". Why did its repositories stop working, and how do you get yum installing packages from that box again?

## Read the error literally ``` Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org" ``` That message is about *finding* repositories, not about installing packages. A `.repo` file can point yum at content in two ways: a `baseurl=`, which is a URL yum uses directly, or a `mirrorlist=`, which is a URL yum fetches to *obtain* a list of baseurls near you. CentOS shipped its stock repositories with a mirrorlist, so when the mirrorlist service stops answering there is nothing to fall back to — yum has no candidate URL at all, and every transaction that needs metadata fails before it can consider a single package. The first diagnostic instinct on this error is usually DNS or a proxy, and on a normal box that would be right: check `getent hosts`, check `/etc/resolv.conf`, check whether other hosts resolve, check `$http_proxy`. Do that once. When resolution works for everything except the CentOS infrastructure, the answer is not on your machine. ## What actually happened CentOS Linux 7 reached end of life on 30 June 2024 — the same date RHEL 7 left maintenance support. When a CentOS release goes EOL, its content is removed from the active mirror network and moved to the archive at `vault.centos.org`, and the mirrorlist service stops returning mirrors for that release. Nothing on your server changed; a dependency of your server was decommissioned on a published schedule. ## The repair, concretely Edit each file under `/etc/yum.repos.d/` — `CentOS-Base.repo` is the important one, but any stock file with a `mirrorlist=` needs the same treatment: 1. Comment out the `mirrorlist=` line so yum stops chasing a host that no longer answers. 2. Uncomment or add a `baseurl=` pointing at the vault, using the **frozen minor version** rather than `$releasever`: `http://vault.centos.org/7.9.2009/os/$basearch/` for the base repository, with `updates/` and `extras/` following the same pattern. Pinning the exact minor release matters because the archive is laid out by minor version and there is no moving target to follow any more. 3. `yum clean all` to discard cached metadata for the old URLs, then `yum makecache` to fetch it from the new one. ```ini [base] name=CentOS-7 - Base #mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os baseurl=http://vault.centos.org/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 ``` Leave `gpgcheck=1` and the existing `gpgkey` alone. The archived content is the same signed content that was on the mirrors; there is no reason to weaken verification because you changed a URL, and "I turned off gpgcheck to make it work" is a bad sentence to have to say afterwards. If the fleet is large enough that you will do this more than a handful of times, note that repository configuration is itself packaged (`centos-release`), so an update to that package can reintroduce mirrorlist lines — but on a frozen box that update will never arrive, which is one of the very few conveniences of the situation. ## Be honest about what you have restored After this, `yum install` works and `yum update` reports nothing to do. Both are expected: the vault is an archive, frozen at the final state of the release. You have restored the ability to install software that was already published, not the ability to receive fixes. Anything discovered after the EOL date will never appear there. So treat the vault switch as exactly one thing: a way to unblock the immediate task — installing a diagnostic tool, rebuilding an application, getting a stuck deployment moving — on a machine that is already out of support. It buys time for a planned move; it is not a state to leave a fleet in, and saying so unprompted is a large part of what an interviewer is listening for. ## The pattern generalises Every distribution does some version of this. Old Debian releases move to `archive.debian.org` and need their sources repointed and expiry checks handled; old Fedora releases move to the Fedora archive. The reusable lesson is that a repository URL is an operational dependency on someone else's infrastructure and someone else's support calendar. If a machine must outlive its distribution's support window — and sometimes one genuinely must — the durable fix is an internal mirror or a local snapshot of the content you depend on, taken *before* the upstream disappears, not a scramble afterwards. ## Interview shape Name the cause (EOL, mirrors retired), name the destination (vault), give the three concrete steps (comment mirrorlist, set baseurl to the pinned minor version, clean the cache), keep GPG checking on, and close with the caveat that the archive is frozen. That is a complete answer in under a minute.