Proposal to add support for function hooks to enhance functionality suited to local requirements

[cschug]

There are environments in which almalinux-deploy.sh cannot be executed successfully in unmodified form as of now. This mostly affects servers which do not have direct access to the internet but rather run in secluded, isolated networks with RPM repositories provided by a local mirror.

While currently almalinux-deploy.sh supports to override the location of the almalinux-release package (by setting the ALMA_RELEASE_URL environment variable) and the location of the public key of AlmaLinux RPM signing (ALMA_PUBKEY_URL), there is not way to influence dnf's repository configuration as such.

Currently the script installs the almalinux-release package in function migrate_from_centos() which provides the two repository configuration files

• /etc/yum.repos.d/almalinux.repo and
• /etc/yum.repos.d/almalinux-ha.repo

which for example have following configuration for the baseos repository:

[baseos]
name=AlmaLinux $releasever - BaseOS
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos
# baseurl=https://repo.almalinux.org/almalinux/$releasever/BaseOS/$basearch/os/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux
fastestmirror=1

Machines which don't have access to mirrors.almalinux.org and the mirrors defined in the mirrorlist will therefore not be able to fetch the RPMs required for migration.

Unless one doesn't want to introduce ugly workarounds like overriding mirrors.almalinux.org to point it to the local mirror and fake the HTTPS verification by adding its own self-signed certificate chain as trusted to the system's certificate bundle, this is a blocker. I think everybody agrees that's a bad idea.

Another option would be to modify the script to the local requirements by modifying the repository configuration files after insallation of almalinux-release and before starting the migration. But changing the script locally makes it hard to keep up with improvements of the script as constant merging is required which also doesn't sound appealing.

As the functionality of the script is pretty much broken into separate functions anyway, there might be a nice way to take advantage of that. Instead of calling functions like migrate_from_centos() directly from main() I would propose the add a wrapper function which is called from main() and which in turn calls migrate_from_centos() for example.
The function's name to call has to be provided as an argument. Before and after calling the specified function, the wrapper function could check the existence of functions (using typeset -F) with the name hook_pre_<function_name>() or hook_post_<function_name>().
Whenever a hook function with matching name is found, it gets called by the wrapper before (pre) or after (post) the function containing the original functionality. That way people can hook in custom functionality without modifying the original script.

Whenever a custom hook function is being called it, it's name should be added to global scoped variable to keep track of that. If this tracking variable is non-empty at the end of the script, a summary should be printed to make clear for support cases that some additional (unsupported) code had been run (in the same way as the Linux kernel for example emits a warning that it is running in tainted mode when some unsupported kernel module has been loaded).

In order to stick to the plan, that the original script should be modified, I would suggest to load the custom hook functions by sourcing an additional file containing those hook funtions and which are to be provided by the site's administrator. The location of that file should be overridable per environment variable (similar to ALMA_RELEASE_URL). If not location is specified, the detault location might be something like $(realpath ${0}.local_hooks), so bascially the same path/name as almalinux-deploy.sh just with a .local_hooks suffix. If the location of the local hook file has been specified by the environment variable mentioned before and it does not exist, the script should fail with an error. If no environment has been defined, to existence of the file should be optional.
If a local hook file exists, it should be tested if it's readable and that it consists of valid bash syntax (bash -n ...) before being sourced.

In the end such a thing would be quite flexible and allows more use cases beside adjusting the repository configuration files. Some other ideas might be

• creating a file system snapshot/trigger a backup
• stop some configuration mangament like Puppet agent which might interfere while the migration is in progress and start it later again; or even specifically trigger a Puppet run to provide the updated repository configuration after the almalinux-release has been installed which also makes Puppet Facter to recognize the system as AlmaLinux and not CentOS any longer
• Check disk space constraints beforehand
• Check for a sane configuration status before/after the migration by looking for .rpmnew/.rpmsave files
• Call web hooks for all sort of notification or updates (disable/enable monitoring; update a CMDB, update some ticket or send Jabber notifications, send a mail for example)

The only other thing which would be required is the splitting of the migrate_from_centos() function into two stages, with the lines until report_step_done 'Install almalinux-release package' becoming migrate_from_centos_stage_1() and the lines after that becoming migrate_from_centos_stage_2(). Then it would be sufficient to come back to the original issue to define a function called hook_post_migrate_from_centos_stage_1() which contains the code the update the repository configuration to suit local needs.

What do you think about it?

[ghost]

Hello @cschug, I'm going to work on making this update to the upgrade script. Hopefully I will have a PR together soon.

[cschanzlenist]

While a formal engineering exercise is in the works, I hacked the current script to do what I needed. Attached is a very simple patch. almalinux-deploy-siterepo-patch.txt
Edit the patch to change 'mirror.example.com' (possibly http->https) to your local mirror and apply via:

patch -p0 < almalinux-deploy-siterepo-patch.txt

Hope that helps someone!