BlueOnyx is an open source User Interface for virtual Webservers. BlueOnyx is built on top of the free CentOS or Scientific Linux operating system, which is binary compatible with Red Hat Enterprise Linux (EL). Over the years different versions of BlueOnyx were made for different versions of said OS's: EL5, EL6, EL7, EL8 and EL9.
BlueOnyx allows a Linux novice to install, administer, and manage a Linux-based Web server. The administrator will use a browser to use configure the server, virtual websites, users, DNS, FTP, and email accounts.
The user interface is available in the following languages: English, German, Danish, Spanish, French, Dutch, Italian. Portuguese and Japanese.
Cobalt Networks Inc. launched in 1996 as a garage company with three employees (Mark Orr, Mark Wu, and Vivek Mehra). The objective was to develop an Internet server, the pre-configured and ready to plug in - could be put into operation in a few minutes - even by laymen. In March 1998, these efforts bore fruit with the launch of the Cobalt Qube 1)
This cube-shaped server was initially designed as a workgroup computer for small and medium-sized enterprises, because it offered both Web and Intranet services. In addition to Web, email, FTP, the Qube also supported the protocols SMB and AppleTalk to act as a domain controller in local networks.
After the Qube, a similar Server in 19“ construction and especially for Internet Service Providers was developed. This product was called RaQ. The raq had the groupware functionality removed. There was an opportunity to operate up to 250 domains per server.
There were multiple releases of both Qube and RaQ over the years. The latest version of Qube was the Qube 3 The latest version of the RaQ was the RaQ550.
After Sun purchased Cobalt Networks Inc. for two billion dollars 2), development of the former cobalt Networks server products almost came to a complete standstill.
Despite statistics 3) that indicate over 3 million hostnames were hosted on cobalt servers in August 2002, Sun announced end of sale of cobalt RAQ and Qube in 2003 4)
In July 2003, 5) Sun released the source code of the Qube 3 as open source and under a modified BSD license.
Immediately after the publication of the source code under the BSD License, we saw the launch of Project Blue Quartz. The objective was to provide both for the very popular in Japan Qube 3, and for the RaQ550 alternatives on the basis of the now free source code.
BlueQuartz initially used Fedora. In early 2004, the project changed to CentOS. During the early days, BlueQuartz had to deal with some problems, as the underlying architecture was sometimes quite poorly documented. Later on former employees of Sun provided some extra documentation beyond what was already in circulation. However, that documentation also had many shortcomings or was more oriented towards marketing than technically minded developers.
In addition, some commercial developers also used the combined source code of Sun and BlueQuartz, creating competing platforms for users to choose from.
Added to this was the somewhat cumbersome procedure for installing BlueQuartz in its early phase. To do this, first had to install and customize the operating system. Then you launched an installer, the reconfigured the operating system, and conformed the components of the browser-based user interface installed.
In early 2005 Brian N. Smith of NuOnce Networks published a free Boot CD, providing both the configured operating system and BlueQuartz installed. Only then became BlueQuartz an increasingly growing acceptance and came first for all those in question, which had to replace a RaQ550 by more modern server hardware.
In mid-2005 Project BlueQuartz started. It was initiated by Hisao Shibuya as the lead developer at Turbolinux, Inc. - a Japanese Linux distributor. There they developed a commercial product on the basis of the published source code for the Sun RaQ550, which got called the Turbolinux Appliance Server 2.0. Which was als called TLAS in short. TLAS 2.0 was released in March 2006 6)
Just as BlueQuartz had accelerated the development of TLAS there was also a constant flow of development in the reverse direction, benefitting BlueQuartz itself. Improvements to the commercial TLAS also found their way into the source code of BlueQuartz. More often so BlueQuartz had fixes and new features earlier than TLAS, as the commercial product had slower release cycles than the Open Source project BlueQuartz. This eventually caused a conflict of interest, as the freely available BlueQuartz offered the same functionality as the 950 U.S. dollar priced TLAS 2.0 7).
BlueQuartz was mostly adopted among former operators of RaQ550 servers, who needed compatible replacements for their aging Sun Cobalt RaQs with more modern hardware. However, over time BlueQuartz also attracted new users that had no prior Sun Cobalt experience. According to statistics ← evaluation of server log files of the central YUM repositories of BlueQuartz.org April 2008 -.> (04/2008) of Project Blue Quartz run more than 135,000 Web servers worldwide with Blue Quartz (the numbers were counting Update operations collected and broken down by IP and may not be entirely representative).
The original Blue Quartz developers <ref> BlueQuartz: [http://bluequartz.org/aboutus.html The Team] </ref> were Hisao Shibuya, Yutaka Yasuda and Makoto Oda. In the end of 2006 Brian N. Smith of NuOnce Networks, Inc. and Michael Stauber from Solarspeed.net joined the team. Both had (since 2000) provided add-on software and services for Sun Cobalt server and its successor systems. The team was further strengtened by Taco Scargo, a former Sun Cobalt employee.
Although CentOS 5 was published in April 2007 the project management team of BlueQuartz did not appear to make any push to transition BlueQuartz to CentOS 5 8) and BlueQuartz so far was only available for CentOS 4 instead. Separate efforts of individual developers towards porting BlueQuartz to CentOS 5 found no support among the rest of the developers 9).
Eventually Brian N. Smith and Michael Stauber 10) decided to leave the BlueQuartz development team to create Project BlueOnyx http://www.blueonyx.it with a fork of the BlueQuartz code . The first release of BlueOnyx 5106R on CentOS 5 included many new features and was released on 31 December 2008 11)
Hisao Shibuya, Yutaka Yasuda and Makoto Oda continued to maintain BlueQuartz. However, the newer BlueOnyx and the departure of important developers didn't make their task any easier. Years later BlueQuartz managed another major release and published BlueQuartz 5200R, which was based on CentOS 5 as OS, but it was soemwhat rough around the edges and lacked an ISO install method.
The project BlueQuartz had fallen more or less dormant over the years and Team BlueOnyx is happy that Hisao Shibuya has joined us to aid with his amazing expertise in the platform.
Developed by Cobalt Networks Inc. architecture called Sausalito. Essentially, Sausalito is modular and functions can be retrofitted via modules (eg third party) 12) 13). Other Sun Cobalt related original documentation can be found in the BlueOnyx Developer Archive as well.
Sausalito consists of the following components:
The administration interface of BlueQuartz and BlueOnyx is programmed in PHP. Via so-called Skins or Themes the look of the admin interface could be customized, although the template architecture of the original GUI is by now somewhat antiquated. The UI runs on a customized Apache web server that is bound to a specific port (Port 81 - HTTPS / Port 444 - HTTP). This web server is running as an unprivileged user 'apache' (or 'admserv' in newer versions). However, it allows authenticated users to execute certain narrowly defined functions on the underlying operating system with superuser (root) rights. The level of privileges each user has is defined by Access Control Lists (ACL's) that operate on a per Group basis. Serveral levels of privileges exist.
If an authenticated user - provided he has sufficient privileges to do so - runs a transaction (such as creating a virtual site or user), then Sausalito writes an entry in an internal database. This database is called CODB. Which is short for “Cobalt Object Database”.
The Cobalt Object Database is an object-oriented database for storing parameters, settings and data of the web server.
Data stored in the database objects belong to Classes, which themselves can have separate NameSpaces. The format of Classes and their Namespaces is defined via XML Schema files. Such Schema files define the key/value pairs that a Class or NameSpace has. They also define which type of data can be stored into a “value” field. This immediately provides input validation as well. For example: If a database value is configured to only accept an email address, then data that doesn't appear to be an email address won't be accepted. Additionally the access controls for each key/value pair (or the entire Class or Namespace) can be defined in those Schema files. Here is one example of a Schema file BlueOnyx 5209R Apache Schema file)).
When CODB is tasked with the database manipulation (creating of Objects, modification of Objects or deletion of Objects - and their Namespaces) it always checks if the transmitted data is valid, if the user is authenticated and has the proper access control rights to perform this transaction.
CCE (Cobalt Configuration Engine) is the interface between the admin interface and CODB (Cobalt Object Database). It handles the authentication of users and compares them with the mechanisms for user management of the operating system. It also manages CCE database requests from the UI to read, write and delete Objects.
CCE consists of a Daemon, which constantly runs in the background, as well as a Client, which can be used as needed from the command line to perform administrative functions. CCE also runs certain scripts (Handlers and Constructors), which perform administrative tasks with superuser privileges based on startup events (Constructors: Run on CCE startup) or CODB database events (Handlers: Run on specific CODB transactions).
Via configuration files CCE can be configured to performs certain operations with superuser privileges when certain database fields are created, changed or deleted. For example it can be defined that if a certain Class is created or deleted, then a certain Handler should be run to modify config files. Or if a certain database field in CODB gets modified, then a Handler should run to publish these changes to the OS config files. In all cases these Handler runs can only be triggered by users with the proper access levels and after successful authentication.
A handler is typically a Perl script that can perform certain narrowly defined tasks on the file system of the server with superuser privileges. These scripts can only be triggered by CCE itself - for safety reasons. Handlers are for example used to create users or virtual sites, or to adjust configuration files of the server.
Like Handlers a Constructor is typically programmed in Perl and performs certain tasks on the file system with superuser privileges. However, a Constructor usually runs only once when the CCE daemon is started.
Constructors are typically used to read configuration files and to inform CODB of the state of the server by writing that data into CODB. Or values stored in CODB are published to the OS to make sure that the server operates on a known configuration.
Since the Cobalt days the communication between UI and CCE is done via a Zend API PHP module called cce.so. This extends the basic PHP interpreter of the server with special functions to communicate with CCE and CODB. This cce.so PHP module is only loaded on the separate webserver (AdmServ) that runs the GUI.
Additionally another Zend API PHP module (i18n.so) is loaded to provide PHP with the internationalization support needed to display the GUI in different languages. The i18n.so module provides an interface between PHP and the GetText locales on the server.
Naturally this creates a problem as far as the upgradeability of PHP on the servers OS is concerned: These two mandatory PHP modules are specially compiled against the PHP that BlueQuartz or BlueOnyx ships with. In order to work with a different PHP version they need to be recompiled. If the PHP version is drastically different, then these modules might no longer be compatible. For this reason upgrading (or replacing) PHP has always required certain “special” procedures. Or an install of the updated PHP into a separate directory.
BlueOnyx 5207R and BlueOnyx 5208R still use the PHP modules cce.so and i18n.so, but have a fallback mechanism in place. If these modules are no longer loaded (due to PHP compatability issues) the GUI will fall back to native PHP Classes that provide the same functionality. However, this comes at a small performance impact, as the PHP modules are faster than the PHP Classes.
Starting with BlueOnyx 5209R the PHP modules cce.so and i18n.so are no longer used, as we couldn't get them to work with newer PHP versions due to API changes within PHP. Since BlueOnyx 5209R all BlueOnyx versions use native PHP classes for communication with CCE and also for i18n localization.
Generally the source of BlueQuartz or BlueOnyx can easily be adapted so that it can run on any Linux or Unix derivative. For this purpose only minor adjustments to the source code and a recompilation of the sources might be necessary. Since all the advanced features of the BlueQuartz or BlueOnyx GUI are all modular it would be trivial to use it as a GUI framework for entirely different purposes.
In practical terms the adaption of BlueQuartz or BlueOnyx to different OS's (than the ones already supported) requires a wide range of skills and expertise and the lack of thorough documentation creates certain challenges. We are working on making it easier, though and this Wiki is one step into that direction.
PKGs are special packages that allow the installation of pre-packaged additional software. PKGs consist of files that have been packed with tar and gzip. Within a PKGs are RPMs, a list of files to be installed and scripts that run when installing or uninstalling the PKGs. Additionally PKGs can display license information and information about the included software that is presented in the GUI upon installation. A PKG has mechanisms to make sure that it can only be installed on versions of BlueQuartz or BlueOnyx that the PKG was designed for.
There is also a server implementation for the distribution of PKGs, which can be used to distribute PKGs (and their updates) to servers that are tied into this update channel. This distribution method is called NewLinQ and is used by the BlueOnyx Shop)).
After the release of the source code of the Qube 3 and the RaQ550 efforts were made from different companies and groups to build a similar solution based on this code. Not all were successful.