Blogs

Timotheus Pokorra's picture

Kolab/Roundcube with Squirrelmail’s IMAPProxy on CentOS6

There is the suggestion on the page http://trac.roundcube.net/wiki/Howto_Config/Performance to use a caching IMAP proxy. This will cache the connections to the IMAP server for each user, so that not every click in Roundcube on a message leads to the creation of a new connection.

I found these alternatives:

I had a closer look at Nginx IMAP Proxy and Squirrelmail’s IMAP Proxy.

Squirrelmail’s IMAPProxy
This is actually the easiest solution, at least compared to Nginx IMAP Proxy.

Install from EPEL with: yum install up-imapproxy

I have changed the following values in /etc/imapproxy.conf:

server_hostname localhost
listen_port 8143
listen_address 127.0.0.1
server_port 143
force_tls yes

To install the service:

service imapproxy start
chkconfig imapproxy on

Roundcube configuration
You need to change the port that Roundcube connects to, instead of port 143 now use 8143 where your Squirrelmail’s IMAP Proxy is running.

In file /etc/roundcubemail/config.inc.php:

$config['default_port'] = 8143;

I have added the initIMAPProxy.sh script to my TBits scripts: initIMAPProxy.sh

Timotheus Pokorra's picture

Unattended installation of Kolab

For testing, it is useful to run setup-kolab in unattended mode.

There might be other reasons too, eg. as part of a docker setup etc.

One option is to use Puppet: Github: puppet-module-kolab. I don’t know enough about Puppet yet myself, and I have not tried it yet.

My way for an unattended setup is to patch setup-kolab in this way (see initSetupKolabPatches.sh to see the action in full context):

Aaron Seigo's picture

first Kontact 5 meeting on IRC

One of the things that came out of the Winter 2014 KDE PIM sprint in Munich is that people felt we, as a team, needed to coordinate more effectively and more often. Bringing together people from Kolab, upstream KDE PIM, downstream packagers and even users of PIM was fantastically productive, and everyone wanted to keep that ball rolling.

One suggestion was to do regular team meetings on IRC to formulate plans and keep up with each other's progress. While the mailing list is great for ongoing developer discussion and review board is fantastic for pushing forward technical steps, coordinating ourselves as a team can really be helped with an hour or two of real time discussion every so often.  So we lined up the first meeting for yesterday, and I have to say that I was very impressed at the turn-out. In all, 12 people signed up on the meeting's scheduling Doodle and I think there were even more in attendance, some just listening in but many participating.

Aleix Pol was kind enough to take notes and sent a good summary to the mailing list. The big topics we covered were the Qt5 / KDE Frameworks 5 (KF5) ports of the KDE PIM libraries, a new revision of Akonadi and a release roadmap for a Qt5/KF5 based Kontact. These are all quite important topics for both Kolab, which relies on Kontact for its desktiop client, and KDE itself, so it was good to focus on them and make some progress. And make progress we did!

There will be releases of the libraries for Qt5 as frameworks coming soon. The porting effort, led largely by Laurent Montel, has done a great job to get the code to the point that such a release can be made. The kdepimutils library is nearly gone, with the useful parts finding their way to more appropriate frameworks that already exist, and kcalcore needs a bit more love ... but otherwise we're "there" and just the repository creation remains. Aleix Pol and Dan Vratil will be heading up this set of tasks, and once they are done we will be left with just the small core of libraries that rely on Akonadi. Which brings us to the next topic.

Aaron Seigo's picture

first Kontact 5 meeting on IRC

One of the things that came out of the Winter 2014 KDE PIM sprint in Munich is that people felt we, as a team, needed to coordinate more effectively and more often. Bringing together people from Kolab, upstream KDE PIM, downstream packagers and even users of PIM was fantastically productive, and everyone wanted to keep that ball rolling.

One suggestion was to do regular team meetings on IRC to formulate plans and keep up with each other's progress. While the mailing list is great for ongoing developer discussion and review board is fantastic for pushing forward technical steps, coordinating ourselves as a team can really be helped with an hour or two of real time discussion every so often.  So we lined up the first meeting for yesterday, and I have to say that I was very impressed at the turn-out. In all, 12 people signed up on the meeting's scheduling Doodle and I think there were even more in attendance, some just listening in but many participating.

Aleix Pol was kind enough to take notes and sent a good summary to the mailing list. The big topics we covered were the Qt5 / KDE Frameworks 5 (KF5) ports of the KDE PIM libraries, a new revision of Akonadi and a release roadmap for a Qt5/KF5 based Kontact. These are all quite important topics for both Kolab, which relies on Kontact for its desktiop client, and KDE itself, so it was good to focus on them and make some progress. And make progress we did!

There will be releases of the libraries for Qt5 as frameworks coming soon. The porting effort, led largely by Laurent Montel, has done a great job to get the code to the point that such a release can be made. The kdepimutils library is nearly gone, with the useful parts finding their way to more appropriate frameworks that already exist, and kcalcore needs a bit more love ... but otherwise we're "there" and just the repository creation remains. Aleix Pol and Dan Vratil will be heading up this set of tasks, and once they are done we will be left with just the small core of libraries that rely on Akonadi. Which brings us to the next topic.

Management of ProFTPD users with kolab-webadmin

ProFTPD is a versatile ftp server. I recently integrated it in my Kolab 3.3 server environment, so that user access be can easily organized by the standard kolab-webadmin. The design looks as follows:

Kolab users are be able to login to ProFTPD but every user gets jailed in his own separate (physical) home directory. According to his group memberships, aditional shared folders can be displayed and accessed within this home directory.

You will need proftpd with support for ldap and virtual root environments. In Debian and Ubuntu, this is achieved via module packages:

  • proftpd-mod-ldap, proftpd-mod-vroot

On other platforms you may need to compile your own proftpd.

Via kolab-webadmin I created a new organizational unit FTPGroups within parent unit Groups. Within this unit, you can now add groups of type (Pure) POSIX Group. These groups are later used to restrict or permit access to certain directories or apply other custom settings per group by using the IfGroup directive of ProFTPD.

Note, that you stick to sub-units of ou=Groups here, so that this unit will be recognized by the kolab-webadmin. The LDAP-record of such a group may look like this:

Aaron Seigo's picture

Chwala

The last month has been a wonderful romp through the land of Kolab for me, getting better acquainted with both the server and client(s) side of things. I had expected to learn quite a bit in that time, of course, but had little idea just what it would end up being. That is half the fun of exploration. Rather than keeping it all to myself, I thought I'd share some of the more interesting bits with you here.

First up: chwala. Ch-what-a? Those of you know Polish will recognize that word immediately; it means "glory". So, first thing learned: there are fun names buried in the guts of Kolab. Collect them all! Ok, so what does it do?

It's the file storage backend for the Kolab web client. You can find the code here. As with Roundcube, the web-based groupware application that ships with Kolab, it is written in PHP and is there to glue file storage to groupware application. This is responsible for the "save to cloud" and "attach from cloud" features in the webmail client, for instance, which allows you to keep your files on the server side between recipients on the same host. The files are also available over webdav, making browsing and working with files from most any modern file manager easy.

The default storage system behind the API is exactly what you'd expect from Kolab: IMAP. This makes the file store essentially zero-configuration when setting up stock Kolab, and it gives the file store the same performance and access mechanisms as the other groupware data Kolab stores for you. Quite an elegant solution.

However, Chwala is not limited to IMAP storage. Let's say you want comprehensive offline file synchronization or you wish to integrate it with some network attached storage system you have. No problem: Chwala has a backend API with which you can implement integration with whatever storage system you wish.

In addition to the default IMAP store, Chwala also comes with a backend for Seafile which is a free software storage cloud system that has a cross-platform synchronization client. (Which happens to be written with Qt, by the way.) Seafile code can be found here.

Aaron Seigo's picture

Chwala

The last month has been a wonderful romp through the land of Kolab for me, getting better acquainted with both the server and client(s) side of things. I had expected to learn quite a bit in that time, of course, but had little idea just what it would end up being. That is half the fun of exploration. Rather than keeping it all to myself, I thought I'd share some of the more interesting bits with you here.

First up: chwala. Ch-what-a? Those of you know Polish will recognize that word immediately; it means "glory". So, first thing learned: there are fun names buried in the guts of Kolab. Collect them all! Ok, so what does it do?

It's the file storage backend for the Kolab web client. You can find the code here. As with Roundcube, the web-based groupware application that ships with Kolab, it is written in PHP and is there to glue file storage to groupware application. This is responsible for the "save to cloud" and "attach from cloud" features in the webmail client, for instance, which allows you to keep your files on the server side between recipients on the same host. The files are also available over webdav, making browsing and working with files from most any modern file manager easy.

The default storage system behind the API is exactly what you'd expect from Kolab: IMAP. This makes the file store essentially zero-configuration when setting up stock Kolab, and it gives the file store the same performance and access mechanisms as the other groupware data Kolab stores for you. Quite an elegant solution.

However, Chwala is not limited to IMAP storage. Let's say you want comprehensive offline file synchronization or you wish to integrate it with some network attached storage system you have. No problem: Chwala has a backend API with which you can implement integration with whatever storage system you wish.

In addition to the default IMAP store, Chwala also comes with a backend for Seafile which is a free software storage cloud system that has a cross-platform synchronization client. (Which happens to be written with Qt, by the way.) Seafile code can be found here.

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.