Kolab.org Groupware Solution

As written in my last blog, Kolab 3 for openSUSE almost ready for production. I set up test server for my company as well as for my private use and they're running - issues I encounterd have been fixed in the mean time. Progress since week 9 I did ... [More] various fixes for kolab-cli and kolab-imap. kolab-scripts has been updated as well and makes installations a lot easier. 389-ds-base got a fix to also start its instances when started. 389-* has been pushed into network:ldap My test systems are up and running, the major features of Kolab 3 all seem to work (I still have to finish some tests) All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST.   Tasks Wiki pages on opensuse.org need proper updates. There are plans to provide support for OpenLDAP - this includes schema, packages and dependencies. There are also new plans to provide support for Dovecot. Tests on my test systems have to be completed (including send/receive mails, tasks, calendars, ActiveSync and everything). If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me. [Less]

Today I’d like to share a success story of a picture perfect project collaboration as it only happens in the open source world without any commercial, political or geographical borders. It all started back in 2009 after a short interview about ... [More] Roundcube was published on a techworld.com blog. Short time after we got an email from Georg Greve, founder of the FSFE and member of the Kolab Groupware project. At that time, Kolab already made its name as a free competitor to Microsoft Exchange and Outlook and they were just about to found a new company to push Kolab to the next level. One thing Kolab definitely needed was a better web client to access all the groupware data from anywhere. And this is where Roundcube seemed to fit in perfectly. Although Roundcube was “just” an email client, the Kolab guys saw great potential in our codebase and the vital community around it. And now, more than three years after, we can all witness the great success of this decision. Lots of lessons learned After some first meetings and discussions about a possible collaboration between Kolab and Roundcube, we agreed on a general interest from both sides. For the newly founded company Kolab Systems who (as opposed to the Roundcube project) directly hits customers with real needs and urgent bugs to be fixed, it was important to get direct and reliable access to Roundcube developers in order to be agile enough to establish professional services around the open source software stack that is Kolab. This is also where we started to learn how to run an open source project in a more professional and sustainable way. They taught us the importance of having release branches with long-term support, a clear road map and well documented changesets. Kolab also helped us to better understand the whole licensing topic and with them getting us some legal consultancy from the FTF we finally made the transition to GPLv3 with the added exceptions for skins and plugins. Escpecially the latter one opened the doors for Roundcube to become more accepted in commercial environments which previously had their concerns about the strict terms of the GPL. Great boost of development But let’s also have a look at the product side of the story. All users of Roundcube have been on the receiving end of technical and other benefits starting from the 0.7 release. To give you some background about myself: When Georg and I were talking for the first time, my day-job left me very little time to work on Roundcube. I hadn’t contributed much code in a while, and was even considering to step back from the project altogether because I fell short of my own expectations. Of course it’s impossible to say what would have happened in an alternate universe, but fact is that Kolab Systems enabled me to get back to work on Roundcube. And because Kolab is fully open source, everything has become available to all who use Roundcube. Here are just some of the features and plugins we added to Roundcube as part of the Kolab integration work: ACL plugin Calendar plugin Tasks plugin Advanced contact search Savable contact search queries Personal spell check dictionaries ODF document viewer plugin Inline PDF viewer plugin And these are only the “visible” additions to our software which have primarily been initiated and forced by Kolab. Lots of improvements on the stability and quality of the underlying codebase, namely the IMAP and LDAP libraries, are referable to reports coming from the Kolab community. The work on the various plugins used to bring full-stack groupware functionality to Roundcube also resulted in several upstream patches to other open source projects such a jQuery UI and the jQuery fullcalendar. And that’s what makes free software development truly awesome! Quality guaranteed Another very positive aspect of the collaboration with a mature OSS project such as Kolab with a competitive company in the background is the quality assurance and testing we get from them. While we get a lot of bug reports from our own community that help stabilizing our code, there’s no real QA process set up for Roundcube, mainly due lack of resources. Because Kolab Systems takes responsibility (and money) for the installations of the Kolab Groupware, they have a strong interest in quality assurance. And with Roundcube now being an important component of their suite, we can just ride on the wave of QA management and processing. The only price we pay is to fix bugs within a reasonable time. And again, the results of this are accessible for everybody who regularly updates their Roundcube installation. On an operative and decision-making level, Kolab Systems and the Kolab project itself strive to be “good citizens” in the open source world the same way as we do. Without having to ask for it, it was made clear that Roundcube would remain its own fully independent and emerging project run by the community. Whenever there is a question of whether a certain feature is in Roundcube’s general interest, whether it should go into Roundcube core, or into the Kolab specific modules, or perhaps even approach differently altogether, that decision is always ours to make with no interference from Kolab. So we kept Roundcube as the lean, focussed web mailer that I believe it should be, and moved all other functions into their separate modules. From the perspective of Roundcube, this has led to improvements on all aspects that matter: adoption, code, quality, community and allowing both Alec and myself to spend lots of time that benefits all users of Roundcube. Summarizing all these facts and stories, this “K”ollaboration finally IS nothing but a success story. Two great open source projects came together to become even greater. [Less]

Today I'll summarize what happend the past two weeks - I was pretty busy and got Kolab 3 for openSUSE almost ready. Still a few things need to be taken care of: full testing is neccessary to ensure everything is working and pre-checks have to be ... [More] implemented. Progress since week 7 libcalendaring is ready for SLE 11 SP2. libkolabxml builds on SLE 11 SP2 (with disabled php and mono bindings). libkolabxml 0.8.3 has been released. server:Kolab:Extras provides cyrus-imapd 2.3.18 with Kolab patches enabled and LDAP support. 389-ds now is build with OpenLDAP instead of mozldap, fixing bugs in 389-admin. perl-Mozilla-LDAP has also been rebuild with OpenLDAP instead of mozldap. An issue with saslauthd has been fixed, preventing users from authentificating. A package called kolab-scripts has been introduced to server:Kolab:UNSTABLE, (in near future) containing scripts to aid Kolab developers. Currently, this package only contains a script called prep-setup-kolab, that updates your system, checks for a valid FQDN and creates a certificate authority and server certificates. I'll try to include some handy scripts from git.kolabsys.com A few bugs in kolab-mta (preparing main.cf) have been fixed. Amavisd has been updated to 2.8.0 and has just been released with openSUSE 12.3-RC2. amavisd.conf.tpl has also been modified to match openSUSE configurations. kolab-syncroton has been updated to 2.1rc1. All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST. Note: Some of the new packages are currently not available in the repositories, as the build hosts are pretty busy with openSUSE 12.3 being released in less than two weeks.   Tasks It's still our wiki pages on opensuse.org - they need to be updated. There are plans to provide support for OpenLDAP - this includes schema, packages and dependencies. There are also new plans to provide support for Dovecot. Now that we're done with cyrus-imapd, it's time to have a look at postfix and verify, that this is working with Kolab on openSUSE. If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me. [Less]

<p>During the last month of running Kolab 3.0 on my Debian server, I tweaked some settings for anti-spam fighting. Here is what I did and what you can do to have your Kolab 3.0 inboxes as spam-free as possible.</p> ... [More] <h1>Greylisting</h1> <p>Stopping spam before it enters the queue is a good thing. One way to achieve this is Greylisting: Reject a triplet (sending host, sender address, recipient address) on the first deliver attempt with a temporary error (<code>450 4.2.0 &lt;[email protected]&gt;: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/tobrunet.ch.html</code>) and save this triplet. On the second delivery attempt check the triplet against the database and if it matches, allow this message to be delivered. This stops many spam senders because they only try it once. A correctly configured MTA tries it again after a few minutes and the mail is delivered.</p> <p>A drawback of this mechanism is that an email which is sent for the first time has a longer delivery time and if you have impatient users, they won&#8217;t like it. It&#8217;s also possible to lose emails if the sending MTA is not correctly configured, but then the sending MTA has probably other problems and could be a spam sender.</p> <h2>Installing and configuring postgrey</h2> <p>Implementing Greylisting on Kolab 3.0 running on Debian is very easy:</p> <ol> <li>Install postgrey: <code>apt-get install postgrey</code></li> <li>Add postgrey policy filter to Postfix by editing <code>main.cf</code> and adding <code>check_policy_service inet:127.0.0.1:10023</code> to <code>smtpd_recipient_restrictions</code> at the end of the list (restart/reload postfix after this change)</li> <li>Check you <code>mail.log</code> if postgrey is acting as expected: <pre>Feb 25 20:31:56 james postgrey[3211]: action=greylist, reason=new, client_name=mtasender.domain.com, client_address=123.52.23.32, [email protected], [email protected]</pre> </li> </ol> <p>A nice Blog post on <a href="http://www.debuntu.org/postfix-and-postgrey-a-proactive-approach-to-spam... explains some parameters which can be tweaked for postgrey</p> <h1>Spamassassin</h1> <p>On a default Debian installation, Spamassassin is not enabled in the Amavis configuration. This is too bad, because Spamassassin can help to stop many spam emails. To enable Spam scanning in Amavis, remove the comment before <code>@bypass_spam_checks_maps</code> in the file <code>/etc/amavis/conf.d/15-content_filter_mode</code> and restart amavis. Spamassassin has to be trained with spam and ham. There is some good documentation about that topic in <a href="http://docs.kolab.org/en-US/Kolab_Groupware/3.0/html/Administrator_Guide... 6. Combating Spam</a> of the official Kolab 3.0 documentation.</p> <h1>Blacklists</h1> <p>RBL blacklists (Real-time Blackhole Lists) helps to block known spamming IP addresses at the SMTP conversation level. All configured Blacklists will be queried (using DNS) to check if the connecting IP of the MTA is listed on the Blacklist. The sending MTA is then blocked with a hard error, f.e. <code>554 5.7.1 Service unavailable; Client host [190.190.76.151] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=190.190.76.151</code></p> <h2>RBL configuration</h2> <p>RBL blacklists are directly integrated into Postfix and are configured in <code>main.cf</code>:</p> <pre>submission_recipient_restrictions = [...] reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, [...]</pre> <p>I&#8217;m using Spamhaus, IX and Spamcop blacklist at the moment, as I&#8217;ve made good experience with them. Wikipedia hosts a comprehensive comparison table of RBLs: <a href="http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists">http://en.wik... <h1>Backup MX</h1> <p>One of the best things I could do in fighting spam was removing the backup MX record from DNS and not use any backup MX anymore.<br /> The reason is the backup MX did not have any spam fighting technologies and did not know anything about the primary MX (available mail addresses, greylisting triplets, &#8230;). This is the case on many backup MX systems and spam sender know that. So they startet to send spam directly to the backup MX which accepts all mails without scanning and delivers it to the primary MX. The primary MX is then accepting mails from a well known good mail server and did not have the possibility to identify spam as good as if they were sent directly to the primary MX.</p> <p>In my opinion a backup MX is not necessarily needed. A well configured MTA should retry sending messages for several days if it could no deliver it on the first attempt until it&#8217;s returned to the sender. The primary MX should be up again after a few hours or within a day, so there&#8217;s no need for a backup MX.</p> <h1>Anti-Virus</h1> <p>Scanning E-Mail for viruses should be done on the MTA to stop malware from entering the system. Virus scanning is done in Amavis using Clamav, but on Debian it&#8217;s disabled by default. To enable it, remove the comment before <code>@@bypass_virus_checks_maps</code> in the file <code>/etc/amavis/conf.d/15-content_filter_mode</code> and restart amavis. The user <em>clamav</em> needs to be added to the <em>amavis</em> group so that the permissions are correct (restart clamav and amavis).</p> [Less]

A little later than usual, I will give you an update on the "Kolab 3 on openSUSE" status. The past days I mostly worked on the "back end" of Kolab, updating php-pear-* packages, fixing bugs and improving the setup. Progress since week 6 I fixed some ... [More] of the packages to build for SLE 11 SP2. Now, most of them are building with only libcalendaring, libkolab and libkolabxml left, blocking pykolab and kolab-utils. The "old Free/Busy" and the Z-Push setup scripts are removed from the packages, so there are less errors when using setup-kolab. apache2-mod_authn_sasl provided a buggy config. This has been fixed. openSUSE lacks cyrus-imapd with LDAP support, so we're working on packaging a new version with Kolab patches. Roundcubemail requires apache2-mod_php. All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST. The next weeks I'll add further descriptions on how to install Kolab 3 on openSUSE as well as how to troubleshoot.   Tasks libcalendaring, libkolab and libkolabxml need to built on SLE 11 SP 2. setup-ds-admin.pl: There is an issue with perl-Mozilla-LDAP calling ldap_initialize. The Mozilla LDAP API (mozldap) only provides ldap_init, so this call results in an error. Our wiki pages on opensuse.org still need to be updated. There are plans to provide support for OpenLDAP - this includes schema, packages and dependencies. If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me. [Less]

Kolab 3 has built-in ActiveSync support, using Syncroton. It’s integrated into Roundcube, all settings can be done using the Webmail client. Installing it is very easy on Debian Wheezy: apt-get install kolab-syncroton If Kolab 3 is already installed ... [More] and configured (setup-kolab already done) the database needs to be imported by hand: mysql -p roundcube < /usr/share/doc/kolab-syncroton/syncroton.sql If kolab-syncroton is installed before running setup-kolab, the database will be populated with the tables. To check if ActiveSync is working fine, open http://yourserver/Microsoft-Server-ActiveSync and log-in with an available account. It should display It works! Your userid is: 2 and your IP address is: x.x.x.x. Logs are written to /var/log/roundcubemail and $rcmail_config['activesync_debug'] can be added to main.inc.php to increase logging. Just add the account to the mobile device and all E-Mails, calendar entries and contacts will be synced. In Roundcube -> Settings -> Activesync the new device should appear and can be individually configured. It’s possible to set the device name and choose which folders should be synchronized. Basically it works great, but there seems to be a bug when synchronizing with a modern Samsung Android device (such as a Galaxy Note or Galaxy S3). All E-Mails are marked as encrypted and can’t be read. A Bugreport about this is already filled. Another problem I found is synchronizing contacts with a Nokia N9. It seems not possible. Maybe SyncEvolution will do it. [Less]

The last week has been rather busy, yet I managed to spend some hours on Kolab as well as updating and improving some openSUSE packages Kolab depends on. Progress since week 5 The Kolab system services (kolabd, kolab-saslauthd, wallace) are now ... [More] installed correctly and can be started with systemctl. The remaining minor errors when executing setup-kolab have been fixed. bnc#799483 and iko#1556 *should* be resolved. I'm waiting for some more response before closing these. You can log into kolab-webadmin, view, create and edit objects. All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST. The next weeks I'll add further descriptions on how to install Kolab 3 on openSUSE as well as how to troubleshoot.   Tasks Still packages for SLE 11 SP 2 are a work in progress, mostly because SLE misses some dependencies. setup-ds-admin.pl: There is an issue with perl-Mozilla-LDAP calling ldap_initialize. The Mozilla LDAP API (mozldap) only provides ldap_init, so this call results in an error. A config for Kolab’s Freebusy is not installed by default, which results in setup-kolab not setting up the freebusy daemon. You have to manually install the config file into /etc/kolab/freebusy/config.php before starting the setup. This evening I found a bug (probably configuration) which doesn't let me log into roundcube and I'll try to solve it this week. Our wiki pages on opensuse.org still need to be updated. There are plans to provide support for OpenLDAP - this includes schema, packages and dependencies. If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me. [Less]

Following Paul Klos, I'd like to give you an update on the packaging status of Kolab 3 for openSUSE. A few people were curious about how far I am and what's next to do, so I’ll try to give a little insight into what’s the current state: Progress ... [More] Currently all Kolab 3 packages are available on openSUSE 12.2 and openSUSE Factory (thus the upcoming openSUSE 12.3). We have a working 389 Directory Server on openSUSE 12.2 and openSUSE Factory and roundcubemail 0.9-beta. libkolab and libkolabxml will ship through KDE with openSUSE 12.3 natively. All other package dependencies resolve without further problems; packages not distributed in the main repository can be found in server:Kolab:Extras repo. All packages are built and packaged on OBS (server:Kolab:UNSTABLE and server:Kolab:Extras). The repositories can be easily added via zypper or YaST.   Tasks Packages for SLE 11 SP 2 are a work in progress, mostly because SLE misses some dependencies. There are some minor errors when executing setup-kolab but most of them have been fixed. I'm working on bnc#793661, bnc#799483 and iko#1556. setup-ds-admin.pl: There is an issue with perl-Mozilla-LDAP calling ldap_initialize. The Mozilla LDAP API (mozldap) only provides ldap_init, so this call results in an error. A config for Kolab’s Freebusy is not installed by default, which results in setup-kolab not setting up the freebusy daemon. You have to manually install the config file into /etc/kolab/freebusy/config.php before starting the setup. The Kolab system services (kolabd, kolab-saslauthd, wallace) cannot be started with systemctl. Our wiki pages on opensuse.org still need to be updated. If you want to help, to contribute, to test Kolab 3 on openSUSE or if you encounter a bug, don't hesitate to contact me. [Less]

A few weeks ago, the OpenSource Groupware Kolab 3 has been released. It features a brand new Webmail client based on Roundcube (which is really very nice), a completely new web based administration panel (called WAP – Web Administration Panel) ... [More] , integrated ActiveSync with Syncroton and an updated storage format. Many other things are new, compared to older Kolab versions, but the greatest improvement under the hood – in my opinion – is the replacement of OpenPKG with distribution specific packages. This makes it much easier to deploy and update. The people behind Kolab are working with Redhat, so the original packages are RPM based. But thanks to the great community, Debian packages for Wheezy are also already available. The official installation documentation covers Debian Wheezy already, but I’d like to provide my experience and a short installation How-To. This helps to have a quick installed up-and-running Kolab 3 installation running on Debian Wheezy. Installation Steps Install Debian Wheezy (It’s OK to use the 64Bit version) Add the package sources to /etc/apt/sources.list.d/kolab-3.0.listdeb http://mirror.kolabsys.com/pub/debian/kolab-3.0/ wheezy release updates deb-src http://mirror.kolabsys.com/pub/debian/kolab-3.0/ wheezy release updates Prefer Kolab packages over the original ones. Add to /etc/apt/preferences.d/kolabPackage: * Pin: origin mirror.kolabsys.com Pin-Priority: 501 Install packages (they are not signed!): aptitude update; aptitude install kolab Provide a MySQL root password Run setup-kolab It’s easiest to accept all provided default settings Choose “1: Existing MySQL server (with root password already set).” to enter the chosen MySQL root password Check the installation, run kolab list-mailboxes  it should exit without an error. If you get the error cyruslib.CYRUSError: (10, 'LOGIN', 'Invalid user'), just restart the server to re-initialize all services (sometimes the installler does not restart all services) Now you can login to WAP on http://<yourserver>/kolab-webadmin with the user “cn=Directory Manager” and the password provided during setup-kolab (“LDAP Directory Manager”) Create a user and give him the role “kolab-admin”. This is now the Admin user for the domain That’s it, the Kolab server is now up-and-running. Just change the MX record pointing to this server and Kolab will be happy to receive mails. [Less]

Now that Kolab 3 is released, it's time to gather some feedback as well. Many of you have installed Kolab 3, and it's time for you to participate! I'm going to start off with an easy one, but before I do so, please allow me to provide you with some ... [More] rationale. First, please allow me to take a minute of your time to have you read chapter 3.1 of our Administrator Guide - you can stop once you hit section 3.1.1. I personally think the recipient policy is a very powerful feature, and I therefore wanted to show this off with any given installation - so I've provided defaults that apply this policy in one of the many ways that it is possible. Now, I understand that many of you have no purpose for this feature, and that many of you want it changed. We've received questions, and complaints (each of these is to be taken as a compliment, or in the case of Kolab Systems -whom I work for- a sales opportunity). We've provided you with documentation on the why, and the how (to change the behaviour), and the how (to completely disable this feature). We've received enhancement requests to allow this powerful feature to be applied to a user's 'uid' attribute value, too. So now is the time to gather some of your feedback, and see if we can improve the defaults for the use-cases you have, and the way you think the recipient policy could be improved. I'm hereby inviting you to do so; send me a direct email at [email protected], stating; Whether you would like to see the defaults deployed on your system(s) to include the recipient policy, Whether you think the documentation on changing and/or disabling the recipient policy is clear and visible enough (did you find what you were looking for when you Googled?), Whether you have any suggestions that would improve the recipient policy for your needs and use of it. Perhaps stating the obvious but nonetheless worth mentioning: Your sending such feedback to my personal address, and not my professional address. I'll treat it confidentially, and so rest assured that Kolab Systems is not going to take the email you send as a sales opportunity nor that you've opted in to a marketing scheme - I won't allow it, not without your explicit prior consent. That said, please do know that you have Kolab Systems to thank for most -not to say all- of the work that has gone in to Kolab 3. If you wanted to leave a "thank you" note, I suppose [email protected] is the place to do so! This will most likely sollicit a response though, mind you ;-) [Less]