[BlueOnyx:25569] Re: AlmaLinux 9 - BlueOnyx 5211R development

[Michael Stauber]

Hi Ernie,

> people will still want to be able to switch php versions for vsites, in
> particular, to earlier versions when the orginal site developer disappears
> off the face of the earth, which seems to happen way too often!

That's actually an admin problem, isn't it? If the siteAdmin goes 
walkies, why doesn't the server admin promote someone else who can take 
over?

> The benefit is the admserv GUI is protected from php changes, which I see as a big plus.
> That way you don't have to spend months converting the 5210R GUI to work on
> php 8.0 on Almalinux 8.6 or whatever php is in Almalinux 9 atm.
> 
> The GUI could stay on the old codeigniter using PHP 7.2.24 until you were
> ready to replace the GUI.
It's a neat idea, but it has some pretty big strings attached. For 
starters there is no guarantee that PHP-7.2 still compiles with the GCC 
and OpenSSL 3 present on EL9. I haven't tried that yet, but PHP-7.2 
predates OpenSSL 3 by quite a bit and in my experience software that 
uses SSL needs to be modified to compile against OpenSSL v3.

The next issue is that switching from CodeIgniter 3 to CodeIgniter 4 
during the lifecycle of 5211R would be *highly* disruptive. The format 
of the 5211R GUI pages is slightly different. That is even before I try 
to wiggle a new theme in (which is planned, but I'm not happy with the 
theme yet). The internal routing (which URL call triggers the loading of 
which GUI page class) is also different. In some cases that will 
probably require different URL paths to access GUI pages.

If this there was just one fat YUM update eventually when the switchover 
happens? That would already rock the boat mightily. But throw in the 
fact that people will have PKGs from the shop installed and those PKGs 
have their own GUI pages? All those will break *hard* after that fat YUM 
update and those PKGs would need to be updated via NewLinQ to restore 
functionality.

But what if a BlueOnyx users subscription for Shop updates isn't 
current? Without ongoing support or subscription they then can't restore 
functionality which that YUM update broke. That's a really shitty user 
experience and if a software vendor or provider did that with me I'd be 
pissed.

This would be such a massive and disruptive change that (in good 
conscience) I can't and won't do it during the lifecycle of a BlueOnyx 
build.

Like I said in another post on this list: As is right now there is no 
pressing urgency to rush a release of 5211R as 5210R is still good 
enough. Neither BlueOnyx 5211R or EL9 for that matter have any "must 
have" components or features at this time.

So I'll do it right and when it's good enough for release, it'll get 
released.

I'm not entirely opposed to run the GUI off a separate (modern!) release 
of PHP. But why should I? Look at it this way: Updates of that PHP would 
have to be released by me whenever the need arises. And during the 
life-cycle of 5211R that need will surely arise more often than we can 
anticipate now. And eventually the makers of PHP will EOL that 
particular PHP version long before EL9 goes EOL. As it is right now with 
the OS supplied PHP: Upstream (RedHat) still maintains the PHP bundled 
with the OS until the EOL of the OS itself. And they patch security 
holes in it long after anyone else has thrown the towel maintaining said 
PHP version.

Eventually we reach the point where I will have to take the OS supplied 
PHP SRPM, extract RedHat security patches from them and need to apply 
them to our custom AdmServ PHP. That's a somewhat shitty proposition, as 
it adds to my workload for no real gain.

Like Chris said yesterday: Use the OS supplied PHP. Or use the Shop 
PHPs. That's good enough for not only typical, but also most (if not 
all) of the exotic usage cases. And that's kind of where I should draw 
the line unless I get a compelling usage case that is universally 
benefiting the majority of the user-base.

BlueOnyx isn't and never will be a Swiss army knife. I'm not inclined to 
cater absolute niche usage cases if it requires a disproportional effort.

-- 
With best regards

Michael Stauber