5210R: Development Diary #1

Some feedback on the development of BlueOnyx 5210R on RHEL8 beta.

As you might know, the development of BlueOnyx 5210R for EL8 started recently when RHEL8 beta came out. Of course we're targeting to release 5210R on CentOS8, but the RHEL8 beta should give us a good idea of what to expect and to line up all the ducks for the time when CentOS8 finally comes out.

TLSv1.3

One of the bigger benefits of EL8 is that TLSv1.3 is now supported out of the box. That's a big step and something to look forward to.

However, there are other things that I'm less pleased with as a developer as well as a user. This isn't about shifting blame or telling you what shoddy job RedHat did this time around. Because they haven't. But it is - at this time - not all roses.

Apache, Nginx, HTTP/2

The Apache 2.4 that ships with RHEL8 beta has a module that allows us to directly use HTTP/2. Ain't that cool? We could actually do away with the Nginx HTTP/2 proxy for HTTPS, right?

Sadly: Nope. We can't and we won't.

This Apache HTTP/2 module is a prime example of the German saying: "Das sieht aus wie gewollt, aber nicht gekonnt." That loosely translates to "It looks the way it was meant to, but they couldn't get it done." And it's exactly that: Garbage.

While Nginx handles the the selection of HTTP/1, HTTP/1.1 or HTTP/2 in the negotiation stage of the connection, Apache 2.4 (even with that shitty HTTP/2 module) doesn't. And it won't upgrade a HTTP/1.1 connection to HTTP/2 as long as the GET request contains a payload. Which it usually does. So in principle Apache 2.4 *can* do HTTP/2 if said module is activated, but for all practical intends and purposes: It won't. That's a big "Are you f*cking kidding me?!?", but that's how it is.

But fine: In that case we continue to use Nginx as optional HTTPS-Proxy with HTTP/2 support. Screw it.

Perl modules and compiling dependencies

With any new OS release that I port BlueOnyx to there is always the issue that our existing code has certain dependencies. For example: We use the GD image library somewhere from within Perl. So we need "perl-GD", "perl-GDGraph" and "perl-GDText" for example. Or perl-JSON, perl-Quota and a few others. All in all there are about 45 Perl RPMs that I needed to build on my own for EL7 in order to get everything pieced together so that BlueOnyx did run on EL7. Should be easy to build them for EL8 as well, right?

The ways how I did and do build Perl related RPM modules differs on circumstances. Sometimes an RPM I need is available on EPEL. In that case I might do the lazy thing and grab the SRPM, rebuild it and shove the resulting RPM into the BlueOnyx repository. Sometimes EPEL comes up blank, but RPMfind or PKGs.org or some other site has it listed in a new enough version *and* links to a downloadable SRPM. Other times I simply used the shell-script "cpan2rpm" and if that didn't work then either its newer cousins "cpantorpm" or "cpanspec" would get used to build the RPMs.

For RHEL8 I was directly pulling up blank on 40 of our 45 dependencies. Worse: "cpan2rpm" doesn't work reliably enough anymore, "cpantorpm" would insist in installing the Perl Modules into the wrong directories. And "cpanspec" was missing about 38 Perl module dependencies itself just to get itself running. Go figure!

Which is funny, considering RedHat supposedly used "cpanspec" themselves. Yet the RHEL8 beta they ship is missing most of the Perl related modules to get even "cpanspec" working? That's almost cute!

So at the end I had to use the CPAN-shell to do a direct install of all dependencies of "cpanspec" on my build box. Just so that I could then start to crank out Perl module RPMs myself. This will bite me in the ass in the long haul, as I now have Perl modules installed that didn't come aboard via RPMs. I need to trace back that path to identify them all and the build proper RPMs for these dependencies.

Just today I had to build 64 Perl module RPMs to satisfy the dependencies that building perl-GD did require.

To say that the RHEL8 beta YUM repository is missing many very common and often used Perl module RPMs would be an understatement. It's devoid of a lot of really essential things and that's quite a shame.

But it gets worse:

We need perl-Quota. And it doesn't build. Now perl-Quota is fairly old and has provisions for different OS's - including AIX and Solaris. For Linux is uses a generic header-file that assumes that our Linux has RPC support. It had. Once upon a time we had that in GLIBC. Then it got thrown out and moved to glibc-compat. Which we don't have either for RHEL 8 beta. At least not yet.

Some sources and header files of what we'd need were moved into 'libtirpc' and 'libtirpc-devel', which RHEL8 beta has available. But that's only half of the requirements. I went as far as trying the Fedora 28 and Fedora 29 SRPMs as well, but they have the same issue and this show us that RedHat 8 beta has cut off an old bun and burned a bridge that we still need to cross somehow.

There are quite a few things left to compile and I imagine I will continue to have to chase RPM dependencies for at least two more weeks until I can even get the basic BlueOnyx GUI up and half way running.

Some stuff doesn't compile at all at this time (ProFTPd for example). The compiler throws some serious warnings chucking through the code of ProFTPd. Which isn't exactly new, as each new RHEL version usually has a newer compiler with better error reporting and warnings. Which often results in old source code not compiling, because it's now finally tripping over the obvious code errors that always have been there. In real or imagined form, because the "guessing" of the compiler isn't always dead on.

And aside from perl-Quota and Proftpd there are another ~90 RPMs that are not directly BlueOnyx related that I already had to build as they aren't yet available anywhere for RHEL8 beta. And some of these have other complex dependencies which the RHEL 8 beta YUM repository doesn't yet have answers for.

So there are - at this time - a lot of early adopter issues. They will get fewer and fewer as more time goes by. Eventually EPEL will have an EL8 repository and that should ease many of these toothing pains.

In any way: Chasing dependencies back and forth is no fun at all. \o/

Development Fundraiser

As mentioned here we're currently raising funds for the development of BlueOnyx 5210R and for "EasyMigrate".

I'm happy to report that the targeted goal of 2500,- Euros in order to fund a new GUI theme has been met. This means that BlueOnyx 5210R will get a new GUI theme - yay! We're still looking for further donations, though, as - at this time - every little bit helps. It's a lot of work.

A very big thank you to everyone who has donated. It's deeply appreciated. Thank you!