Community News: On The Way to Beta
Last week Kolab 3.0 alpha1 was released. Finally feature-complete, Kolab 3.0 will largely only stabilize further from this point on forward. From the length of this news update you can see that we have been everything but lazy the past week. We've helped plenty of people on the mailing list and on IRC to get the brand new Kolab installed and heard many success stories and happy users.
There's many things still left on our TODO list, including providing all the necessary documentation to upgrade existing Kolab deployments to Kolab 3.0. While testing these upgrades now, we find issues with the tool chain we provide that will need to be resolved before we can publish the documentation on docs.kolab.org. We appreciate help in testing real-life upgrade scenarios! I myself, for one, have so far used a real-life test corpus.
Documentation (General and Upgrade Paths)
There's a lot of work in documentation, which is easy enough to contribute to when considering most of the information on the Kolab wiki is outdated for native packaging, though some information is still very relevant (such as the Fighting Spam article, that has been included in the Administrator Guide). We have 4 different upgrade scenarios to document:
- Upgrade from an OpenPKG installation (Kolab 2.2 or 2.3),
- Upgrade from a Kolab 2.4 installation (with native packages),
- Upgrading Cyrus IMAP from 2.3 to 2.4 (third-party product integration),
- Upgrading the format from Kolab v2 to the new Kolab v3.
While I myself am working on 1) in combination with 4), I learn a couple of things about 2) and 3) as well, but I'm merely migrating data over and upgrading the format. Given the lessons learned, it will take us a little while longer than we expected, to come up with a properly documented upgrade path that is likely to work for most of you. For those of you interested in working on the upgrade path(s), please see the documentation GIT repository where the texts are being developed and maintained (see the Upgrading_*.xml files).
Preliminary documentation for 1) upgrading from an OpenPKG installation (Kolab 2.2 or 2.3) is now available. Please help us test this procedure as well.
Most of the Kolab components these days allow their texts to be localized, including the Kolab daemon, SMTP Access Policy, command-line tools, and the Web Administration Panel and API. We are aware our strongest userbase is in Europe, and we all know many different languages are spoken in Europe.
We have created the opportunity to easily translate Kolab at the localisation platform Transifex. Please check it out and translate a few strings. Every word helps! ;)
We have many users interested in Debian and/or Ubuntu packages, but we do not have the packagers to do the packaging. So far, I've only managed to get Kolab 2.4 on Squeeze to a state in which it is missing only the Roundcube packages, after which we can start testing how well "setup-kolab" behaves and deal with the fallout. Naturally, work is needed for Kolab 3.0, and for Wheezy, Sid and Ubuntu platform versions.
Become a Kolab Community champion by providing the many users with the few packages. Please simply write to the Kolab development mailing list (kolab-devel at kolab dot org).
We have released pykolab-0.5.3, a bug-fix release containing small enhancements as well. This release is available from the usual location and is available for native package deployments as an update in the kolab 3.0 development repository.
The most important changes since 0.5.2 are:
- A new configuration section in /etc/kolab/kolab.conf is available: [kolab_hosting]
This section contains setting related to Hosted Kolab deployments, for which more work and more documentation is still pending.
- Added a command to list mailbox ACLs. Usage:
$ kolab list-mailbox-acls <mailbox-pattern>
$ kolab lam <mailbox-pattern>
- Added a command to set mailbox ACLs. Usage:
$ kolab set-mailbox-acl <mailbox-pattern> <subject> <rights>
$ kolab sam <mailbox-pattern> <subject> <rights>
$ kolab set-mailbox-acl firstname.lastname@example.org email@example.com lrs
$ kolab set-mailbox-acl firstname.lastname@example.org email@example.com lrs
- Added a command to delete mailbox ACL entries. Usage:
$ kolab delete-mailbox-acl <mailbox-patter> <subject>
$ kolab dam <mailbox-pattern> <subject>
- Added a new command list-mailbox-metadata. Usage:
$ kolab list-mailbox-metadata <mailbox-pattern>
$ kolab list-mailbox-metadata user/john.doe/Calendar@example.org
- Added a new command set-mailbox-metadata. Usage:
$ kolab set-mailbox-metadata <mailbox-pattern> <metadata-key> <metadata-value>
$ kolab set-mailbox-metadata user/john.doe/Calendar@example.org /shared/vendor/kolab/folder-type "event.default"
- Added a new command rename-mailbox. Usage:
$ kolab rename-mailbox <old-mailbox> <new-mailbox>
$ kolab rename-mailbox firstname.lastname@example.org email@example.com
This is a bug-fix and enhancement release, as up and until today we've included only development snapshots in Kolab 3.0 (alpha1). This release can be downloaded from the usual location.
The most important changes are:
- The domain name space selection box displayed on login has been removed again.
This was a temporary work-around for multi-domain deployments, that allowed a user to log in to one of the domains available. We have now settled on a convention in which specifying @domain as part of the login username will attempt to log the user in to that domain, and if no domain is specified, a login attempt against the primary domain will be attempted.
Users will basically log in with their uid@domain, or full mail or alias email addresses, if they are not in the primary domain.
- The log system is overhauled, and now allows for trace, debug, info, warning and error messages to be logged separately, and without code modification - whereas previously, to get trace information, all console() calls needed to be uncommented.
This introduces a new setting available in the [kolab_wap] section of /etc/kolab/kolab.conf, named "debug_mode". Set this to a string of either trace, debug, info, warning or error (with the default being "error").
- A preliminary interface for registration with Hosted Kolab deployments is included. Manual intervention is required to fully deploy and enable this interface, including a database schema update, for which testing and documentation is pending.
This is a simple bug-fix release. There's a list of fixed bugs available in our issue tracker.
We've released version 0.8.1 of libkolabxml, with a couple of bug-fixes, primarily in relation to exception handling and encoding problems we've experienced. The download is available at the usual location.
We've released version 0.3.1 of libkolab - another bugfix release with fixes primarily related to PHP bindings (naming and location), encoding handling, and the format upgrade for Kolab 3.0. You can find this release for download at the usual location.
We've released kolab-utils version 3.0.2 - a bugfix release for Kolab 3.0, hopefully resolving most of the format upgrade issues. You can download this release at the usual location.
While the data is being worked on, this means that for a migration of LDAP data, we, the community at large, would appreciate help. If a migration of LDAP data (from OpenLDAP to 389 Directory Server) isn't desirable, then perhaps a data migration from OpenLDAP on a Kolab OpenPKG deployment to OpenLDAP on native packages is.
I have completed the base integration layer necessary to have the Kolab daemon run against an OpenLDAP server using Syncrepl, during our Sprint in Berlin, which needs testing, bug reports and perhaps even some further development.
We encourage you to log tickets in our issue tracker, whether the issue be big or small. We apply two golden rules (of thumb):
- If something is unexpected, it is a bug.
- If it isn't in Bugzilla, it doesn't exist.
We therefore encourage you to take everything that raises your eyebrow or doesn't quite work the way you expected, and put it in a ticket.