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/process.py", line 44, in synchronize
auth.synchronize()
File "/usr/lib/python2.7/dist-packages/pykolab/auth/__init__.py", line 243, in synchronize
self._auth.synchronize()
File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 860, in synchronize
callback=self._synchronize_callback,
File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 2151, in _search
secondary_domains
File "", line 10, in
File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 1895, in _persistent_search
secondary_domains=secondary_domains
File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", 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/__init__.py", line 1389, in _change_none_user
self.imap.connect(domain=self.domain)
File "/usr/lib/python2.7/dist-packages/pykolab/imap/__init__.py", line 144, in connect
self._imap[hostname].login(admin_login, admin_password)
File "/usr/lib/python2.7/dist-packages/pykolab/imap/cyrus.py", line 133, in login
cyruslib.CYRUS.login(self, *args, **kw)
File "/usr/lib/python2.7/dist-packages/cyruslib.py", line 416, in login
self.__doexception("LOGIN", error)
File "/usr/lib/python2.7/dist-packages/cyruslib.py", line 359, in __doexception
self.__doraise( function.upper(), msg )
File "/usr/lib/python2.7/dist-packages/cyruslib.py", 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.