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?

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.

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.

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.

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!

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.

But there are also some features I’m missing from CyanogenMod 9. In good Free Software fashion I created feature requests for them in CyanogenMod’s issue tracker. Here’s my list:

Power Control Widget Not Configurable

In CM7 multiple Power Control Widgets could be added to the desktop. Each could be configured individually and have a different number and types of buttons. In CM9 only the Power Control in the drawer can be configured. That helps somewhat but is far less powerful than having any number of custom widgets.

No SSH Daemon (Dropbear)

Having a dropbear daemon running on my phone used to be a great feature, because it allowed my to remotely log into my phone, run scp and rsync. Unfortunately, there’s no dropbear binary on the CM9rc2 image anymore.

Option for Black Background Missing for Contacts and Messages

CM7 had the option to set a black background for the free (as in free speech) contacts, messages and calendar apps. (Note that I’m not talking about the non-free Google Apps here.) This option is gone in CM9 and these apps don’t integrate at all in a phone where all other apps have black background. Plus it consumes more energy.

No More Direct In-App Shortcuts on Desktop

The Desktop from CM7 allowed custom shortcuts to screens within applications. This was a useful feature to for example directly link to the alarm clock.

Native OpenVPN Support is Gone

PPTP and IPSec are still there, but OpenVPN is just gone.

In case you are actually using a Google Account, you can vote for those issues by starring them.

Update: Added missing Dropbear support.