Question
DNF metadata cache expiration and permission boundary on CentOS Stream
Mira River
0 reputation · 13 Feb 2021, 19:34 UTC
134.9K views
Loading…
0 reputation · 13 Feb 2021, 19:34 UTC
DNF metadata cache expiration on CentOS Stream is governed by the interaction between repo-provided expire and dnf.conf metadata_expire, with effective freshness taken as the minimum of the two values.
The cache is stored under /var/cache/dnf per repository and is root owned, creating a permission boundary where non-root users can query packages via dnf but cannot directly inspect or purge cache contents for troubleshooting.
With a rolling release model, long expire values can allow stale package lists to persist after upstream changes, and there is no documented hard maximum staleness cap independent of upstream metadata.
What configuration provides predictable freshness guarantees for CentOS Stream without relying solely on upstream expire? Should a hard maximum staleness cap be enforced by default? How should cache inspection be permitted within the existing permission boundary?
33775 reputation · 13 Feb 2021, 22:43 UTC
To establish a predictable freshness guarantee that does not rely on upstream repository metadata, you must explicitly define the metadata_expire value in /etc/dnf/dnf.conf. When this value is set, DNF uses it as a local override to determine when the cached metadata is considered stale.
For a rolling‑release system like CentOS Stream, a conservative value (e.g., metadata_expire=6h) ensures that the system checks for updates at least every six hours, regardless of the expire value provided by the repository XML.
DNF has no built‑in “hard cap” that operates independently of metadata_expire. The most reliable way to enforce a maximum staleness boundary is to schedule a periodic dnf makecache via systemd timers or cron jobs.
centos# Example: Force metadata refresh every 12 hours via cron
0 */12 * * * /usr/bin/dnf makecache
The /var/cache/dnf directory is root‑owned to prevent unprivileged users from corrupting the package database. Non‑root users can still query the cache with dnf list or dnf info. If a user needs to inspect the actual timestamp of cached metadata, give them controlled access via sudo with a restricted alias in /etc/sudoers:
/var/cache/dnf, which would create a security vulnerability.dnf clean metadata or dnf makecache without full administrative privileges.To verify the current expiration settings and permission boundaries, run the following commands as root:
# Check configured expiration
grep metadata_expire /etc/dnf/dnf.conf
# Verify cache directory ownership
ls -ld /var/cache/dnf
Missing Diagnostic Detail: Are you using a local mirror or a proxy cache (e.g., Squid)? If so, the freshness guarantee is further impacted by the proxy’s own TTL settings, which would require adjustments at the network layer rather than just in dnf.conf.
Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 14 Feb 2021, 00:50 UTC
To clarify the interaction between local and upstream settings: DNF resolves the effective expiration as the minimum of dnf.conf, repo-specific files, and the repomd.xml expire field provided by the mirror. On CentOS Stream, if the upstream repomd.xml specifies a one-hour expiration, any local metadata_expire value higher than 3600 seconds is effectively ignored for those repositories.
Regarding the permission boundary, non-root users can still perform basic metadata inspection without sudo by using the --cacheonly flag. This allows verification of available packages without triggering a root-level refresh:
# Inspect cached package versions as a non-root user
dnf repoquery --cacheonly kernel
# Check metadata timestamps and expiration dates
dnf --cacheonly repoinfo '*'For those seeking a hard staleness cap, enabling the dnf-makecache.timer (which is often disabled by default on minimal installs) is the standard systemd-native approach to ensure periodic refreshes regardless of the calculated expiration.