This is an old revision of the document!
Multiple MySQL databases per Vsite:
This is really needed. Will be the next feature on the list in the coding pipeline. We need to allow Vsite admins to create and manage more than one MySQL database. Additionally the server admin should have the ability to place an already existing database under the management of an existing Vsite admin.
Multiple PHP versions at the same time:
Let me talk about this from a technical perspective. The problem starts with how you tie these different PHP versions into Apache on a per Vsite level. Say your Apache runs with the DSO. Then all sites that use the DSO are tied to this version of PHP. Which can be the stock one, or an upgraded one.
So let us just talk 5209R here for a moment. We have the smallest user base there and it's still Beta and we can drastically alter its functionality without rocking the boat too much.
Right now that has:
If we allow multiple PHP versions, which implementations would allow us to use different PHP versions?
DSO or DSO + mod_ruid2:
AFAIK: Not possible.
Possible via some wizardry with “AddType” and “AddHandler”. Works fine.
PHP-FPM / FCGI:
Easily possible. But then you'll have one PHP-FPM daemon (with its own Vsite pool) for each PHP version that's installed. You'd just need to move Vsites from one PHP-FPM pool to another to make this work.
So we would have two options that do allow this. This requires some architectural changes in base-apache and base-vsite. Also the PHP PKG building procedure needs to be changed, but it's doable. At this time all updated PHP versions install into /home/solarspeed/php/, so they cannot co-exist. Each PHP version needs its own directory.
This also goes one step further:
If such a new PHP version is installed, it would no longer replace the DSO version that Apache uses. Instead we need a pulldown there that lets the server administrator decide which PHP version he wants to use as a default on his box:
Likewise the naming of the PKGs (both on a file level, package name and NewLinQ name) must be different enough so that a side-by-side install of several of them at the same time is possible.
Yet: How do we handle upgrades? If someone has PHP-5.4.37 installed and installs PHP-5.4.38, then does he end up with both and has to switch +200 Vsites manually from 5.4.37 to 5.4.38? So we probably would want to allow separate PHP-5.3, 5.4, 5.5 and 5.6 versions, but only one for each category to automate updates.
So this needs some exploration and tinkering about means and methods, but I'm on it.
But like said: This is such a fundamental change that we can only do it for 5209R. Anything else would rock the boat too much and has the potential to interrupt services for existing users.
CMU is good and has lots of it past quirks ironed out. We also have a top-notch documentation on how to use it step by step. Still: Ideally there should be a GUI method for moving Vsites and Users from one BlueOnyx to another (same or different model of BlueOnyx).
Additionally there should be an import option to allow importing Vsites and Users from other platforms such as cPanel, Plesk and DirectAdmin.
Logins with firstname.lastname@example.org?
This is hellishly complicated to implement for the GUI and all other authentication services. Especially in a way that it doesn't break existing (traditional) authentication. We might not be able to pull this one off for all services. But it should at least be explored if it can be done for the email related services and maybe for the GUI.
Reseller Management: Needs more intuity
All you really need to do is this:
“Server Management” / “Server Administrators”: Add a new user.
Under “Virtual Site Administration” configure the maximum disk quota usable for Vsites + Users, numbers of Vsites he might have and numbers of Users.
Under “Administrative Options” give him these two rights:
Under “Virtual Site Management: Additional rights” you can configure which Vsite options (such as PHP, suPHP and so on) are available to him.
Granted: This might not be intuitive enough. How can we make it more intuitive? I thought about this. How about we create a separate menu entry below “Server Administrators” that's just named “Reseller”. In it we strip all options away which aren't related to the reseller management, such as all the “Administrator Options” that grant rights beyond what a Reseller needs?
GUI layout & user experience:
What menu or layout changes (if any) would enhance the user experience?
When we look at comparisons of web based server control panels, then one feature is often mentioned: Ability to manage multiple servers via the same GUI. I asked myself: How useful is that? What's the “added value”? But that feature is there and others have it.
We could do this, too. Via various methods. The most extreme one would be to (securely and locked down) expose the CCE socket via PHP to the net. Similarly like we do with the API.
As is even the new BlueOnyx GUI isn't totally “uncoupled” and does a few things directly via PHP system() calls. But these few instances could indeed be “uncoupled” to run everything through a CCE socket. Either the local socket on the same box, or a remote socket on another box.
It could work like this: You login to the GUI of ns1.xxx.net and do your things. Then you want to do something on ns2.xxx.net. Instead of typing its URL into the browser bar, you would click on the pulldown in the GUI that currently shows that you're on ns1.xxx.net and select ns2.xxx.net from it. Which will automatically log you in to that GUI.
Even if we don't expose CCEd via net-socket: I could hack a small add-on to BlueOnyx which works similarly. Instead of using the GUI on ns1.xxx.net to manage ns2.xxx.net, it would indeed connect to the GUI of ns2.xxx.net and would log you in there automatically.
Drawback: The way auth works on BlueOnyx, we need to store the “admin” passwords in one way or another on all servers that are “linked” together in this fashion. The other way around would be to not automatically auth. In that case you would get the “your login expired” on the redirect and would need to sign in on the 2nd box. Which is the better approach security wise. Like said: This could easily be done.
However: The consensus about this feature on the developer list was favoring not to pursue this particular idea for the moment, as it doesn't add enough tangible value compared to other features.
Service Status & Service Start / Stop / Restart in the GUI:
Show the status of the services in the GUI with the possibility to start / stop / restart the service. Today we have the status check but this I do not mean. It should be a site with all services and the three options. Example: Apache Start Stop Restart Sendmail Start Stop Restart Dovecor Start Stop Restart […] If the service runs it is green, if it is starting / stopping it is yellow. If it is stoped it is red.
Not only subdomains as additional domains with its own directory in a vsite
The ability to have additional fqdn in a site. It can be handled like subdomains but should be fqdn (full qualified domain name).
Note by mstauber: This is already there via “Web Server Alias” and the “Web Alias Redirects” checkbox.
Different Editions / Better Shop integration
My suggestion for three differenz Editions:
I also do not like newlinq. Sometimes it is confusing me with old versions and so on. Michael started to build a process for a better integration for the shop. This should be continued. Maybe plesk can be the benchmark. Integraed add on installation and the necessity for a license key for app ons which are not free.
Note by mstauber: The rental schema for Standard/Professional BlueOnyx is something that Greg and I already did some preliminary work on. We never got this totally done as there still some fundamental technical issues that we need to tackle. But yes: This needs to come.
Webmail as included application
It would be helpful to have a webmail in the free edition included again.
As is users may have a database (soon they might have more than one). This database(s) can - at the present - have literally unlimited space. There should be a quota system in place that keeps track of the MySQL database size for this Vsite.
If a Vsite has a total database size that exceeds a predefined quota, then the database(s) should either get set read only, or the MySQL access for that Vsite should get disabled.
This needs to tie into Active Monitor to send warning emails when approaching threshold or when a “Red” action is taken. Additionally this needs to get tied into the Reseller management, so that a Reseller might have X GB of MySQL database tables that he can distribute between Vsites. If that limit gets exceeded, action is taken, too.