From 3b6c0366f95ab699e034819de2bfaccc3c5d571d Mon Sep 17 00:00:00 2001 From: Luca Beltrame Date: Sat, 8 Jun 2019 09:25:58 +0200 Subject: [PATCH] Amend post with some more details --- _posts/2019-06-07-new-server-away-from-kolab.markdown | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_posts/2019-06-07-new-server-away-from-kolab.markdown b/_posts/2019-06-07-new-server-away-from-kolab.markdown index 5b35e0d..44f409b 100644 --- a/_posts/2019-06-07-new-server-away-from-kolab.markdown +++ b/_posts/2019-06-07-new-server-away-from-kolab.markdown @@ -38,11 +38,11 @@ I used to run Kolab Server 3.4, but as time passed I found many barely tolerable Kolab is an incredibly complex piece of software which includes C++ parts (including forks of some libraries developed originally by KDE), a series of daemons, Postfix for SMTP, Cyrus as POP/IMAP server, and Amavis/ClamAV/Spamassassin for spam handling. It offers a user database based on LDAP, and a web interface to administer users and mailboxes. The first problem is exactly this complexity: Kolab is *incredibly* fragile and some configuration changes may break everything with obscure errors. -Also, some of the defaults make sense for Kolab Now, but have little sense for many other users, for example making the primary username the surname (real or fake) of the user. Changing these is not trivial and very poorly documented (read more on this later). Multi domain support, by default, is basically non existent, and to be productive you might want to rely on scripts made by third party contributors to make everything manageable (in this case, again the documentation is unhelpful). Lastly, it doesn't work with SELinux: you have to run everything in permissive mode. +Also, some of the defaults make sense for Kolab Now, but have little sense for many other users, for example making the primary username the surname (real or fake) of the user. Changing these is not trivial and very poorly documented (read more on this later). Multi domain support, by default, is basically non existent, and to be productive you might want to rely on [scripts made by third party contributors](https://github.com/TBits/KolabScripts) to make everything manageable (in this case, again the documentation is unhelpful). Lastly, it doesn't work with SELinux: you have to run everything in permissive mode. -And here also comes the software problem. Kolab has PHP bindings for its C++ libraries, which are tied to the PHP version in the distro. So you can't really use PHP from another repository without risking breaking anything (I know on CentOS you can USE SCLs, but this means an additional setup cost). You can't run Kolab in LXC, nor in Docker. I had to resort to *very* ugly hacks to run other software that required at least PHP 7. +And here also comes the software problem. Kolab has PHP bindings for its C++ libraries, which are tied to the PHP version in the distro. So you can't really use PHP from another repository without risking breaking anything (I know on CentOS you can use SCLs, but this means an additional setup cost). You can't run Kolab in LXC, nor in Docker. I had to resort to *very* ugly hacks to run other software that required at least PHP 7. -Some advanced features of Kolab are totally not documented: the Chwala file sharing component, for example, can tie to the [Seafile web file sharing application](https://seafile.com), but it was not documented *anywhere* and the configuration options were hidden in mailing list threads. It took a lot of digging to get all of this in shape and [contribute as a HOWTO](https://docs.kolab.org/howtos/use-seafile-with-chwala.html). +Documentation is a sore point of Kolab in general: painfully incomplete, sometimes hard to read, or woefully out of date. A perfect opportunity for someone from outside. to fix it... if how the whole thing worked was actually understandable. Some advanced features of Kolab are completely undocumented: the Chwala file sharing component, for example, can tie to the [Seafile web file sharing application](https://seafile.com), but it was not documented *anywhere* and the configuration options were hidden in mailing list threads. It took a lot of digging to get all of this in shape and [contribute as a HOWTO](https://docs.kolab.org/howtos/use-seafile-with-chwala.html). Upgrade paths are complex, unsupported, and require manual migrations of the databases. It is thanks to the efforts of a couple of community members that they were available at all. In addition, some newer versions introduced **major** regressions, like with the new component Guam, which was supposed to act as a proxy in front of Cyrus IMAP and hide the special IMAP folders Kolab uses for calendars, contacts, and even files, which was obviously not ready when Kolab 16 was released (it couldn't even understand SSL). On top of that, there hasn't been a new version since Kolab 16: upstream development moved to "Winterfell", a continuously developed, integrated, and deployed version. Probably very useful for what Kolab Systems does with Kolab Now!: I'm not sure it would benefit others, though. @@ -52,7 +52,7 @@ First and foremost, all bits of Kolab are Free Software and use open standards, In addition, they don't seem to care at all about downstreams. Packaging Kolab for a distribution is an exercise in futility, due to the number of downstream patches, occasional git snapshots, and other very Kolab-specific bits that do not fit well in an integrator's workflow. I don't mind if Kolab Systems don't do that themselves (they need to keep on making money to stay alive), but enabling or facilitating integration downstream would help a lot. -Lastly, contributions. For a project that is this complex, it's not unusual to expect few contributions. Yet, basically every interaction with the community ended up in silence, few communication, and outright failure. On this topic, let's note the [failed Indiegogo campaign for Roundcube Next](https://www.indiegogo.com/projects/roundcube-next--2) (never ever did anything with zero communication), [the almost dead mailing lists](http://lists.kolab.org/pipermail/devel/), and the fact that the [official forums are a spamfest](https://kolab.org/hub/) (and for some time, they weren't even reachable). +Lastly, contributions. For a project that is this complex, it's not unusual to expect few contributions. Yet, basically every interaction with the community ended up in silence, no communication, and outright failure. On this topic, let's note the [failed Indiegogo campaign for Roundcube Next](https://www.indiegogo.com/projects/roundcube-next--2) (never ever did anything with zero communication), [the almost dead mailing lists](http://lists.kolab.org/pipermail/devel/), and the fact that the [official forums are a spamfest](https://kolab.org/hub/) (and for some time, they weren't even reachable). #### The verdict