Print this page

News

2014-10-22 19:22:35

YUM Update: sausalito-cce


Updated sausalito-cce-* RPMs have been published for all BlueOnyx versions.

Category: General
Posted by: mstauber

The BlueOnyx GUI heavily depends on the daemon "CCEd", which provides an interface between the GUI and the underlying OS, the authentication mechanism and the CODB database backend. CCEd can be accessed from PHP, Perl and Python and a cceclient is also available from the shell.

When we introduced the new "Chorizo" GUI for BlueOnyx (as used in 5207R and 5208R) it became apparent that our CCEd had a stability issue. The issue has been around for a long time, but the heavier and more frequent usage of CCEd by the new GUI just made that more prominent.

The problem usually manifested itself in one CCEd child process entering Z-state (Zombie state) and getting entirely unresponsive. As a result the GUI would hang - as well as Perl based scripts and cronjobs that interface with CCEd. Such as our "Active Monitor" Swatch.

Several bughunts remained unconclusive, so work arounds were applied. Both a cronjob and a component in the GUI itself would monitor if CCEd was responsive. If it wouldn't respond within 5 seconds, then CCEd would be killed off and restarted. And as "Jolly Jumper" aptly says in the comic below: "And that's what he calls a solution!"

No, of course it's not. It's at best a temporarily applied band aid. 

So we're happy to anounce that we found and squished the bug that turned CCEd into an unresponsive slug. \o/

Updates were pushed out to the YUM repository for all BlueOnyx versions and if you're fully YUM updated, then you should already havee notice the enhanced stability of CCEd.

The road to 5209R:

Speaking of CCEd: In the comming days I'll renew the work on BlueOnyx 5209R for EL7 (CentOS7 / Scientific Linux 7).

With the transition to EL7 we were facing three obstacles:

  • Sausalito's CCE PHP module wouldn't compile against PHP-5.4. This is needed for PHP to interface with CCE.
  • Sausalito's i18n PHP module wouldn't compile against PHP-5.4. This is needed for the internationalization of the GUI.
  • Systemd as Init-Service does a whole lot of things different and none better than the old InitV service.

After some brainstorming on the developer's list we decided to abandon the Sausalito PHP modules. The PHP interface to CCE will be rewritten entirely to communicate directly with the Unix socket of CCEd without taking a round about through a Zend-API module of PHP. The functionality of this will be outsourced into a separate PHP Class.

The i18n Zend-API PHP module will also get dropped and will be replaced with a PHP Class that uses native i18n functions that (since long) have been available in PHP itself. When Sausalito was initially designed, this was still in its infancy, but by now PHP has a pretty solid and native i18n engine. Using it instead of our own PHP module therefore eleminates some overhead and redundancy.

Additionally: When we drop these two PHP modules, then this also removes the requirement to keep a certain OS provided PHP version at hand to satisfy the needs of the BlueOnyx GUI.

Lastly ... Systemd: I have absolutly nothing good to say about this ridiculously bloated, complex, buggered and sad excuse of an Init service, or the idiots who thought it worthwhile to incorporate it without alternative into almost all mainstream Linux distributions. Even bloody Debian is about to jump ship there and they won't be the last. If we wanted to provide BlueOnyx with a reliable and simple Init service that just does the job it's been told to (without asking you if you want fries with it), then we'd be left with exactly three choices: Gentoo, OpenBSD or creating and maintaining our own distribution from scratch. None of that will be happening and if we want to stick with CentOS or SL, then (sadly) we're in that bloody same pond that RedHat ditched us into when they adopted Systemd.

So ... we'll get used to it. But we don't have to like it.


Previous page: API Documentation
Next page: Downloads