So a while back I gave a primer and insight into what would happen with Kolab 3.0, and now we’ve released an out-of-schedule Kolab Server 2.4 – what’s that?
There are a couple of reasons for this. Firstly, the Kolab 3.0 development cycle is well under way, and progressing nicely for the most part, even if we may have to do some feature triaging for the 3.0 release depending on how many contributors come to the task in the next month or two.
But even so it is going to be some time before that release is out after some testing, and simultaneously the OpenPKG set of packages of the Kolab Server is ageing. Quickly. Providing security updates is something that would be done in the ideal world, but it takes around two weeks to wrap a release, as even an individual component easily means the entire stack needs to be rebuilt.
That’s a lot of effort for something that’s been discontinued.
From a business perspective it is also completely wasted, as there are zero customers of Kolab Systems on that particular technology base. None. Some other service providers may have paying customers on that basis, which is fine. But in the way they have chosen to maintain those customers on that basis without upstream support, they have themselves chosen to become the upstream for the solution their customers are on. So we gladly give them everything they need to provide such updates for their customers, but they’ll have to do the work themselves, I am afraid.
Naturally they could also hire us to do this for them. But I’d rather prefer if they didn’t, because this packaging base and some of the technology contained within is fundamentally unmaintainable, while the new basis is much leaner, more modular and each component can be updated as required without affecting the entire stack. In other words: Up to date (release) engineering.
In any case, even if an employee of ours were hired for another OpenPKG release, that person would be missing from other activities, such as the native packages available through our software subscription for customers with upstream support. So I’d much prefer to have the employee work on that, to be honest.
At the same time, we do not want to let our community be without an update for too long, and we want to lower the barrier to becoming active in the Kolab 3.0 development cycle. The answer to all those questions was the intermediate Kolab 2.4 release. That release already gets so many things right that we really encourage anyone with interest in Kolab, Roundcube or Free Software Groupware to take a look themselves.
The fastest way to a running virtual machine is if you’re on Fedora 16 or 17 and have the virtualisation packages installed & the service running.
Simply run the script below kindly provided by Jeroen van Meeuwen, our Systems Architect.
Or take a look at the quick installation instructions on the kolab.org web site.
Fastest way to Kolab, courtesy of Jeroen van Meeuwen
Assumptions to the script:
- Purely demonstrative,
- Assumes libvirtd managed ‘virbr0’ network,
- Assumes no kolab-demo system already exists,
- is to be executed with something like as follows:
- sudo TMPDIR=/path/to/my/tmp/dir /path/to/setup-el6-k24.sh
Save the following as setup-el6-k24.sh and make it executable (e.g. chmod 755 setup-el6-k24.sh):
#!/bin/bash
virsh destroy kolab-demo
virsh undefine kolab-demo
rm -rf ${TMPDIR:-/tmp}/kolab-demo.img
qemu-img create ${TMPDIR:-/tmp}/kolab-demo.img 8G
virt-install \
--name=kolab-demo \
--ram=2048 \
--vcpus=2 \
--disk="path=${TMPDIR:-/tmp}/kolab-demo.img" \
--location=http://mirror.switch.ch/ftp/mirror/centos/6/os/x86_64/ \
--extra-args='ks=http://hosted.kolabsys.com/~vanmeeuwen/ks.cfg' \
--network='bridge=virbr0' \
--hvm \
--virt-type=kvm
