Paul Boddie's Free Software-related blog

Paul's activities and perspectives around Free Software

Kolab and Debian Packaging Pitfalls

Hugo Roy has been trying to install Kolab and not getting on particularly well with it. His experiences persuaded me to take another look at my Kolab installation done back in June, and to my surprise it didn’t seem to work any more. I eventually discovered some things that will probably need fixing in the packaging, and these are mentioned below. I suppose I’ll try and pursue these with the developers and packagers.

The LDAP server (provided by the 389-ds suite of packages, but actually started when the ns-slapd program is run, and known as the dirsrv service – yes, all very confusing stuff) doesn’t want to run until the permissions are fixed on the /var/run/dirsrv and /var/lock/dirsrv directories so that the ns-slapd program can create pid and lock files.

The kolab-saslauthd service won’t be running if the LDAP server isn’t running. (You can check this using service --status-all and seeing what is running and what isn’t.) Some Kolab programs seem to get upset when they can’t connect to the LDAP or IMAP servers, and if the LDAP server is brought up, there’s a frequent, recurring error from a Python program complaining about IMAP server connections failing…

Traceback (most recent call last):
 File "/usr/lib/python2.7/dist-packages/kolabd/", line 44, in synchronize
 File "/usr/lib/python2.7/dist-packages/pykolab/auth/", line 243, in synchronize
 File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/", line 860, in synchronize
 File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/", line 2151, in _search
 File "", line 10, in
 File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/", line 1895, in _persistent_search
 File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/", line 1735, in _synchronize_callback
 eval("self._change_none_%s(entry, change_dict)" % (entry['type']))
 File "", line 1, in
 File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/", line 1389, in _change_none_user
 File "/usr/lib/python2.7/dist-packages/pykolab/imap/", line 144, in connect
 self._imap[hostname].login(admin_login, admin_password)
 File "/usr/lib/python2.7/dist-packages/pykolab/imap/", line 133, in login
 cyruslib.CYRUS.login(self, *args, **kw)
 File "/usr/lib/python2.7/dist-packages/", line 416, in login
 self.__doexception("LOGIN", error)
 File "/usr/lib/python2.7/dist-packages/", line 359, in __doexception
 self.__doraise( function.upper(), msg )
 File "/usr/lib/python2.7/dist-packages/", line 368, in __doraise
 raise CYRUSError( idError[0], mode, msg )
 CYRUSError: (10, 'LOGIN', 'generic failure')

Restarting the kolab-saslauthd service fixes this; maybe restarting the cyrus-imapd service also helps. Restarting the kolab-server service should apparently synchronise the constituent services, but I’m not sure it helps if you get the above Python error. You may also see an LDAP-related error which just appears to be the same program or a related one getting even more upset about the LDAP server.

Also, if you don’t update for a while, the clamav-freshclam service uses a lot of CPU and bandwidth performing updates. Such stuff needs turning off if you value your computer’s interactivity, in my experience.

2 Responses to “Kolab and Debian Packaging Pitfalls”

  1. HarimauX Says:

    So as of 29 Oct 2013, is there any working Kolab setup recipe for Ubuntu 12.04LTS?

    I am now stuck on:

    ldap.INAPPROPRIATE_AUTH: {‘info’: ‘Anonymous access is not allowed.’,
    ‘desc’: ‘Inappropriate authentication’}

    Is there any way to cleanup Kolab and start the setup again?

    By the way, setup-kolab has broken Virtualmin/Webmin Users And Groups management, which I guess is due to LDAP.

    I need to use Webmin as well as Kolab on the same machine.
    Kolab seems to be a great product, which I haven’t managed to install for 7 days and nights.

    Can someone create a working setup script for Ubuntu 12.04LTS and higher?

    I’m close to giving up on Kolab, and I had really high hopes for it.

  2. Paul Boddie Says:

    I don’t think there is a really good way of cleaning up, other than Timotheus’ script ( which I haven’t needed to look at yet, but I’d like to contribute work to prevent situations arising where one might need to clean up. In any case, I hope I can suggest a few things to help you.

    The error looks familiar. What I found was that the LDAP server wouldn’t actually start, but the error suggests that it is started but doesn’t like the credentials (or lack of them) being sent. So, then I’m tempted to think that one of the other services isn’t playing along, perhaps kolab-saslauthd, and so you might want to see if restarting that makes any difference.

    Some other service may start complaining, too, and restarting cyrus-imapd service might prevent this. Generally, I think that everything becomes desynchronised and there’s no panic button to reset everything and make it all happy again. But my most recent problems definitely originated with the LDAP server not starting.

    I’ll try and take a closer look at this tomorrow, but perhaps someone on the Kolab mailing lists or #kolab IRC channel can offer some suggestions.

    Meanwhile, I’ve been trying to do some packaging work, but it feels like I’m doing it the hard way at the moment. That’s another job for tomorrow, I guess. I want Kolab to be more approachable because it seems like a project that people just disregard, and I’d rather that didn’t happen just because the packaging didn’t work.