The script should try to detect and warn about custom repository configurations

[oranenj]

The deploy seems to currently assume that hosts are using a standard CentOS 8 repository configuration via the RPM packages. This is often not the case if repositories are using a local mirror configured by configuration management.

Users using custom configurations will likely know enough to modify the script, but to avoid nasty surprises the script ought to warn if there are extra repositories in use after the release package has been replaced and prompt the user to continue.

[cschanzlenist]

I don't understand this issue. oranenj, could you be more specific about what your issue is?

I modify all my .repo files to point to local mirrors and I had no issue with changes being reverted by the script. This includes my various epel.repo files, rpmfusion-{free,nonfree*} plus a custom local repo.

I did make changes to the deploy script to point to my local almalinux mirror after almalinux-release is installed, which should be supported IMHO.

[oranenj]

@cschanzlenist as far as I can tell, the code has nothing that removes externally managed base repositories from the configuration, it seems to merely assume that removing the repos package is enough for this, but this won't work if the repositories do not come from the package. This is not an uncommon configuration especially if you manage repositories via configuration management, so I think it would make sense for the script to at least attempt to detect and warn about it.

If the original repositories aren't fully removed, the script may not work correctly or at all.

[cschanzlenist]

Ah, so to be even more specific, you remove or disable the original CentOS-*.repo files and install your own. I won't say your site management is doing it wrong, but I have found it "better" to make edits (automated with sed) to the provided repo files to comment mirrorlist= and uncomment baseurl= and point baseurl to my site preferences. I ensure this is done on every update as centos-release (now centos-linux-repos) changes not just on point upgrades but has updated in the middle of a point release.

Perhaps a check and warning like below could be added to the deploy script after removing the CentOS release packages ("rpm -e --nodeps --allmatches ${to_remove}"):

baserepos=$(echo {appstream,baseos,extras,plus}{,-source} cr debuginfo devel fasttrack ha media-{appstream,baseos} powertools)
for repo in $baserepos; do
  dnf config-manager --dump $repo 2>/dev/null | grep -q 'enabled = 1' && echo "Warning: repo '$repo' is still configured in $(grep -l "^\[$repo]" /etc/yum.repos.d/*.repo)"
done

FYI, baserepos was acquired from a "normal" system:

grep -h '^\[' /etc/yum.repos.d/CentOS-Linux-*.repo | sed -r 's/\[|]//g' | sort

[oranenj]

@cschanzlenist I don't really control which file gets edited, since the configuration is enforced by Puppet, and it'll parse the repo files, remove any repositories that are not managed, and replace them with its own.

But the crucial point is that you can't trust that removing the repository package will remove all relevant repository configuration, and I think it would be better for the user if the script at least attempted to detect this.

[robbevl]

The deploy seems to currently assume that hosts are using a standard CentOS 8 repository configuration via the RPM packages. This is often not the case if repositories are using a local mirror configured by configuration management.

Users using custom configurations will likely know enough to modify the script, but to avoid nasty surprises the script ought to warn if there are extra repositories in use after the release package has been replaced and prompt the user to continue.

I agree. Surely I know how to disable / remove the custom repo's, but I didn't foresee that they would be a problem for the script. So ran the script with the repo's intact and ended up with a mess: a mixture of Almalinux and OpenLogic packages installed on the system.

In my case, the CentOS machine was an Azure image by OpenLogic, and it does use the OpenLogic repo's. I imagine others will run into the same issue as well.