An early Horde4 release for Kolab-Server-2.2.4

A while back p@rdus promised an early alpha of Horde4 for the Kolab Server for today. Which would have been followed by the release of the Horde4 mail client and the new mobile mail view in the following weeks. But as the Horde developer team has been quick to provide the new mobile view there is no need to delay the delivery of the mail client and the mobile portal any further. So you get a little bit more than promised today but as it is St Nicholas' Day that seems to be just fair.

Of course all the usual warnings apply. This is an extremely early packaging attempt. It is not well prepared and the installation procedure is flawed. There will be no upgrade path. Doing the following on your server has a high chance of damaging the system. Do not even think about installing the packages on a productive machine. In addition the packages just install the mail part of Horde and won't provide a lot of new functionality. And since there are tons of issues the stuff that is new is likely to be broken.

But those of you who have a spare machine with a throw-away Kolab Server 2.2.4 can try to install the packages using the following steps (this assumes your server is up and running):

wget http://files.pardus.de/horde4-20101206.sh
chmod u+x horde4-20101206.sh
./horde4-20101206.sh

You should be able to access the Horde4 installation at http://your-domain.com/client4.

Any kind of feedback is of course appreciated and will be used to improve the packages during the months to come. p@rdus will also continue testing and bug fixing of the packages while the final phases of the Horde4 development continue.

Now there are no December items of the roadmap left. So p@rdus will continue the next weeks with highlighting the new elements you can expect to find in Horde4. This should be accompanied with a few bug fix releases. In addition it is planned to provide you with a demo server in case you do not have a spare machine to test the new packages. So stay tuned!

PHP library release survey

Tobias Schlitt is asking PHP developers and users about their preferences concerning the release process of PHP libraries. I figured I spread the word and provide you with the link to the survey.

The survey itself originates from an ongoing discussion on how to release Zeta components. It will certainly not allow to extract a generic guideline on how to release your PHP code but I think that is also not what the survey intends to do.

The central question of the survey "What is your preferred way of installing PHP libraries?" does only have one correct answer after all. But that one varies depending on the person asked and on the installation target.

"Man, I clicked this cool button on my webhosters site and now I got this webmail installed in just one go. What a nice custom installer!"

"I just love Ubuntu. I even have that on my server. If I need a PEAR IMAP library I can just apt-get install pear-horde-IMAP_Client. If I need Horde I run apt-get install horde4. And I get all the security updates automatically! Using your distribution or OS is really the only choice there is."

"I downloaded Horde and installed it on my dedicated server. Set it to run on lighty and it's blazing fast. I connected it to our LDAP user DB. Now I still need to get the Facebook and Twitter API keys so our users can connect to their accounts there. Unpacking and installing the tarballs was no major deal."

"I'm a PHP developer and I want to code a small application that needs to handle IMAP. It needs to be better than the IMAP stuff from PHP. But I don't want to code the protocol handling myself and I don't want to pull something totally unstable from a repo. And please don't give me a full framework. I just need IMAP. Oh, and in a year I might want to upgrade in case there were fixes to the package. Can I get Horde_Imap_Client via PEAR please?"

"Huh? I code Horde, I do some PEAR. Sometimes I pull stuff via the OS. For customers the tarballs are great. But at the end of the day: There is only git."

Screenshots of the new Horde4 mobile portal

As mentioned before p@rdus currently sponsors development of draft mobile mail and mobile calendar portals for Android, iPad and iPhone. These portals are based on Horde4 and the recently released jQuery mobile framework.

The Horde developers have been far quicker than they promised themselves and so without further ado here are some early screenshots of the projects:

• Login screen
• Portal
• List of folders
• Mailbox view
• Message view
• Month view
• Day view
• Event view

Now p@rdus still needs to ensure that these screens go live on a Kolab server near you. Packaging is progressing well and chances are high that you can try the alpha version very soon.

Resizing an EBS volume

If you run into size limitations with an EBS (Elastic block storage) volume attached to your EC2 instance it just takes a few minutes to expand the storage space.

• Unmount the small volume (assumed to be /dev/sda here).

unmount /dev/sda

• Detach the unmounted partition from the instance.
• Take a snapshot of the detached volume.
• Recreate an EBS partition from the snapshot.
• Attach the EBS disk to your instance.
• Resize and remount the larger volume with:

e2fsck -f /dev/sda
resize2fs -p /dev/sda
e2fsck -f /dev/sda
tune2fs -l /dev/sda
mount /dev/sda /somewhere

Installing the Kolab Server on Ubuntu 10.04

Just a quick note on the required steps to get the Kolab server installed on an Ubuntu 10.04 server. The first step pulls the required dependencies to be able to compile the Kolab sources:

sudo apt-get update
sudo apt-get install bison flex gcc automake libtool autoconf tcl

And subsequently the server code gets downloaded and installed via the standard commands from the Kolab wiki:

mkdir /tmp/kolabtemp
cd /tmp/kolabtemp
wget -r -l1 -nd --no-parent http://files.kolab.org/server/release/kolab-server-2.2.4/sources/
gpg --keyserver wwwkeys.pgp.net --recv-key 5816791A
gpg --verify SHA1SUMS.sig
sha1sum -c SHA1SUMS
sudo sh install-kolab.sh 2>&1 | tee /root/kolab-install.log

The Horde4/Kolab package mill

p@rdus established another Hudson based continuous integration setup in preparation of the first experimental Horde4 packages in two weeks. The new system bundles Horde4 packages for the Kolab-Server-2.2.4/OpenPKG and lives here.

Packaging the Horde4 source code for a distribution is nearly trivial as the basic Horde packages are already continously integrated and packaged as PEAR modules. Because of that it is likely that p@rdus will establish a similar process for the native Kolab-Server/Debian.

With Kolab currently planning to move away from OpenPKG it is also possible that p@rdus makes the native Debian port the primary supported platform for Horde4 on Kolab in the future.

Horde continuous integration

With the increasing complexity of a huge codebase such as provided by Horde there is a significant need for quality control. As p@rdus accumulated a decent amount of experience with a variety of PHP QA tools during the past years it was only natural to apply this knowledge to the Horde codebase.

Many modules - including the Kolab_* packages - are now under constant surveillance of a continous integration server. The system is available for your inspection at ci.horde.org.

The service itself is run by Hudson - the standard CI server these days. The tools deployed on the server are a collection of the latest and greatest in the arena of quality control for PHP. PHPUnit certainly being the most important one as it delivers the framework for unit testing and code coverage analysis. In addition Hudson runs PEAR CodeSniffer (style check), PHP Depend (structural analysis), PHP Mess Detector, and the PHP Copy Paste Detector. On top of this the brand new PHP Code Browser integrates the analysis results into a view of the code.

With this system in place Horde is probably the only PHP based groupware client that can claim to validate its code base against current commercial grade software standards for PHP with each and every commit.

Horde4/Kolab road map

The current version of the Kolab web client saw its first real release on the Kolab Server in December 2007 and is based on Horde3. In 2008 p@rdus promised the switch to Horde4 for 2011.

In the past months the Horde development team has steadily progressed towards the first release of Horde4. With that being in sight now it finally makes sense to provide a detailed roadmap for Horde4/Kolab.

• [06.12.10] Horde4 Portal
• [13.12.10] Horde4 Mail
• [20.12.10] Horde4 Mail on jQuery mobile
• [07.02.11] Horde4 Calendar
• [14.02.11] Horde4 Calendar on jQuery mobile
• [28.02.11] Horde4 Addressbook
• [07.03.11] Horde4 Tasks
• [14.03.11] Horde4 Notes
• [28.03.11] Horde4/Kolab Beta

Both jQuery mobile oriented projects are financed by p@rdus. These will not be able to compete with the full feature set of the default view but should be an interesting draft of mobile apps based on the Horde applications.

You are encouraged to measure the reliability of p@rdus on the basis of this timeline.

A server is a server is just a server

In the process of getting the Horde4 packages ready for the Kolab Server the p@rdus development environment needed some love. Besides a few minor updates it remained virtually unchanged during the last two years.

The process started with an update of the underlying Gentoo base. Which took a few hours to compile. And of course there were a few problems associated. Which also took some time.

Subsequently the configuration via puppet didn't really work out. Some additional obscure issues. More time.

And ultimately the bundling and upload of the updated image didn't work. Even Google wasn't able to help this time.

All that is fine if the required time is available and if the stuff learned while fixing the issues means progress for yourself. But it is a fact: there is neither the time nor does fixing obscure issues align with the targets at hand. The server setup and upgrade must complete in minutes and not hours. It is "just a server" after all.

Sigh... I love Gentoo. I have been a Gentoo developer. I wrote a book about this distribution. Giving up on my developer status for Gentoo was hard. Giving up on Gentoo... damn. Nevertheless: Farewell.

A new old PHP framework

With Horde4 the old "framework" block of code contained in the base Horde application will be split into its single component parts. This should help to underline the modular framework aspect of Horde itself.

The Kolab Server is one of the few systems that tried to use part of the Horde software stack even with Horde3. Both the free/busy system and the Resource management do not require more than a few packages from the Horde core framework.

With Horde3 this approach has always been somewhat awkward. The Horde release process made no use of the fact that the Horde framework was split into modules. With the Kolab Server we had to work around this limitation which resulted in the split packaging layout which will be available with Kolab-Server-2.3. But this is hand made on the Kolab side.

For Horde 4 p@rdus is pushing the use of PEAR with a specialized "component helper". The idea is to facilitate the handling of many small Horde components - each a PEAR package.

The tool currently allows automatic updates to Horde component manifests. It packages development snapshots. Builds continuous integration configuration for a component. It creates packaging specs for a distribution - and lists package dependencies.

Last but not least: It install components. And it does that primarily based on the code repository.

This is an essential feature for the continuous integration setup as all testing of the newest code will happen based on installed components. As a result the packaging will automatically be part of the quality control. Both the developers as well as the packagers will benefit from that.

Once the complete components setup is in place it will be very easy to derive a set of packages from it. Whether these packages are targeted for OpenPKG (Kolab Server 2.2.4 or 2.3) or some later native packaging will not really matter. p@rdus is of course actively working on such packaging and you can watch for commits on the horde4 branch of the Kolab server mercurial repository.

PHP Hudson tools

A while ago p@rdus published an easy to use toolset for PHP quality control purposes. Many PHP software tools left the good old hacky script era of PHP some years ago and nowadays quality control becomes increasingly important.

The toolset is primarily intended to provide a basis for the continuous integration setup of the upcoming Horde4 release. It helps to enforce commercial grade quality guidelines for the Horde4 code base and allows to publish this to the outside.

Since the Kolab Server bases a large part of it's functionality on PHP packages it is obvious that the toolset is likely to also play its role in the quality control of the server.

As the name implies the toolset is primarily oriented towards providing the standard PHP QA toolset for the Continuous Integration server Hudson.

The content of the package is a collection of PEAR based packages and an ant script for automated installation. Thus you can basically use the resulting toolset for any other purpose in the field of PHP QA, too.

The included software in detail:

• PHPUnit
• PHP Depend
• PHP Documentor
• PEAR CodeSniffer
• PHP Mess Detector
• PHP Copy Paste Detector
• PHP Code Browser
• Horde Components

The toolset hopefully helps to get you up and running with PHP QA in no time.

Kolab2GentooPrefix

Last time I experimented with Gentoo-Prefix is about half a year ago. I don't know what type of problems I had back then but I remember I did not get far enough. Now - as I'm finally having a tiny bit of spare time for Kolab/Horde again - I did actually get it to compile and run. Nothing more than the base install. But I didn't see anything that would prevent me from trying to get a Kolab server running in such a prefix.

Combine that with the fact that the Kolab server is currently searching for a replacement for OpenPKG... ah, a tiny tiny little wee bit of hope. I don't think it will work out as I would like it to but at least I'm trying.

I believe the Kolab crowd will prefer a native installation method as their next primary platform. But OpenPKG had some significant advantages - even though nobody liked the distribution itself.

It can be installed on many distributions.

It only needs to be tested once and will have this tested stability independent of the distribution it is installed on.

It is a self contained system and the admins know they should keep changes in there to a minimum if they don't want to risk breaking the server.

Gentoo Prefix would allow us to retain these advantages. Ah, back to playing around...

Connecting to the net via a bluetooh mobile...

... using the command line on Ubuntu. These are just the core bluetooth commands and the hint does not deal with specific mobile devices or the settings for your specific provider. It is basically a reminder for myself. First you need to identify the bluetooth address and the channel using sdptool:

sdptool search DUN
Inquiring ...

Searching for DUN on 00:23:F1:21:63:0F ...
Service Name: Dial-up Networking
Service RecHandle: 0x2008003
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0101

The modem device can now be added with rfcomm:

sudo rfcomm connect DUN 00:23:F1:21:63:0F 1
Connected /dev/rfcomm0 to 00:23:F1:21:63:0F on channel 1
Press CTRL-C for hangup

The tool reports that the modem device can now be used at /dev/rfcomm0. This can now be set in /etc/wvdial.conf to connect to the provider.