Mixing ULN, a stale internal snapshot, and a PHP module stream
An Oracle Linux 8 application server is registered to ULN and also has the public ol8_baseos_latest and ol8_appstream repositories enabled. The internal standard requires PHP 7.4, but a recent dnf update proposes switching the php:7.4 module stream to php:8.0 and upgrading 612 packages, including glibc and the UEK kernel. The change board approved security updates only. dnf repolist shows an internal snapshot repo internal-ol8 with priority=1 and exclude=php* in /etc/dnf/dnf.conf, and a third-party repo epel is enabled. dnf update fails with 'Cannot download repomd.xml' for the ULN repo when the host uses the corporate proxy, although curl to the proxy works. The admin proposes dnf --nogpgcheck --disablerepo=* --enablerepo=epel update to get the latest packages quickly.
1. Diagnose the repomd.xml failure and the repository design issues, and give a safe remediation order.
Read the worked answer
Diagnosis. A repomd.xml download failure with a working proxy usually means DNF is not using the proxy, not that the repo is down. Check dnf -v repolist and /etc/dnf/dnf.conf for a [main] proxy= entry; DNF uses libcurl and does not reliably inherit shell http_proxy. Add proxy=http://proxy.example.com:3128 (and credentials if required), run dnf clean all, and retry. Also check the ULN repo baseurl and CA trust; if the system is behind TLS inspection, the CA must be in /etc/pki/ca-trust. The repository design is the larger risk: ULN and public ol8 repos can provide the same packages from different builds, and a priority=1 internal snapshot that is stale will win over security updates; a global exclude=php* blocks PHP security errata. EPEL is not a replacement for Oracle base packages. Pick one source of truth: ULN for supported packages, or public yum plus a controlled internal mirror. Remove duplicate repo definitions, narrow exclusions to specific packages if truly needed, and verify with dnf repolist --all and dnf repoquery --duplicates. Then fix PHP with module commands, not a global exclude.
2. How do you keep PHP on 7.4 while still applying security updates, and how does DNF module stream behavior affect this?
Read the worked answer
Module stream control. Module streams are separate package sets with their own metadata; enabling a stream tells DNF which set to use, but an enabled stream is not a version lock. Check dnf module list php and dnf module list --installed. If php:8.0 became enabled or the system has modular packages from 8.0, run dnf module reset php, then dnf module enable php:7.4, then dnf module install php:7.4 or dnf update to converge on the 7.4 stream. Remove the global exclude=php*; it prevents security updates for PHP and is coarser than the requirement. To prevent an accidental stream switch, keep php:7.4 enabled, avoid dnf distro-sync and avoid enabling 8.0, and use dnf update --security for the approved errata. dnf versionlock can pin specific packages, but locking every PHP package would also block 7.4 security updates; if you use it, lock only the stream-defining packages after testing, and document the unlock procedure. Confirm with dnf module list php that 7.4 is enabled and 8.0 is not, and test the application before and after the update.
3. Evaluate the proposed --nogpgcheck --disablerepo=* --enablerepo=epel update and describe a controlled update that meets the security-only mandate.
Read the worked answer
Reject the shortcut. --disablerepo=* --enablerepo=epel removes Oracle's signed base and security repos and replaces them with a community repo that is not built or supported for Oracle Linux. --nogpgcheck disables signature verification, so a corrupted or malicious package can be installed. Together they can replace glibc or other core packages with incompatible versions, break the UEK kernel, and leave no supported rollback. A controlled update starts with a staging clone or a snapshot and backup, then dnf check-update --security and dnf updateinfo list security to see the approved advisories. Use dnf update --security or specific advisories with GPG checking enabled, and exclude only packages the change board explicitly deferred, for example --exclude=kernel-uek* if the kernel is out of scope. Keep the Oracle GPG key imported; if a repo needs a proxy, fix the proxy instead of disabling repos. Review the transaction with dnf update --assumeno, then apply, record dnf history, and validate the application and PHP stream. If a dependency conflict appears, use --nobest only as a diagnostic, not as a way to force EPEL packages.