On a RHEL 8 or 9 host, `yum install httpd` still works even though the system's package manager is dnf. What is the `yum` command on such a host, and what happened to /etc/yum.conf and /etc/yum.repos.d?

## What is actually at /usr/bin/yum On Red Hat Enterprise Linux 8 and 9 — and equally on CentOS Stream, AlmaLinux and Rocky Linux of those generations — `yum` is not a program of its own. It is a symbolic link: ```bash $ ls -l /usr/bin/yum /usr/bin/dnf lrwxrwxrwx. 1 root root 5 /usr/bin/yum -> dnf-3 lrwxrwxrwx. 1 root root 5 /usr/bin/dnf -> dnf-3 ``` Both names resolve to `dnf-3`, the Python 3 entry point of dnf. So `yum install httpd` and `dnf install httpd` are the same process doing the same work; there is no translation layer, no wrapper script, and no second dependency solver installed alongside. The link is shipped by a small `yum` compatibility package that simply requires dnf. ## Why the alias exists Red Hat replaced yum 3 with dnf in RHEL 8 because yum 3 was a Python 2 codebase with a dependency solver that had reached the end of its useful life; dnf uses libsolv for depsolving and hawkey/librepo underneath. But an operating system with a ten-year support life inherits a decade of muscle memory: shell history, wiki runbooks, kickstart `%post` sections, Chef recipes, Dockerfiles, and Ansible tasks that all say `yum`. Keeping the name working is the cheapest possible migration path for all of that. ## The configuration followed the command The compatibility is deliberately not limited to the command name. - `/etc/yum.conf` is a symlink to `/etc/dnf/dnf.conf`. Editing either edits the same file, so an old instruction that says "set `installonly_limit` in /etc/yum.conf" still lands in the right place. - Repository definitions did not move at all. dnf's default `reposdir` is `/etc/yum.repos.d`, so every existing `.repo` file — with its `[repoid]`, `name=`, `baseurl=` or `mirrorlist=`, `gpgcheck=` and `enabled=` keys — is read as-is. This is the single biggest reason the migration was tolerable: repository configuration, the part that is most customised per site, needed no change. - Variables such as `$releasever` and `$basearch` in those files are still expanded. What did move is runtime state, and this catches people who go looking for it: - the metadata and package cache is `/var/cache/dnf`, so `du -sh /var/cache/yum` on RHEL 8 usually reports an empty or absent directory; - transaction logging goes to `/var/log/dnf.log` rather than `/var/log/yum.log`. ## The helper commands were aliased too The old `yum-utils` family was reimplemented as dnf plugins. On RHEL 8 and 9 the `yum-utils` package is a compatibility shim that pulls in `dnf-utils` and `dnf-plugins-core`, which provide `yum-config-manager`, `yumdownloader` and `repoquery` as front ends for `dnf config-manager`, `dnf download` and `dnf repoquery`. So `yum-config-manager --add-repo <url>` still writes a `.repo` file into `/etc/yum.repos.d`, just by a different implementation. ## Where the compatibility stops The alias covers names and configuration, not internals or semantics. - **Plugins.** yum 3's plugin API is gone. A third-party plugin written for yum 3 (Python 2, dropped into yum's plugin directory) will not load; dnf plugins are separate packages against a different API. - **The Python API.** `import yum` no longer exists. Anything that drove package management by importing yum's library — including old automation and monitoring scripts — must be ported to `python3-dnf`. This is why the Ansible `yum` module needs the dnf Python bindings on RHEL 8+, and why `ansible.builtin.dnf` is now the module you should be writing. - **Behaviour.** Several everyday invocations resolve differently under dnf than they did under yum 3, because RHEL's shipped `dnf.conf` sets stricter defaults. That is a separate discussion, but it is the reason "yum still works" should never be read as "yum still behaves identically". ## Where genuinely old yum still lives Real yum 3 — version 3.4.3, running on Python 2.7 — is what RHEL 7 and CentOS Linux 7 shipped. Those are the boxes where `yum` is the actual resolver rather than an alias, and they are also the ones most likely to be out of support: CentOS Linux 7 reached end of life on 30 June 2024, and RHEL 7 left maintenance support on the same date with only paid extended support beyond it. If you meet a machine where `ls -l /usr/bin/yum` shows a real ELF binary rather than a symlink, you are on that generation, and everything about the box — not just its package manager — deserves a second look. ## What to say in an interview Lead with the symlink, name `dnf-3`, and mention that the repository directory did not change. Then add the caveat that identical command names do not imply identical outcomes. That order shows you have both read the man page and been bitten by it.