[Kolab-devel] Debian Packages for Kolab
Paul Boddie <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kolab |
|---|---|
| Message-ID | <201310241420.58455.paul__35503.0248560526$1382616646$gmane$org@boddie.org.uk> |
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