If leader node is turned off there is no control over UI of any of the nodes, so at least a minimal UI with node status and control from each cluster node could be useful to some degree. If a worker node is remote that will save a few calls and travels just to reach to the physical/virtual button.
But before that I’d prioritize extending AD functionality (permissions, wsdd, trashcan, user profiles…)
Sometimes easy to forget.
I think that is the hardest part of all and far to become real. (going by some music lyrics… this task ahead, this task at hand, ominous and daunting, crippling undertaking… where to begin eludes me, ruling ever deeper, this massive endeavor…)
A path, without having though as much as the devs surely already did, could be:
- Migrate from CentOS 7 to Rocky Linux 8 or CentOS 8 (no Debian) and from there to Rocky 9:
- Involving AlmaLinux’s Elevate + Leapp (an example) OR migrate2rocky
- Rebuild each nethserver module for EL8 and EL9 (safest, doesn’t mean safe) or just for EL9 (more risky):
- Having into account all the new version of dependencies from repositories
- AD could be troublesome as RHEL pulled the plug on some feature (?) and had to be rebuilt and compiled as the devs did for the last AD versions.
- Another concern is the firewall (shorewall availabilit), available on EL8 but not on EL9, unless I’m mistaken).
- At this stage, the server should be up and running (after the 2-way upgrade) on EL9 and with all modules working.
- Migration from EL9 to NS8 (one app by one):
- Install NS8 app (creating app users, folder structure, permissions, podman volumes…)
- Migrate settings from NS7 module to NS8 app
- Move (or copy, although could hit space limitation) data / databases from NS7 module to NS8 app + fix ownership and permissions
- Put NS7 module in maintenance mode (disable it, recoverable if copied, troublesome if data moved and permissions changed)
- Fire up NS8 app (reconfiguring it to old account provider if needed)
- At this stage, the server will be a mixture of NS7 modules and NS8 apps, controlled by different server managers / control panels.
- After every NS7 module supported by NS8 is successfully migrated (as there are modules that have no direct migration path), remove NS7 remnants.
Cons:
- Many possible sources of problems (apps, firewall, taking over used ports from one module to the app, grub boot-loader, etc.)
- Daunting task for devs (not only programming, but lots of testing involved)
- Time consuming efforts put on in-place migration, stale advancement of NS8, NethSecurity, NethVoice…
I love FOSS in the broader sense (freedom as well as free beer) but if I were on a Business management/executive position and had to seriously consider an in-place upgrade path, I’d be tempted to put it behind a paywall (subscription) to try to get some revenue for the unaccounted hard work, increase of support request and having customers breath on my neck.
I though of start/pause/restart/stop or enable/restart/disable, but all depends on how safe it is for the data, clock, and what is allowed by the underlying technology. For instance, traefik shall not be hardly ever touched, AD could be troublesome for all the apps that depend on it…
About the internal app services, that might be a second layer of control in contrast of the whole app as a unit.
Agree. It should be easy enough to add on the next app update.