Blogs

Cornelius Hald's picture

Kolab 3.3 Multi-Domain Setup on CentOS 7

Today we’re showing how to extend thesingle domain setup done earlier to get a truly multi domain Kolab install. You should probably reserve a couple of hours as there are quite some changes to do and not everything totally trivial. Also, if you’ve not read the blog about single domain setup, now is a good time :)

First of all, you can find the official documentation here. It’s probably a good idea to read it as well. We start with the easy parts and end with postfix, which needs the most changes. At the very end there are a couple of things that may or may not be issues you should be aware of.

Change Amavisd

We tell amavisd to accept all domains.

vi /etc/amavisd/amavisd.conf
# Replace that line
@local_domains_maps = ( [".$mydomain"] );
# With this line
$local_domains_re = new_RE( qr'.*' );

Change Cyrus IMAPD

Tell the IMAP server how to find our other domains. Add the following to the bottom of /etc/imapd.conf

ldap_domain_base_dn: cn=kolab,cn=config
ldap_domain_filter: (&(objectclass=domainrelatedobject)(associateddomain=%s))
ldap_domain_name_attribute: associatedDomain
ldap_domain_scope: sub
ldap_domain_result_attribute: inetdomainbasedn

Change Roundcube (webmail)

Basically you need to change the base_dn at several places. The placeholder ‘%dc’ is replaced during run-time with the real domain the user belongs to.

To save me some typing I’m pasting the diff output produced by git here. So it looks more than it actually is…

Cornelius Hald's picture

Kolab 3.3 Single-Domain Setup on CentOS 7

After a lot of reading and some trial-and-error, I’ve figured out a way to reproducible install Kolab 3.3 on CentOS 7 with multi-domain support. Most information can be found in the official documentation, however some parts are not that easy to understand for a Kolab noob.

I won’t go into too much details here, so it will be mostly a step-by-step thing without a lot of explanation. You really should not use this document as your only source of information. At least read through the official documentation as well. Also you should feel confident with Linux admin stuff – otherwise Kolab might not be the best choice as it is not an of-the-shelf solution.

In this document we will use the following hosts and domains. Replace them with your own.

  • Hostname: mail.skolar.de
  • Management domain: skolar.de
  • Primary hosted domain: kodira.de
  • Alias for primary hosted domain: tourschall.com
  • We could go on with a secondary hosted domain, but works exactly like the primary hosted domain, so we won’t go there…

Let’s start with a fresh minimal CentOS 7 install where you are root.

First we disable SE-Linux and the firewall. You should re-enable that later, but for now we don’t won’t both to get into our way:

# Check status of SE-Linux
sestatus
# Temporarily disable it
setenforce 0
# Stop firewall
systemctl stop firewalld
# Disable firewall (dont't start on next boot)
systemctl disable firewalld

To permanently disable SE-Linux edit /etc/selinux/config (I recommend you do this now)

Set a valid host name (needs to be resolvable via DNS)

echo "mail.skolar.de" > /etc/hostname

Add Kolab repositories and GPG keys

roundcube's picture

Roundcube Webmail 1.1-beta available

We’re proud to announce that the beta release of the next major version 1.1 of
Roundcube webmail is now available for download and testing. With this
milestone we introduce a bunch of new features and some clean-up with the 3rd
party libraries Roundcube uses:

  • Allow searching across multiple folders
  • Improved support for screen readers and assistive technology using
    WCAG 2.0 and WAI ARIA standards
  • Support images in HTML signatures (copy & paste)
  • Added namespace filter and folder searching in folder manager
  • New config option to disable UI elements/actions
  • Stronger password encryption using OpenSSL
  • Support for the IMAP SPECIAL-USE extension
  • Support for Oracle databases
  • Moved 3rd party libs to vendor directory, managed by Composer

And of course plenty of small improvements and bug fixes.

IMPORTANT: with this version, we dropped support for PHP < 5.3.7 and
Internet Explorer < 9. IE7/IE8 support can be restored by enabling the
legacy_browser plugin.

See the complete Changelog at trac.roundcube.net/wiki/Changelog
and download the new packages from roundcube.net/download. Please note that this
is a beta release and we recommend to test it on a separate environment. And
don’t forget to backup your data before installing it.

How to fix error when moving events between calendars

Recently, I noticed "Failed to save changes" error when tried to move events between distinct calendars.
After a short investigation I found that this bug is already fixed, but not packaged for an easy upgrade, so I will shortly describe how to apply fix for Debian Wheezy and Kolab 3.3.

The above-mentioned bug is already fixed in roundcubemail-plugins-kolab repository.
You can jump directly to the a3d5f717 commit and read details.

Quick Remedy

We need to replace calendar and libkolab plugins.

Download code from already fixed roundcubemail-plugins-kolab repository to /tmp temporary directory.

# cd /tmp
# wget http://git.kolab.org/roundcubemail-plugins-kolab/snapshot/roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Rename mentioned roundcubemail plugins directories that will be replaced in next step.

# mv /usr/share/roundcubemail/plugins/{calendar,calendar.before_fix}
# mv /usr/share/roundcubemail/plugins/{libkolab,libkolab.before_fix}

Extract both plugins from downloaded archive.

# tar xvfz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545/plugins/{calendar,libkolab} --strip-components 2

Install and configure plugins.

# mv {calendar,libkolab} /usr/share/roundcubemail/plugins/
# ln -s /etc/roundcubemail/calendar.inc.php /usr/share/roundcubemail/plugins/calendar/config.inc.php
# ln -s /etc/roundcubemail/libkolab.inc.php /usr/share/roundcubemail/plugins/libkolab/config.inc.php

Remove downloaded archive.

# rm roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Simple and easy.

How to fix error when moving events to between calendars

Recently, I noticed "Failed to save changes" error when tried to move events between distinct calendars.
After a short investigation I found that this bug is already fixed, but not packaged for an easy upgrade, so I will shortly describe how to apply fix for Debian Wheezy and Kolab 3.3.

The above-mentioned bug is already fixed in roundcubemail-plugins-kolab repository.
You can jump directly to the a3d5f717 commit and read details.

Quick Remedy

We need to replace calendar, and libkolab plugins.

Download code from already fixed roundcubemail-plugins-kolab repository to /tmp temporary directory.

# cd /tmp
# wget http://git.kolab.org/roundcubemail-plugins-kolab/snapshot/roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Rename mentioned roundcubemail plugins directories that will be replaced in next step.

# mv /usr/share/roundcubemail/plugins/{calendar,calendar.before_fix}
# mv /usr/share/roundcubemail/plugins/{libkolab,libkolab.before_fix}

Extract both plugins from downloaded archive.

# tar xvfz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545/plugins/{calendar,libkolab} --strip-components 2

Install and configure plugins.

# mv {calendar,libkolab} /usr/share/roundcubemail/plugins/
# ln -s /etc/roundcubemail/calendar.inc.php /usr/share/roundcubemail/plugins/calendar/config.inc.php
# ln -s /etc/roundcubemail/libkolab.inc.php /usr/share/roundcubemail/plugins/libkolab/config.inc.php

Remove downloaded archive.

# rm roundcubemail-plugins-kolab-a3d5f717a2250cfbd7a5652a445adcd6a0845545.tar.gz

Simple and easy.

Kolab 3.2 for Gentoo is ready to rumble

Just in time for the official Kolab 3.3 release, our Gentoo packages for Kolab 3.2 became stable and ready to use. This will clear the way for the upcoming release of Kolab 3.3 for Gentoo. Altough this release won't bring any major changes, it prepares the ground for upcoming developments and new features in Kolab 3.3. Further, with Kolab 3.2 we introduced an upgrade path between Kolab releases for Gentoo and we will try our best to keep updates as consistent and comfortable as possible.

roundcube's picture

Our Wish List for Encryption Browser Extensions

PGP encryption is one of the most frequently requested features for Roundcube and for good reasons more and more people start caring about end-to-end encryption in their everyday communication. But unfortunately webmail applications currently can’t fully participate in this game and doing PGP encryption right in web-based applications isn’t a simple task. Although there are ways and even some basic implementations, all of them have their pros and cons. And yet the ultimate solution is still missing.

Browser extensions to the rescue

In our opinion, the way to go is with a browser extension to do the important work and guard the keys. A crucial point is to keep the encryption component under the user’s full control which in the browser and http world can only be provided with a native browser plugin. And the good news is, there are working extensions available today. The most prominent one probably is Mailvelope which detects encrypted message bodies in various webmail applications and also hooks into the message composition to send signed and encrypted email messages with your favorite webmail app. Plus another very promising tool for end-to-end encryption is coming our way: p≡p. A browser extension is at least planned in the longer term. And even Google just started their own project with the recently announced end-to-end Chrome extension.

That’s a good start indeed. However, the encryption capabilities of those extensions only cover the message body but leave out attachments or even pgp/mime messages. Mostly because there extension has limited knowledge about webmail app and there’s no interaction between the web app and the extension. On the other side, the webmail app isn’t aware of the encryption features available in the user’s browser and therefore suppresses certain parts of a message like signatures. A direct interaction between the webmail and the encryption extension could help adding the missing pieces like encrypted attachment upload and message signing. All we need to do is to introduce the two components to each others.

Timotheus Pokorra's picture

Proxy for Kolab yum and apt-get repositories

On the Kolab IRC we have had some issues with apt-get talking about connection failed etc.

So I updated the blogpost from last year: http://www.pokorra.de/2013/10/downloading-from-obs-repo-via-php-proxy-file/

The port of the Kolab Systems OBS is now port 80, so there is not really a need for a proxy anymore. But perhaps it helps for debugging the apt-get commands.

I have extended the scripts to work for apt-get on Debian/Ubuntu as well, the original script was for yum only it seems.

I have setup a small php script on a server somewhere on the Internet.

In my sample configuration, I use a Debian server with Lighttpd and PHP.

Install:

apt-get install lighttpd spawn-fcgi php5-curl php5-cgi

changes to /etc/lighttpd/lighttpd.conf:

server.modules = (
        [...]
        "mod_fastcgi",
        "mod_rewrite",
)
 
fastcgi.server = ( ".php" => ((
                     "bin-path" => "/usr/bin/php5-cgi",
                     "socket" => "/tmp/php.socket",
                     "max-procs" => 2,
                     "bin-environment" => (
                       "PHP_FCGI_CHILDREN" => "16",
                       "PHP_FCGI_MAX_REQUESTS" => "10000"
                     ),
                     "bin-copy-environment" => (
                       "PATH", "SHELL", "USER"
                     ),
                     "broken-scriptfilename" => "enable"
                 )))
 
url.rewrite-once = (
    "^/obs\.kolabsys\.com/index.php" => "$0",
    "^/obs\.kolabsys\.com/(.*)" => "/obs.kolabsys.com/index.php?page=$1"
)

and in /var/www/obs.kolabsys.com/index.php:

How to monitor Kolab processes

I have been using self hosted Kolab Groupware everyday for quite a while now.
Therefore the need arose to monitor process activity and system resources using Monit utility.

Table of contents

Couple of words about monit

monit is a simple and robust utility for monitoring and automatic maintenance, which is supported on Linux, BSD and OS X.

Software installation

Debian Wheezy currently provides Monit 5.4.

To install it execute command:

$ sudo apt-get install monit

Monit daemon will be started at the boot time. Alternatively you can use standard System V init scripts to manage service.

mollekopf's picture

Putting the code where it belongs

I have been working on better ways to write asynchronous code. In this post I’m going to analyze one of our current tools, KJob, in how it helps us writing asynchronous code and what is missing. I’m then going to present my prototype solution to address these problems.

KJob

In KDE we have the KJob class to wrap asynchronous operations. KJob gives us a framework for progress and error reporting, a uniform start method, and by subclassing it we can easily write our own reusable asynchronus operations. Such an asynchronous operation typically takes a couple of arguments, and returns a result.

A KJob, in it’s simplest form, is the asynchronous equivalent of a function call:

int doSomething(int argument) {
    return getNumber(argument);
}
struct DoSomething : public KJob {
    KJob(int argument): mArgument(argument){}

    void start() {
        KJob *job = getNumberAsync(mArgument);
        connect(job, SIGNAL(result(KJob*)), this, SLOT(onJobDone(KJob*)));
        job->start();
    }

    int mResult;
    int mArgument;

private slots:
    void onJobDone(KJob *job) {
        mResult = job->result;
        emitResult();
    }
};

What you’ll notice immediately that this involves a lot of boilerplate code. It also introduces a lot of complexity in a seemingly trivial task. This is partially because we have to create a class when we actually wanted a function, and partially because we have to use class members to replace variables on the stack, that we don’t have available during an asynchronous operation.

So while KJob gives us a tool to wrap asynchronous operations in a way that they become reusable, it comes at the cost of quite a bit of boilerplate code. It also means that what can be written synchronously in a simple function, requires a class when writing the same code asynchronously.

Inversion of Control

A typical operation is of course slightly more complex than doSomething, and often consists of several (asynchronous) operations itself.

What in imperative code looks like this:

int doSomethingComplex(int argument) {
    return operation2(operation1(argument));
}

…results in an asynchronous operation that is scattered over multiple result handlers somewhat like this: