Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

How Kolab is using Open Standards for Interoperability

Today is Document Freedom Day which started out for documents in the OOXML days, but now is much more generally about Open Standards. This is a great opportunity to show you how Kolab uses Open Standards all the way down to the storage layer.

Since Kolab is a lot about email, it uses SMTP (RFC 821) and IMAP (RFC 1730) to send and store emails which is by itself not overly exciting since at least in the free world, most email software does that. But Kolab goes further and uses IMAP as a NoSQL storage engine and therefore gets all the scalability, ACLs and sharing from IMAP for free. It uses the IMAP METADATA Extension (RFC 5464) to storage other content and even configuration in IMAP folders. Since Kolab is a Groupware Solution, it stores contacts, events and tasks in there. Of course, it does so using Open Standards as well. Contacts are stored in the xCard (RFC 6351) format and tasks as well as events are stored in the xCal (RFC 6321) format. All those objects are then encapsulated in a MIME message according to RFC 2822.

The advantage of that is that your personal data is not scattered all over the place, but in one central IMAP database which you can easily back up (e.g. with offlineimap) or move to another server (e.g. with imapsync). The new version of Kolab supports file storage and the default is to store them in IMAP as well.

Unfortunately, not every IMAP client understands the METADATA extension and displays the other data as you would like. Therefore, Kolab offers other protocols to access that data. For your calendars, Kolab uses CalDAV (RFC 4791). Address book with contacts can be synchronized using CardDAV (RFC 6352) and files are available via WebDAV (RFC 2518).

For a proper groupware it is important that you can invite people to events or assign them tasks even if those people are using other systems on other servers. To achieve this, Kolab uses iTIP (RFC 5546) invitations and sometimes has to implement workarounds, because other clients are not respecting the standard fully. Unfortunately, this is a problem Kolab faces with all standards that are for inter-operating with other software.

To make sure all those different standards interact well together in one system and to be able to further enhance the functionality, the Kolab community uses a defined KEP process. KEP is short for Kolab Enhancement Proposal and works similar to Python’s PEP or XMPP’s XEP.

Happy Document Freedom Day! :)

Using External Email Addresses with Kolab

By default, Kolab does not allow you do send mails from external email addresses that are not hosted by Kolab itself. However, it is quite easy to change this.

In /etc/kolab/kolab.conf find the section [kolab_smtp_access_policy] and add mailalternateaddress to the address_search_attrs. Now you just have to enter all external addresses a user should be able to use to the External Addresses field in the Kolab Web Admin.

If you also want to allow users to choose external addresses for identities in the Kolab Webclient, you have to edit /etc/roundcubemail/kolab_auth.inc.php and find the $config['kolab_auth_addressbook'] array. In it, there is a fieldmap where you add

'email:external'    => 'mailalternateaddress',

to it. That’s all! Now your users should also see their external email addresses in the drop down list when editing their identities in Roundcube.

Should setting up your own Kolab server be too much of a hassle for you, you can also get an account from MyKolab and support Kolab’s development this way.

First F-Droid Workshop to Happen Soon in Berlin

If you always wanted to learn how to include new apps into the F-Droid Free Software app repository for Android, then the first F-Droid Workshop is for you. There the F-Droid developers themselves will show you how to do it.

When? Saturday the 3rd of August, 2PM – 5PM
Where? IN-Berlin (OSM)
Who? Daniel Martí and Torsten Grote (F-Droid developer)

F-Droid is a project that aims to provide Free Software applications for Android via a repository system, much like most of the GNU/Linux distributions distribute packages. This differs very much from the Google Play approach since the client and server side software are respect your freedoms and don’t force you to use a Google account to use them.

The workshop is aimed at developers and advanced users – if you know how to use the terminal on a GNU/Linux machine you’re probably good to go. The only requirements for the workshop are basic technical skills, including basic knowledge of the shell and the Git VCS.

The event will be split into two parts: First, there will be a presentation explaining the basics about F-Droid and how it works. After that, we’ll head on to the hands-on workshop, where everyone will be welcome to include new apps, update existing ones, improve the client and more!

Apart from your Android device, you should also bring a laptop if you have one. It will be easier to participate in the workshop if you have your own computer.

For more information, please see the wiki page containing all the information regarding the activities and other details.

Meine Einschätzung der NSA Mitarbeit an Android für ZEIT ONLINE

Gestern Abend erhielt ich eine E-Mail von einem ZEIT ONLINE Redakteur, der mich um eine Einschätzung zu der Mitarbeit der NSA an Android bat und fragte, ob es möglich sei, dass die NSA Hintertürchen eingebaut habe. Der Artikel dazu wurde mittlerweile veröffentlicht und zitiert mich teilweise. Aus Transparenzgründen und zur Steigerung der allgemeinen Medienkompetenz, gebe ich hier mal meine vollständige hastig zusammen getippte Einschätzung wieder:

Prinzipiell ist es natürlich möglich, dass die NSA Hintertüren in den Code von Android eingebaut hat. Vor einiger Zeit gab es ja den Fall, dass das FBI Hintertüren in den OpenBSD Code eingebaut haben sollte. Gerade bei sehr komplexem Code, kann es schon mal passieren, dass dies einige Zeit unentdeckt bleibt.

Allerdings reicht allein der Verdacht, und Tausende von Entwicklerinnen nehmen den betreffenden Code ganz genau unter die Lupe. Bei moderner Software-Entwicklung sorgen Versionskontrollsysteme zudem dafür, dass jede noch so winzige Veränderung in alle Ewigkeit nachvollzogen und einer Autorin zugeordnet werden kann..

Wir wissen nicht, ob die NSA auch an iOS gearbeitet hat und selbst wenn wir es wüssten, bliebe uns nichts anderes übrig der NSA zu vertrauen (haha!) bzw. zu hoffen, dass keine Hintertüren enthalten sind. Denn niemand kann sich den Code von iOS anschauen, da es keine Freie Software ist. Auch der Aussage, das Apple keine Regierungen an den Code müssen wir deshalb blind vertrauen.

Die Behauptung von Mark Milian, dass Freie Software generell schlecht für die Sicherheit ist, ist jedenfalls großer Quatsch.

Ein Detail, was oft übersehen wird ist, dass fast alle Android-Geräte mit unfreien Versionen von Android ausgeliefert werden. Sie enthalten viele unfreie Komponenten, deren Sicherheit niemand überprüfen kann.

Deswegen ist es wichtig, dass es Initiativen wie Replicant oder CyanogenMod gibt, die verbesserte Versionen von Android anbieten, die man sich dann auf sein Gerät laden kann. Nur so kann man sicher sein, dass auch Freie Software auf dem Gerät läuft und wenn man ganz sicher sein will, kann man sich sein Android sogar selbst aus dem Quellcode bauen.

In der bisherigen Berichterstattung wird ja auch darauf hingewiesen, dass die NSA die Sicherheit von Android verbessern wolle und gerade Android ausgewählt hat, weil es sich dabei um Freie Software handelt, also veränderbar und einsehbar ist.

Wie sie vielleicht wissen, ist ein neues “Merkel-Phone” in Entwicklung, dass auch gerade deshalb auf Android basieren soll. Hier ist man nicht auf das Vertrauen in einen Hersteller angewiesen, sondern hat alles selbst in der Hand. Vertrauen ist gut, Kontrolle ist besser.

CyanogenMod removes tracking opt-out, reverses decision, but still uses Google Analytics

The most successful and best managed version of Android CyanogenMod is gathering data from users for statistical purposes. The statistics are public and users have the chance to opt-out of being counted. On March 31st this changed. The founder of the CyanogenMod initiative Steve Kondik removed the opt-out feature from the source code (commit). He explained his reasons in the commit message:

Not having an accurate count of how many people are using CM is painful. I am making an executive decision to remove the opt-out and always turn stats on. The data is anonymized and there is nothing evil that can be done with it. The only purpose here is to tell us if we are a successful project or not.

Only a few minutes later, another CyanogenMod developer Koushik Dutta added an additional tracking feature (commit) which sends data not only to the servers of CyanogenMod, but directly to Google using Google Analytics.

After many users complained and IT media picked up the story, Steve Kondik reversed his decision (commit) today (3 days later) and says:

Apparently this is a bigger issue for a small number of extremely vocal users. We should respect their wishes, no matter how off-base their claims are in this context.

That does not sound like he understood the legitimate issues people have. He considers them “off-base”, but decided to still respect their wishes.

In a later post, he explains himself in more detail, but still seems to be upset:

It’s incredibly frustrating that a handful of incredibly vocal users are ready to “fork” over the issue. News flash: there are already a hundred forks of CM. We like it, and we enable it! And there’s no sinister plot to crack the hashed data and sell your deepest darkest secrets to Verizon and the NSA.

He does not seem to understand that this is all about trust. Many people do not trust Google with their data and CyanogenMod is their only (reasonable) choice. If they start to collect data as well without letting users know and without a way to at least opt-out, they can not be trusted anymore. The best way to protect data, is not to create it in the first place.

It is too bad that CyanogenMod can not have reliable statistics about its usage, but if users decide to opt out from being tracked for statistics, they have their reasons for it. These people and their reasons should be respected. Their privacy is more important than having more accurate statistics. Thankfully, Steve also seems to realize this:

In the end though, we should respect everyone’s wishes here. The change was well-intentioned- we just want to have better answers to certain questions. There are many applications out there who are doing incredibly dubious things like uploading all of your contacts without your consent, so certain suspicions are understandable. I do not want CM to ever be perceived as a group who doesn’t respect the privacy of it’s users.

You could think that in the end everything turned out to be good. Unfortunately, this is not really the case, because the addition of Google Analytics was never removed. It is still in there (source code) and when you decide to contribute to the statistics with your data, it will also be send to Google. It gets your device name, the device version, your country and your current IP address. CyanogenMod does not even tell you about what data they send to whom.

In my opinion, CyanogenMod should remove Google Analytics completely. What’s the point of having a Google-free operating system that still sends data to Google?

Android SDK is now proprietary, Replicant to the rescue

I just noticed that the Android SDK is now non-free software. If you go to

https://developer.android.com/sdk/index.html#download

and click on one of the files, you are presented with lengthy “Terms and Conditions” which for example say:

In order to use the SDK, you must first agree to this License Agreement. You may not use the SDK if you do not accept this License Agreement.

This sentence alone already violates freedom 0, the freedom to use the program for any purpose without restrictions.

Today, the truly Free Software version of Android called Replicant came to the rescue and released a free (as in free speech) version of the SDK.

Apparently, Google made this step to prevent fragmentation of the ecosystem. What are they going to do next? This situation is far from perfect for software freedom. Developing Android Apps in freedom is only possible as soon as the Replicant developers catch up. Looks like Android stops being a Free Software friendly platform.

So let’s all help that this trend is stopped and Android remains Free. Signing up on the android discussion list is a good first step to asses the situation and plan further action.

Update: It has been pointed out by some people that the SDK Terms and Conditions are older than previously assumed. Google only requires explicit agreement now and shows the terms before download. That wasn’t the case earlier.

Update2: Replicant developer Paul Kocialkowski wrote a blog post as well and explained in more detail what the problem with the SDK is.

Compiling KDE Kontact from Source

My new KOrganizer showing my old appointments.

I’m running Debian Sid, because I like to have a rolling distribution with the latest and greatest software as soon as it is released. Unfortunately, the KDE packagers in Debian lack (wo)men power and still ship 4 year old KDE PIM packages. Using their experimental KDE repository does not help.

Since I have multiple annoying issues with Kontact 4.4.11 and because I need it functional for work, I decided to take a rather extreme step: Compiling it myself from the source code repositories. Turns out that it isn’t all that difficult. I documented the process below for those who want to follow my example. It enables me to stay up to date with the development whenever I want and I receive bug fixes immediately after they have been pushed without having to wait for them to be packaged for my distribution. Also, in case I want something to be fixed that still isn’t in latest master, I can just do it myself now.

In order to get started I read KDE techbase which is quite a good resource even though it could still be improved. At first I had to add the following to my ~/.gitconfig file.

[url "git://anongit.kde.org/"]
        insteadOf = kde:
[url "git@git.kde.org:"]
        pushInsteadOf = kde:

Then I could start cloning the git repositories:

$ git clone git://anongit.kde.org/akonadi
$ git clone git://anongit.kde.org/kdepim
$ git clone git://anongit.kde.org/kdepimlibs.git
$ git clone git://anongit.kde.org/nepomuk-core
$ git clone git://anongit.kde.org/nepomuk-widgets
$ git clone git://anongit.kde.org/soprano.git
$ git clone git://anongit.kde.org/strigi
$ git clone git://anongit.kde.org/kdelibs

At first I tried to just clone kdepim, but I needed the others as dependencies. The Strigi repository uses git submodules, so I had to do the following:

$ cd strigi
$ bash change_to_development_git.sh

While I was trying to make everything compile without error, I needed to install the following packages. Please note that on your system you might need additional packages like build-essentials which I already had installed. Finding out which package is missing is quite easy from the cmake output.

$ sudo apt-get install libgrantlee-dev libsasl2-dev libprison-dev libical-dev libakonadi-dev libgpgme11-dev kdelibs5-dev libqtwebkit-dev libqt4-opengl-dev libiodbc2-dev libraptor2-dev librasqal3-dev librdf0-dev libbz2-dev libdbus-1-dev libfam-dev libclucene-dev libclucene-core1 libboost-all-dev libqjson-dev

The techbase told me to have some environment variables set, so I added this to my ~/.bashrc file.

# KDE
export KDEDIR="/usr"
export KDEDIRS="$KDEDIR:/opt/kde"
export XDG_DATA_DIRS="$XDG_DATA_DIRS:/opt/kde/share:/usr/share"

Then I sourced the file, to have the changes right away.

$ source ~/.bashrc

Of course I created /opt/kde and gave my user the necessary rights to write into this directory. Then for each repository I cloned before, I changed into the directory of the repository and executed the following commands.

$ mkdir build
$ cd build
$ cmake .. -DCMAKE_INSTALL_PREFIX=/opt/kde -DPOLICY_FILES_INSTALL_DIR=/opt/kde/share -DXDG_MIME_INSTALL_DIR=/opt/kde/share
$ make -j 3
$ make install

In rare cases I got an error which I fixed by either installing a missing package or by editing some file. For example, in strigi/strigidaemon/bin/daemon/eventlistener/eventlistenerqueue.cpp I had to add #include <unistd.h> in the beginning for it to build.

Once everything was build and installed, I removed my KDE PIM applications from Debian to be sure there are no conflicts. I couldn’t remove akonadi or some libraries because of dependencies.

$ sudo apt-get remove kontact kmail korganizer kaddressbook akregator

In the #kontact IRC channel I was told to execute the following command which allowed me to have access to the settings in the newly build applications.

$ kbuildsycoca4 --noincremental

The development version of KMail

After this is done, I would suggest a restart to be sure that no old libraries are loaded or old Akonadi is running.

Then you can start your new KDE PIM applications and enjoy them. I’m really impressed by the progress done over the last few years and especially enjoy IMAP idle for Inbox folders and the ability to run all PIM applications independent from each other. Kontact really is a professional full-fledged groupware client.

Have fun with your brand new PIM applications and consider contributing if you find the time!

Update: I added some information here and there and resolved some problems in the instructions. And here is the script that I currently use to upgrade my KDE PIM installation form source:

#!/bin/bash

DIR=`pwd`
PROGS=( kdelibs soprano strigi nepomuk-core nepomuk-widgets libkolab libkolabxml kde-runtime akonadi kdepimlibs kdepim-runtime kdepim )

for D in "${PROGS[@]}"
do
        beep -f 200 -l 100
        echo
        echo "Compiling $D"
        echo
        sleep 5

        cd $DIR/$D
        git pull --rebase
        cd $DIR/$D/build
        cmake .. -DCMAKE_INSTALL_PREFIX=/opt/kde -DPOLICY_FILES_INSTALL_DIR=/opt/kde/share -DXDG_MIME_INSTALL_DIR=/opt/kde/share || break
        make -j3 install || break
done

beep -f 300.7 -r 3 -d 100 -l 400

Paying for Free Software

I would like to be able to pay for more Free Software. Usually people think the great thing about Free Software is that it is free as in free beer. They often neglect the fact that it is free as in free speech. This is probably because they rarely or never make use of this freedom. But since many freedoms benefit us only indirectly, it is still worth fighting for them. I don’t publish a newspaper, still I and society as a whole benefit clearly from having freedom of press.

Software freedom is important to me and I refuse to pay for software that doesn’t respect my freedom. That’s why I use the money I save to reward software developers who don’t want to control how I use my computer by allowing everybody to use, study, share and improve the software they publish.

Recently, I am contributing a lot to FSFE’s Free Your Android campaign. The free App Store F-Droid does not support paying for software because it does not want to track users. Instead they offer the option to donate to the developers of the apps through channels offered by the developers themselves.

Twidere is a great micro-blogging app that also supports StatusNet. Its developer (@mariotaku) has only an old computer that is barely capable of running the software needed for development. That’s why I decided to donate $25 to him. If you like, you can donate money to him, too.

First Experiences Installing the New Kolab 3.0

The Kolab Groupware Solution lets you synchronize your contacts and calenders over multiple devices and easily share them selectively with other users. It is a 100% Free Software and historically close to the KDE community, but you can also use it with a multitude of different clients such as Thunderbird. Ever since the first alpha version of the brand new Kolab 3.0 Groupware Solution was released, I wanted to give it a try. The new features and especially the freshly skinned webclient based on Roundcube got me excited. I’m still running an old Kolab 2.2 server on Debian for personal use and hope to be able to switch to 3.0 as soon as Debian packages are ready. So far the best system to run Kolab on is CentOS, because native packages exist. Even though I have virtually no experience with CentOS, I tried a test install in a virtual machine. Read on for my experiences.

Installing CentOS in VirtualBox

Being an advanced user, I started to follow the quick howto from kolab.org. So at first I had to download an ISO image of CentOS from a mirror. I decided to use VirtualBox because it has a nice GUI and is fairly easy to setup. Then I created a new VM called “Kolab Server” with Redhat GNU/Linux 64bit as an operating system because that was closest to CentOS. Afterward, I hooked in the ISO image as a virtual CD drive and booted the VM.

VirtualBox

It booted right into a graphical GNOME environment showing me a button to install CentOS to the hard drive. Pressing that button a couple of times didn’t produce any result, so I figured out what the button was actually starting and ran that command from the terminal. There I was told that there wasn’t enough RAM available to execute the graphical installer. Thankfully the terminal installer was started right away for me and I could get going.VirtualBoxLiveCD

The install was quite easy. Just a few questions here and there. I decided to disable the firewall completely to not run into any trouble with that later. As soon as the installation was complete I didn’t want to work with the cumbersome VM window anymore and was looking into ways to access the VM with ssh. Turned out, I just had to configure Port Forwarding for the VM. So in VM Settings I selected “Attached to: NAT” in the “Network” tab. In “Advanced” I configured “Port Forwarding” as follows:

Name     | Protocol | Host IP | Host Port | Guest IP | Guest Port
guestssh | TCP      |         | 2222      |          | 22

This allowed me to login with ssh from the host machine using

ssh -p 2222 root@localhost

Installing and Setting Up Kolab

Then I continued to follow the quick installation howto. Since the URL of the release package changed since the howto was written, I had to look up the proper URL by clicking on the provided link. The installation of Kolab itself took some time, but it went through without errors. Starting setup-kolab resulted in the following warning:

WARNING: The Fully Qualified Domain Name or FQDN for this system is incorrect. Falling back to 'localdomain'.

Since I had already heard about problems with incorrect domain names, I decided to take the warning seriously and abort the setup by pressing Ctrl+C. To get some more advanced help on the issue I moved over to docs.kolab.org for the extensive installation guide. It told me that the setup “requires that the Fully Qualified Domain Name (FQDN) for the system resolves back to the system”. So in /etc/sysconfig/network I added HOSTNAME=kolab.example.org and in /etc/hosts I added 10.0.2.15 kolab.example.org since 10.0.2.15 was the IP address of the VM. Apparently, it is important not to use 127.0.0.1 here. Then I had to reboot for the hostname change to take effect.

After the VM came back up, I logged into ssh and ran again:

# setup-kolab

This time, it started without warnings and asked me to provide many many passwords. You can see that Kolab still takes security seriously. I’ll post the output of setup-kolab below.

Please supply a password for the LDAP administrator user 'admin', used to login
to the graphical console of 389 Directory server.

Administrator password [ZqtSz8nIQI6f4hR]: 

Please supply a password for the LDAP Directory Manager user, which is the
administrator user you will be using to at least initially log in to the Web
Admin, and that Kolab uses to perform administrative tasks.

Directory Manager password [KzHd2dVQ2o9JkXr]: 

Please choose the system user and group the service should use to run under.
These should be existing, unprivileged, local system POSIX accounts with no
shell.

User [nobody]:
Group [nobody]: 

This setup procedure plans to set up Kolab Groupware for the following domain
name space. This domain name is obtained from the reverse DNS entry on your
network interface. Please confirm this is the appropriate domain name space.

example.org [Y/n]: n
Domain name to use: kolab.example.org

The standard root dn we composed for you follows. Please confirm this is the root
dn you wish to use.

dc=kolab,dc=example,dc=org [Y/n]: 

Setup is now going to set up the 389 Directory Server. This may take a little
while (during which period there is no output and no progress indication).

Shutting down dirsrv:
    kolab...                                               [  OK  ]
Starting dirsrv:
    kolab...                                               [  OK  ]

Please supply a Cyrus Administrator password. This password is used by Kolab to
execute administrative tasks in Cyrus IMAP. You may also need the password
yourself to troubleshoot Cyrus IMAP and/or perform other administrative tasks
against Cyrus IMAP directly.

Cyrus Administrator password [kplMHHzS_U3QRP2]: 

Please supply a Kolab Service account password. This account is used by various
services such as Postfix, and Roundcube, as anonymous binds to the LDAP server
will not be allowed.

Kolab Service password [IWx-2tE0QoC-VcZ]:
Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]
Shutting down amavisd: The amavisd daemon is apparently not running, no PID file /var/run/amavisd/amavisd.pid
                                                           [FAILED]

Starting amavisd:                                          [  OK  ]

Stopping clamd.amavisd:                                    [FAILED]
Starting clamd.amavisd: LibClamAV Warning: **************************************************
LibClamAV Warning: ***  The virus database is older than 7 days!  ***
LibClamAV Warning: ***   Please update it as soon as possible.    ***
LibClamAV Warning: **************************************************
                                                           [  OK  ]
Stopping wallaced:                                         [FAILED]
Starting wallaced:                                         [  OK  ]
Initializing MySQL database:                               [  OK  ]
Starting mysqld:                                           [  OK  ]

Please supply a root password for MySQL. This password will be the administrative
user for this MySQL server, and it should be kept a secret. After this setup
process has completed, Kolab is going to discard and forget about this password,
but you will need it for administrative tasks in MySQL.

MySQL root password [gOZS47jIzy8HOXy]: 

Please supply a password for the MySQL user 'kolab'. This password will be used
by Kolab services, such as the Web Administration Panel.

MySQL kolab password [gsc5FFDJOgGGsOX]: 

Please supply the timezone PHP should be using.

Timezone ID [UTC]: CEST

Please supply a password for the MySQL user 'roundcube'. This password will be
used by the Roundcube webmail interface.

MySQL roundcube password [j_dvolYPbVVfT8I]:
Stopping httpd:                                            [FAILED]
Starting httpd:                                            [  OK  ]
Shutting down cyrus-imapd:                                 [FAILED]
Starting cyrus-imapd:                                      [  OK  ]
Stopping kolab-saslauthd:                                  [FAILED]
Starting kolab-saslauthd:                                  [  OK  ]
Stopping kolabd:                                           [FAILED]
Starting kolabd:                                           [  OK  ]

At first I was afraid seeing these [FAILED] services, but then I realized that stopping services that haven’t been started yet will of course fail. There’s already an enhancement request for suppressing this and other unnecessary output from the setup script. Feel free to work on this request. It is a simple python script, so that should be an easy exercise.

Trying out Kolab

So now Kolab was installed and setup. Surprised by how smoothly that went I was asking myself “What now?”. So I looked in the documentation which pointed me to first login in the web-based administration panel. Since I had no graphical environment installed on the server, I had to forward ports again, to be able to access it from the host machine.

Name      | Protocol | Host IP | Host Port | Guest IP | Guest Port
guesthttp | TCP      |         | 8080      |          | 80

So now I could go to http://localhost:8080/kolab-webadmin/ and login with cn=Directory Manager and the password KzHd2dVQ2o9JkXr that was supplied during the setup process. The login worked well and I could see the shiny webadmin. I was only surprised to find no way to add users, so I asked in IRC. There I was pointed to the documentation again. Since I used the quick install guide, I completely missed the section “Preparing the System”. There was a paragraph on SELinux that says “Not all components of Kolab Groupware are currently completely compatible with running under SELinux enforcing the targeted policy”. So in /etc/selinux/config I had to change SELINUX=enforcing to SELINUX=permissive. This way SELinux just prints a warning, but doesn’t enforce the policy. I again restarted VM, reloaded the webadmin page and had still no links to add users. It turned out that I just had to terminate the current webadmin session by logging out and in again, and there the link appeared.

Now I created a test user and ran the following to verify that it was created successfully.

# kolab list-mailboxes
user/test.test@kolab.example.org
user/test.test/Archive@kolab.example.org
user/test.test/Calendar@kolab.example.org
user/test.test/Calendar/Personal Calendar@kolab.example.org
user/test.test/Configuration@kolab.example.org
user/test.test/Contacts@kolab.example.org
user/test.test/Contacts/Personal Contacts@kolab.example.org
user/test.test/Drafts@kolab.example.org
user/test.test/Journal@kolab.example.org
user/test.test/Notes@kolab.example.org
user/test.test/Sent@kolab.example.org
user/test.test/Spam@kolab.example.org
user/test.test/Tasks@kolab.example.org
user/test.test/Trash@kolab.example.org

This is how it looked for me. But this screenshot is taken from kolab.org.

Great! It worked. Now I moved on to try the webmailer based on Roundcube by going to http://localhost:8080/roundcubemail. I was quite pleased by what I saw. It looke quite nice, a lot better than the old Roundcube skin and seemed to work flawlessly. Only when I sent a test mail to the test user, I noticed that there was a ServerError when checking for new mails. A look in /var/log/httpd/error_log indicated that I had foolishly specified the wrong timezone during setup. So I had to change it in /etc/php.ini from date.timezone=CEST to date.timezone=Europe/Berlin and restart apache with

# service httpd restart

From now on everything went smoothly and I had a working Kolab server running. Overall I was quite pleased how easy and fast the installation went. Configuration also improved significantly compared to the old Kolab release in Debian. There were a few problems during the installation, but all of them were caused by mistakes on my side and by not starting with the full documentation.

So if you are interested in Kolab, please give it a try and let me know about your experiences!

Updating Custom Versions of Android Easily

FSFE’s Phone Liberation Workshops (or Android Install Parties) are just taking off. People usually have to learn how to flash their devices because there’s no over the air update that easily updates the operating system. The Free Software initiative OTA Update Center is planning to change this. It will notify you of updates and allow you to apply the update with a click. No more manual flashing procedures necessary.

Even though their source code is on github and the app was added to F-Droid, you can still not use it with most ROMs, because the ROM needs to support OTA Update Center with three little lines in a text file. The developers are already in talks with the CyanogenMod developers. But OTA Update Center competes with the proprietary ROM Manager that ships with CyanogenMod.

So let’s see if or when OTA Update Center will be part of CyanogenMod.

Update: Turns out that we could even use OTA Update Center if CyanogenMod doesn’t cooperate. We would need a script or an app that lets you add the necessary values to /system/build.prop and we would need somebody who maintains the database at OTA Update Center for all CyanogenMod ROMs and devices.

Of course it is preferable that CyanogenMod adds native support for OTA Update Center. That’s why I supported an existing enhancement request in their tracker. Please express your support there, too!

Update2: Starting with CyanogenMod 10, there is now native support for updates built in. So this problem is solved.