[Kolab-devel] Debian Packages for Kolab

[Paul Boddie]

Hello,

I recently shared some thoughts on the Kolab packages with Torsten Grote and 
Hugo Roy (and also in a blog article), and I thought I should post some of 
them here for further discussion.

First of all, credit is due to Paul Klos for getting the packages into a form 
that allowed me (and others) to try them out. I doubt that I would have been 
so motivated to try Kolab if the software hadn't been available in packaged 
form.

Now, I am no Debian packaging expert, but a few things occurred to me and I'll 
repeat them below to see what others have to say.

The setup-kolab script should be integrated into package post-installation 
and/or be robust enough to be run several times in potentially different ways. 
Consider the scripts provided with PostgreSQL on Debian for doing 
administration, for example: https://wiki.debian.org/PostgreSql

In other words, setup-kolab shouldn't be a "one shot" program which doesn't 
like being run again, or where it isn't clear what it does if it is run again. 
Although an all-in-one approach to setting stuff up can be beneficial, I think 
it needs to be complemented by approaches that allow people to keep their 
existing configuration. Maybe setup-kolab does this, but I didn't get this 
impression. (I also wonder if a choice of sensible defaults might reduce the 
need for setup-kolab, but I accept that various policy matters have to be 
specified somewhere, and so setup-kolab may not be completely redundant.)

The authentication aspects of Kolab might be better supported using things 
other than passwords where appropriate. I imagine that this can be tricky for 
the Web applications, but for server-side tasks where the administrator has 
root already (and can therefore read and write various configuration files), 
having key-based logins (or even trust-based logins) might be cleaner than 
having passwords in configuration files. Looking at Debian packages with 
similar application architectures might be informative.

On this front, I aim to look a bit more at the other groupware systems 
provided by Debian [*] such as Citadel, SOGo and OpenChange. Other kinds of 
systems are also relevant here because managing credentials is a widespread 
problem. Suggestions are appreciated!

[*] https://wiki.debian.org/Groupware

It's a bit unfortunate that Kolab prefers 389 to other LDAP servers and has 
preferences for other things that effectively make those things unsupported. I 
imagine it could take a lot of work to support everything that could 
potentially support Kolab, but having seen issues with Exim and Postfix, it 
might be nice to allow existing choices to be respected (and also not require 
people to start from scratch). There shouldn't be any reason why installing 
Kolab wouldn't be adding the "icing to the cake" provided by already-installed 
mail, IMAP and LDAP infrastructure, in other words adding the extra facilities 
of Kolab, even if one might insist that only new "instances" (of mailboxes, 
databases and so on) or migrated ones would be usable by Kolab.

Again, the other groupware packages may support choices of dependencies, and 
it will be interesting to see how they manage this. For example, the citadel-
server package configuration mentions the following:

Suggests: postfix | exim4 | citadel-mta | mail-transport-agent

Of course, actually supporting multiple dependency options may require more 
work because it's unlikely that all these things work in the same way and will 
thus need explicit support in Kolab.

Finally, I wonder whether targeting "sid" (unstable) rather than "wheezy" 
(stable) isn't best for packaging work given that the Debian packaging 
community usually prefers this, and also things like the 389 packages are 
already in "sid" but must presumably be backported to "wheezy" to provide 
Kolab packages. Naturally, backported packages can be made available as a 
consequence of the main packaging effort.

Any comments on the above?

Paul