Monthly Archives: August 2017

Orabuntu-LXC Announcements

Modular Design

Orabuntu-LXC is undergoing some major revisions.

Earlier this year Orabuntu-LXC modifications to support multi-host deployment got underway.  As that work progressed, it became clear that the code base was getting unwieldly in it’s current form.  When Orabuntu-LXC was originally coded, it began as a bunch of manual scripts that were translated into a set of 5 bash scripts that were essentially a monolithic start-to-finish installer-deployer.

The non-modular design of Orabuntu-LXC began to become a nagging issue that up until now had been ignored, but now with multihost and other features planned Orabuntu-LXC is being redesigned as modular software.   The multihost additions add alot of code that should be generic across the 3 code trees of Ubuntu Linux, CentOS Linux and Oracle Linux/RHEL but in the current design must be redundantly added to each of the 3 code trees.  This consideration was one of the drivers for identifying common code and moving to modular design.

The code trees orabuntu, lxcentos, and uekulele have much code in each tree that is generic and identical across the three trees, and up until this modular redesign, changes had to be redundantly propagated to each code tree.  With the new modular design, modules that are generic across all trees will be maintained as a single piece of code to avoid code anomalies across the 3 existing tress that support Ubuntu Linux, CentOs Linux and Oracle Linux (UEK)/RedHat Linux.  Of course, this will also simplify maintenance of the code as well.  It should also lead to better code, because the longer term goal will be to have every module include the branching required to make it generic across all trees.  However, if there are cases where code is better suited to be unique to that code tree, then multiple versions will be supported if there is good justification.  Overall, this redesign should lead to much better quality of design and coding.

Conversely, code that currently but does not necessarily need to be tree-specific/distro-specific, such as package deployments of yum vs apt-get will initially have separate code in the first cut to modular design, but later efforts will be made to make each module capable of branching to work with all supported distros, as one genuine piece of code with no different versions across the distro code trees.

Another consideration that drove the decision to take the time to recast Orabuntu-LXC as modular design software is that in time it is planned to add additional distros such as Debian, Fedora, OpenSUSE and Gentoo.

The other reason for going to a modular design is in preparation for building a GUI for Orabuntu-LXC since part of the plan for Orabuntu-LXC has always been that it will become a containerized replacement for hypervisor-based products such as VirtualBox, VMWare Player, KVM, etc.  Modular design will allow program elements to be added to the GUI and called by the GUI for atomic tasks rather than the monolithic binary design which constituted Orabuntu-LXC’s genesis.

Modular design also should make collaboration more accessible should additional workers fork Orabuntu-LXC.  To be sure, Orabuntu-LXC has not been forked much yet, although it is now watched by 37, starred by 16 and has been forked twice.

Well I guess those are the main considerations for the somewhat timely and also time-consuming work recasting Orabuntu-LXC as a hopefully modular design.

SCST Storage Layer Improvements

The other significant update is regarding the Orabuntu-LXC storage layer SCST (for more info see website).  While on the uekulele tree for Oracle Linux/RHEL Orabuntu-LXC has long had support for built RPM packages from source (which are auto-rebuilt on kernel upgrades transparently to the user) regrettably on the Ubuntu Linux side the source build deploy of SCST was just a source build that required users of Orabuntu-LXC to rebuild SCST from source after each kernel update.

Orabuntu-LXC was very excited to announce in late July that it now automatically builds DKMS-enabled SCST packages and installs them automatically for Ubuntu 15.04-17.04+ which means that SCST modules are managed and auto-rebuilt on kernel upgrades by DKMS and so therefore both sides of the Orabuntu-LXC house, RHEL-based and Debian-based now have a storage solution that maintains and rebuilds itself so to speak across kernel upgrades and so loss of SCST service after a kernel update is now a thing of the past for any Orabuntu-LXC deployment.

The Grateful Dead

Lastly, Orabuntu-LXC got some great help from Christian Brauner on the Canonical LXC team providing some help on new design features in LXC 2.0.8 that had temporarily left Orabuntu-LXC functionality on the Ubuntu Linux side dead in the water. This problem turned out to be because Orabuntu-LXC was using some LXC functionality that was outdated and deprecated.  The changes recommended by Christian Brauner were immediately implemented and functionality was restored.

You can read more about the resolution of that issue if you are interested here:

The project is very grateful to Christian Brauner for his help.  Christian’s help got the Ubuntu side of Orabuntu-LXC back on track!


All in all July was an exciting if hairy month for Orabuntu-LXC project.  It began with frustrating code failure on in the Ubuntu Linux code tree due to the aforementioned issue that was solved by Christian Brauner and implemented by me, and ended with a triumphant success providing the community with a generic SCST Linux SAN fully-automated DKMS-compliant solution for building and installing DKMS-enabled *.deb packages for SCST.  That SCST solution by the way is generic and can be used even if you are not using Orabuntu-LXC.  I’m really pleased to be able to give back to the community a really good SCST install solution for Debian-based systemd-enabled Linux distributions.

It’s important to note that the SCST solution relies very heavily on my fork of Martijn Grendelman’s scst-3.x-debian Github here and that in addition to Martijn, work was done on that original github for SCST Debian support by Fajar A. Nugraha and Adrian Stachowski for early work on this as well.

Orabuntu-LXC is not a major collborative effort at this point, but as the Stones sang:

You can’t always get what you want
You can’t always get what you want
You can’t always get what you want
But if you try sometimes well you might find
You get what you need

And so thanks to some indirect help from Martijn, Fajar and Adrian, and some direct help from Christian, the Orabuntu-LXC project rolls on…