BlueOnyx IPv6 Support

Some impressions from the IPv6 support that is currently in development for BlueOnyx 5209R.

I thought I'd share some impressions from what I've been working on for the last couple of weeks: The long awaited IPv6 support for BlueOnyx!

"System Settings" / "TCP/IP":

As you can see here: We retained the old form fields for IPv4 IP address, Gateway and Netmask, but added "IPv6 Server Gateway" and the "IPv6 IP Address" fields for the various network interfaces.

If you only enter the IPv4 details, then IPv6 will be disabled. If you only configure IPv6, then IPv4 will be disabled. If both are specified, then your server will be available via both protocols.

"System Settings" / "IP Address Allocation":

The IP Address Allocation allows to specify IP address ranges which can be used for Vsites on the server. If you use Reseller accounts, you can also specify which IP address range(s) a Reseller can use for his own Vsites. As you can see here: A range can either have a start/stop IP address in IPv4 format, or in IPv6 format. The input form for that takes both and is smart enough to validate IPv4 and/or IPv6 at the same time via a regular expression.

"Site Management" / "Virtual Site List":

I think this is the "money shot". As you can see: The column "IP Address" now shows the IPv4 and IPv6 IP addresses of Vsites. Vsites can indeed have either an IPv4 address, IPv6 address or both at the same time. As IPv6 IP addresses can be quite a bit longer than IPv4 IP addresses we loose a bit of display width for the "Full Host Name", though.

"Site Management" / "Template":

The Template for new Vsites inherited a field to enter an optional IPv6 IP address as well, provided IPv6 is enabled.

"Site Management" / "Add Site":

The obvious change here is - of course - that the field "IPv6 IP Address" has been added and that the old "IP Address" field on top got renamed to "IPv4 IP Address". But you might also notice that both now show "(optional)". No, you can't create a Vsite and leave both blank. In that case you will get a (new) error message that reminds you of this. But you can leave either IPv4 or IPv6 blank. As long as a Vsite has at least one IP it'll work.

I also changed and extended the routine that shows the IP address ranges below the input forms. Which are of course only visible if "IP Address Allocation" is enabled. If you're logged in as systemAdministrator ("admin" or similar), then you will see which users are allowed to use a given range.

"Site Management" / <Vsite> / "General Settings":

This is how it looks in the Site Management of an existing Vsite. No surprises there.

Developer shoptalk:

The IPv6 integration wasn't entirely without challenges, because the network stack of the GUI is now old enough to vote and drink. In certain areas it was flying a mile behind the cockpit, because we still used the traditional command line tools to manipulate the network settings, whereas our underlying OS (CentOS 7) has since long switched away from using "ifconfig" and "route" to use the "ip" command instead. Likewise we were also still using aliased network interfaces for every extra IP beyond the primary IP. The initial plan was to do away with the aliased network interfaces and have our change_route.pl Handler dynamically bind any IPv4 and IPv6 IP address beyond the primary IPs. However: While this worked just fine it rocked the boat too much during an upgrade. Hence we continue to follow standard practices and keep the network alias files for IPv4 and use "IPV6ADDR_SECONDARIES" in the primary network config file to allocate and bind extra IPv6 IP addresses beyond the primary IPv6 IP address.

This is how it looks on the command line:

The first command I've run up there is "ifconfig", which shows us the configured network interfaces. In this case there is only "eth0" which has the primary IPv6 IP address and it has also bound all IPv6 IP addresses. Then you see the network alias files like eth0:1, eth0:2 and so on, which bind the additional IPv4 addresses. Keep in mind that the "ifconfig" command will get deprecated eventually and it already shows its age here.

Now if we take a look with the "ip" command instead and pass the right options, then you see all bound IP addresses. Lines with "inet" mean IPv4 IPs and lines with "inet6" show the bound IPv6 IPs. You can see that here:

Additional goodies:

CCEd UPDATE command:

While I was at it I also rewrote a hell of a lot of handlers and constructors with an emphasis on speed. For this several new CCE methods were introduced. When constructors run during a CCEd restart, we did a lot of SET transactions to CODB while we were synchronizing the system configuration files into the CCEd backend. While GET transactions (fetching data from CODB) are blazingly fast, SET transactions (writing data into CODB) are very costly in terms of time needed. Hence I introduced the UPDATE command. It works the same as a SET command and can take individual key/value settings or an array of them too write the off to CODB. Bbut it does a GET first. Then it checks if whatever it's supposed to write into CODB is already present without any changes. If whatever it is trying to set is already identical, it does nothing. If there are differences, then it does the SET command only for those keys whose values are currently not up to date in CODB.

I modified *all* constructors of BlueOnyx to use the UPDATE command wherever it makes sense and the speed increase is dramatic during full CCEd restarts.

Rewriting of <VirtualHost> containers via Handlers:

The modularity of Sausalito brought it with it, that certain modules need to write to the Apache config files of Vsites to add the features they bring with them into existing <VirtualHost> containers. We do have a pretty solid engine which supports editing of config files of all kinds of formats. Yet, when about a dozen scripts try to have a go at the same file at the same time (or in rapid sequence), things get a bit murky.

Over the last decade we've had a few cases where things then might go missing. Like webserver aliases, PHP settings and what not. All of these bugs eventually got squashed (but one), but all of them were a nuisance to track down. No more of this: I rewrote all Handlers that deal with <VirtualHost> changes and there is now only *one* handler that does it all in one go. That one handler covers everything from SSL settings, aliases, PHP, CGI, SSL settings, redirects and what not. And the same handler is used during Vsite creation as well as Vsite modifications. Meaning: The <VirtualHost> container is rewritten from scratch during edits, making sure it has everything it needs.

This also cuts down massively on the HTTPd restart/reload requests, because in the past many <VirtualHost>-editing handlers were of the opinion they need to perform a HTTPd restart/reload. Because we never could be sure if they were the last handler that would run or not. So we had a stopgap measure in place which cut down on the restarts by queing them and eliminating duplicates from the queue. That's history now as well and we restart Apache only once after all edits are done.

This also speeds up certain GUI transactions and will be immensely beneficial during CMU-Imports as well.

When will it be released?

Ah, you know the drill: When it's ready. ;-)

I want to be *really* careful here, because it's supposed to go out as a regular BlueOnyx 5209R YUM update. However: During the YUM update the existing network configuration isn't touched, so we're pretty safe there that nothing undue happens. Hence I am currently looking at a release date within the next couple of days. Like the night of 8th to 9th February.