We’re hitting an issue with ‘dnf modules’ where, since the default say for Nginx is 1.14, when someone ‘yum install nginx’ like in past times it’s defaulting to 1.14 which causes all sorts of issue with our security scans.
Is there a way to set yum/dnf to automatically use the newest module version when someone does a ‘yum’ or ‘dnf’ install of a non-enabled module as many aren’t familiar with the module system or realize that even needs to be adjusted from an older default version.
Side note, this is also biting users when they ‘yum’ or ‘dnf’ update thinking it’s say updating Nginx from 1.14 to 1.16, 16 to 18, 18 to 20, etc because it’s not, and then they’re asking why the security scans are calling out their old versions and why it isn’t updating to say 1.20 as it’s the newest… so in relation to that is there a setting to tell yum or dnf to automatically update to the newest module version for that package before actually running the update/upgrade as I haven’t been able to find much info out there in this area.
If you have something installed from a stream and then automatic throws you into different stream, it should do all the “proper steps” … which might depend on what is already installed.
True. The question is how to educate the users to properly use the features of a distro?
It certainly does not help that the entire module system seems to have weak and troublesome aspects. Neat concept, questionable implementation.
The issue with ‘dnf upgrade’ is the same even without modules. If you have php-7.0 and you run ‘dnf upgrade’, it won’t upgrade it to php-7.1
The issue with security scanners is the same without modules, the scanner would need to be aware of RHEL backporting to show the correct result.
With streams and modules, you can switch to the latest version on day one of building the server, and then “users” would see the newer version, but sometimes there’s a good reason for the defaults, e.g. dependencies with other packages.