Katello breaks EL systems to the point where migrate2rocky can't properly
migrate them and any attempt to do so causes major corruption. This prevents
migrate2rocky from running on Katello systems.
When attempting to check if a package exists for a particular provide string
what happened is if an older version of the package was on the system but a
newer version in the repositories then the older (system) version would be
returned by dnf provides, but this could not be translated into a package name
with dnf repoquery because that specific version could not be found in the
repos. The solution was to check rpm first to translate the package name on the
system and then dnf repoquery if rpm doesn't find it.
This brought to light issues when passing arrays of package names to rpm and dnf
which might happen to contain an empty element. In this case rpm and dnf would
consider the empty arg an indicator that it should match all packages on the
system, or all available packages. While we should try to avoid passing arrays
with empty elements, this highlighed a need to make rpm and dnf safer in this
regard, and so there are now saferpm and sfednf functions which simply strip any
empty args before calling the appropriate command with the rest of the args
untouched.
This commit also fixes an issue with output column formatting.
Before this commit, the Rocky system packages like rocky-repos,
rocky-release and similar, were not checked for their gpg signature,
while the rest of the packages were signature checked.
While the system packages were downloaded from https://dl.rockylinux.org,
this still created the risk that someone could attack the CDN infrastructure
behind dl.rockylinux.org and place malicous files there.
With this patch the GPG key is downloaded separately and then compared
against a checksum contained in the script. This adds an extra layer of
security.
Before this commit the user was supposed to give the -e cmdline parameter
to run the EFI conversion when necessary. But it was missing in the getopts
parameter list, so it didn't work.
Instead of fixing it, I opted to remove the -e parameter alltogether and
automatically detect if the system is running on EFI or not. Because if the
user should forget to give -e on an EFI system, it would result in an unbootable
system without any bootmanager installed. Fixing this situation takes time and
requires some sysadmin skills, so we should take steps to avoid this situation.
Detecting if the system runs on EFI or not can reliably done by checking for
/sys/firmware/efi/.
This is for two reaons:
1. There have been a number of complaints about the color blue. For now I
can't get reasonable agreement on which color to make informative messages and
it will differ depending on what the background color is of a person's terminal.
2. Currently the log is generated simply by splitting stdout and stderr. That
means that color codes go to the log, which is less than ideal. We need
separate logging routines that don't send the color codes but for now turning
off color will suffice.
This has been accomplished simply by commenting out the tput assignments at the
beginning of the script. It is likely that osme form of color support will go
back in at some point so we'll keep the old code around for now.
EL 8.0 had a dnf that was not compatible with this script (output changed
causing parsing errors). Make sure that e ahve a recent enough dnf for this
script to run properly and recommend updating otherwise.
Additional RHEL fixes:
- Don't remove subscription-manager because baseos is subscription managed.
- Disable any remaining subscription managed repos that are replaced by
RockyLinux repos.
- Hide digest messages from rpm.
Various fixes to allow RHEL conversions to work:
- adding additional commands to bin_check
- Fixed awk command to parse out the gpgkey for a repo.
- provides_pkg() which returns a package name for a given provides.
- allow additional packages to be removed without replacing them with rocky
equivalents.
- Don't bother checkign the exit status of dnf shell, it doesn't return a valid
fail status anyways.
- Instead check to make sure that the appropriate packages have been removed and
installed. If not attempt to fix with rpm.
There is no need to actually execute curl in order to check that it exists on
the system, the type builtin can tell us without having to fork the command.
