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

[Michael Stauber]

Hi all,

Some more updates on the BlueOnyx 5211R development:

It turned out we need in fact a separate PHP for AdmServ. Which is 
something we wanted to avoid for reasons posted above. But it turns out 
it cannot be avoided for reasons beyond our control.

Shop PKGs with PHP GUI pages are encoded with IonCube encoder. Most 
prominently the NewLinQ GUI pages, as these handle the license 
management. Obviously we need to protect the means and methods used 
within these. Hence the encoding in those and as proprietary commercial 
add-ons they are shipped under a different license than BlueOnyx itself. 
Whereas all GUI pages that ship with BlueOnyx itself are free of such 
encoding to adhere to the Open Source ideals.

Now I got to a point where I was building the "solarspeed-ioncube" RPM 
to satisfy the dependencies we need to let AdmServ (and the regular OS 
provided PHP 8.0.13) use the IonCube Loader. Turns out: IonCube does NOT 
offer a loader for PHP-8.0. They do have one for PHP-8.1, though.

When asked about this oddity they explained that they had skipped 
PHP-8.0 to chafe off a few months of development and had gone straight 
to PHP-8.1. "Which is better anyway." Yeah, sure <sigh>.

So ... no IonCube for PHP-8.0. What now?

That meant we had to use another PHP version for AdmServ. One for which 
IonCube provides a loader. Like PHP-7.4 or PHP-8.1. Now PHP-7.4 would 
have the benefit that the GUI would run on it "as is" w/o further 
changes. At least as far as older CodeIgniter 3 and the PHP pages are 
concerned. But I'll not ship BlueOnyx 5211R with an outdated CodeIgniter 
and a PHP-7.4 that is already EOL or as good as EOL. I'm not even sure 
if PHP-7.4 would compile on EL9 due to OpenSSL 3 and the more picky GCC 
it uses.

So PHP-8.1.9 it is for the moment. I scripted an automatic update 
process on a devel box that will spit out updated "admserv-php" RPMs for 
5211R whenever a new PHP-8.1 version is released. That script then 
publishes the RPM and SRPM to an internal YUM repository from which I 
can test them before release. So we got that covered nicely. Eventually 
when PHP-8.1 goes EOL, the GUI will switch to a more modern PHP version.

The change to PHP-8.1 for AdmServ also necessitate the switch to 
CodeIgniter 4.2 for the GUI, which is a process that was already started 
anyway. PHP-8.1 also required that we ditch the PHP PECL extension 
"crack". That provides PHP with an interface to "cracklib" for password 
strength tests. That extension hasn't been maintained in more than a 
decade. While it was still available for PHP-8.0 it finally doesn't play 
nice with PHP-8.1 anymore. But we already had a replacement for that for 
years (via an internal PHP Class), as it was clear that this would 
eventually happen.

There are some more causalities:

* Mailman: "It's dead, Jim!"

   I can't get it to build and so far nobody has Mailman 3
   RPMs/SRMS that work with EL9 due to an insane amount of Python 3
   related dependencies.

   Should this situation change and evenutally someone builds EL9
   RPMs for Mailman (and its dependencies!), then it will be added
   back in. But for now: It's gone.

* Net2FTP: We used that PHP based file manager in 5209R and 5210R to
   allow people with FTP, SCP or Shell access to manage their files
   via the GUI. That project is dead since 2019 and the PHP code of it
   failed horribly under PHP-8.0. I don't even need to test it under
   PHP-8.1 to know that it won't work.

   So that one is a goner, too. Any other good solution I found is either
   payware, or so horribly insecure or so bland, that it would be madness
   to include it. Eventually I'll throw in a simple file manager via
   regular GUI methods as replacement, though.

Other than that things are looking good. For the rest of the stuff I 
have all dependencies satisfied. With CodeIgniter 3 and PHP-8.0 I had 
the GUI working except for some minor glitches. And with PHP-8.1 and 
CodeIgniter 4 I'm in a stage where I'm still sorting out a lot of 
fundamentals because of the many changes in both CodeIgniter and PHP, 
which require a lot of tinkering in pretty much any library, module and 
GUI page.

That work is progressing nicely by the day (and nights), but it's too 
early to say when an end to that might be in sight. But this is bread 
and butter coding without any large surprises.

-- 
With best regards

Michael Stauber