Kroupware Contract Frequently-Asked Questions

This FAQ is maintained by the people of the Kroupware Contract. Send question or remarks to the public mailinglists of the www.kolab.org Project. or directly to Bernhard.Reiter@intevation.de.

FAQ Revised: Tuesday 29 November 2005 12:00:02

Table of Contents

1. General

• 1.1. What is the Kroupware Contract?
• 1.2. What came out of the Kroupware contract?
• 1.3. Was the German government sponsoring/supporting Kolab?
• 1.4. Is it a goal to replace Exchange?
• 1.5. What is the plan beyond version 1? Is there a roadmap?
• 1.6. Can I help (with translations)?

2. KDE Client

• 2.1. Are there other Kolab1 clients than the one you have developed for KDE?

3. Windows Client

• 3.1. How can I make Outlook talk to the Kolab1 Server?
• 3.2. Is there no Free Software Outlook plugin? Will you create one?
• 3.3. Why didn't you create a Free Software plug-in for Outlook?
• 3.4. Where there other Kolab clients on Windows than Outlook? Preferably Free Software?

4. Kolab Server

• 4.1. What do you mean with Scalability?
• 4.2. How to use filtering of emails on the server side
• 4.3. How to change data in LDAP without LDAP browsers
• 4.4. mod_rewrite.h:133:18: ndbm.h: No such file or directory
• 4.5. Why did you choose OpenPKG rpms. (I prefer, Fedora rpms, SUSE rpm, Debian deb....)
• 4.6. How to make OpenLDAP fast on large installations

1. General

1.1. What is the Kroupware Contract?

The companies Erfrakon, Intevation and Klarälvdalens Datakonsult had been contracted by the German Bundesamt für Sicherheit in der Informationstechnik (BSI) (Federal Agency of IT-Security) to provide a groupware solution accessible with Windows running Outlook and GNU/Linux running KDE clients. These companies leveraged Free Software components and operated in an open manner as much as possible to maximise the benefits for the Free Software community. Kroupware is the name for the activities done by this group under this contract between October 2002 and July 2003.

1.2. What came out of the Kroupware contract?

The resulting concept is called Kolab. A server implementation now called Kolab1 Server was developed on on mature Free Software components like Postfix and Cyrus IMAPD. Check the original architecture document available from kroupware.kolab.org for the details.

The KDE client side was based on enhanced versions of KMail, KOrganizer and other KDE 3.1 components. The results have been incorporated into the codebase for forthcoming KDE versions. However only a part of it was activated in the KDE 3.2 release as KDE development continues.

1.3. Was the German government sponsoring/supporting Kolab?

At no point Kolab was "supported" or "sponsored" by the German Government to be precise. Saying this would missrepresent the situation. Kroupware is a regular commercial business contract after the three companies won the tender to deliver a solution for the groupware requirements of the BSI (compare answer 1.1). The participating companies organise the open development of this Free Software under the name of Kolab only to create the best technical results. This could be understood as "indirect funding of Free Software", but it is not more funding then "indirectly funding proprietary software" when you buy a solution from proprietary vendors. It helps us if you avoid the simplification and speak about a contract for a solution having a good side effect for Free Software.

1.4. Is it a goal to replace Exchange?

This is a contracted service where our customer wanted to set up a groupware solution given certain conditions. Third parties can also enjoy some of the software, but this is just a benefit from the Free Software business model of the involved companies.

So no, it's not a goal to build a replacement for Exchange or Outlook. On the software side we have assembled a solution that solves some typical asynchronous groupware tasks like group calendaring. Our usage of standards like disconnected IMAP and the iCalender format is a new, innovative approach.

1.5. What is the plan beyond version 1? Is there a roadmap?

Check www.kolab.org for progress about Kolab. The Kroupware contract was finished July 2003. Naturally our companies are still active within Kolab and you will find us open for contracts to design and implement more features in guarenteed timeframe.

Note that the client feature code has been given into the development versions of KDE and will most likely continue to live there. The components of the Kolab Server already have their own lifes.

1.6. Can I help (with translations)?

Yes! Check the website of the Kolab Project.

2. KDE Client

2.1. Are there other Kolab1 clients than the one you have developed for KDE?

The Kroupware contract itself had a limited focus and is now concluded. We concentrated on the KDE Kolab1 client. The whole Kolab server concept is based on open standards, thus other groups like the Mozilla or Evolution people are welcome to adopt them and become full Kolab clients. It is up to them and their community to decide to do this. Check with the Kolab Project for news.

3. Windows Client

3.1. How can I make Outlook talk to the Kolab1 Server?

A plug-in is needed. Kolab1 originally was tested with the proprietary InsightConnector in version 1.x. It stopped being available later. The Kolab Project most likely has a more uptodate list of available plug-ins.

Since it appeared on the market most success reports came using the proprietary Plug-in Toltec Connector: www.toltec.co.za

3.2. Is there no Free Software Outlook plugin? Will you create one?

Within the Kroupware contract we did not create a Free Software plug-in for Outlook and also had no knowledge of such a development.

At end of the project the most advanced development for a Free Software plugin for Microsoft MAPI based Outlook was done by SourceXtreme, Inc..

3.3. Why didn't you create a Free Software plug-in for Outlook?

It would have been a lot of work. Especially because of subtle differences of the various Windows/OL/IE combinations. Doing a plug-in for Outlook means tailchasing Microsoft. Serious funding would be needed to do that.

For several reasons this did not seem to be an good strategy. The proprietary plug-in already existed and could be used right away. On the cost side we expected that operating a Kolab Server saves significantly more than the costs for the proprietory plug-in licenses.

For the Free Software community this would be only a transition step as we ought to have a Free Software solution in the long run and an increasing number of people deploying the Kolab KDE clients. So if more funding comes available we prefer developing a Free Software Kolab client for Windows and improve the Kolab Server to further outrun the competition with more innovative features.

3.4. Where there other Kolab clients on Windows than Outlook? Preferably Free Software?

Yes there were other Kolab clients on Windows. Check the Kolab Project website for updated information.

4. Kolab Server

4.1. What do you mean with Scalability?

Kolab was designed with maximal scalability in mind. Basically this means we are targeting possible installations with many thousand and maybe up to millions of users. In order to achive this we employ a number of technologies but try very hard to not introduce to much complexity.

Scalability techniques employed are:

• make it possible to distribute the Kolab components across multiple servers. E.g. seperate the MTA and the IMAPD
• make it possible to cluster functionality in order to gain high performance and high availability. E.g. use several Postfix MTA's and MX records for HA and HP
• Do not put unecessary processing on the Kolab server but use the clients instead. Basically this means that with the number of the clients the available processing power also increases
• Optimize the architecture for I/O. This means mainly avoid unnecessary copying of data and use of burst technologies
• Allow for distributed clustering basically to gain HA and network bandwidth/latency
• Use latency hiding techniques
• Avoid locking whenever possible. Use copy+delete instead of modify operations when appropriate.

4.2. How to use filtering of emails on the server side

Filtering on the server side is currently not supported with neither the web gui nor the KDE Kolab client. For filtering on the server you must use the RFC 3028 conform sieve scripting language. Please be aware of the potential pitfall with mailboxnames.

If you want to get sieve working please consider the following hints:

• /kolab/var/imapd/log/lmtpd.log is your friend
• In order to use fileinto, you need to know that the mailboxes are specified as follows:

  fileinto "user/username@some^host^name/path/to/folder";

  "user" is literal, "user@some^host^name" needs to be replaced, as does the path/to/folder of course. In orde to get an idea about the usernames and paths please check /kolab/var/imapd/spool/user on the Kolab server.

• Example script:
  require ["fileinto"];
  if header :contains ["List-Id"] [""] {
  fileinto "user/staikos@kde^org/KDE/Kroupware";
  }
  
• Don't forget that you must "put" the script with the sieve client and then activate it.
• please be careful not to break forwarding and vacation handling as offered by Kolab which both also use sieve to get their tasks done.

4.3. How to change data in LDAP without LDAP browsers

• rc.kolab stop
• slapcat -f /kolab/etc/openldap/slapd.conf -l /tmp/my_first.ldif
• edit the file to your requirements The best way to create a ldappassword is by means of slappasswd, just cut 'n paste the encrypted password into the *.ldif file.
• destroy your database files underneath /kolab/var/openldap/openldap-data
• load your *.ldif file, using slapadd slapadd -x -D "cn=manager,dc=" -W -f /kolab/etc/openldap/slapd.conf -l /tmp/my_first_changed.ldif
• rc.kolab start

4.4. mod_rewrite.h:133:18: ndbm.h: No such file or directory

The header file ndbm.h is missing in your install. gdbm as provided contains the required header file. You may simply copy it to /kolab/include/ manually. Depending on your prefix the required command looks like

• cp /kolab/RPM/SRC/gdbm/gdbm-1.8.3/ndbm.h /kolab/include/

4.5. Why did you choose OpenPKG rpms. (I prefer, Fedora rpms, SUSE rpm, Debian deb....)

We thought that www.OpenPKG.org is currently the best solution in order to be able to support many platforms simultaneously. With the help of the OpenPKG people (especially Thomas Lotterer) we could offer binary packages for a lot of plattforms.

Another key feature of basing Kolab1 on OpenPKG is that the OpenPKG team is well known for high quality and timely security fixes.

Mandrake was the first distributor to pick up Kolab and make directly supported packages for their GNU/Linux distribution. Mandrake 10.0 contains a full featured Kolab1 Server.

4.6. How to make OpenLDAP fast on large installations

Put the following into your crontab on the server:

00 6 * * * root /kolab/sbin/slapindex -b dc=foo,dc=bar

This increases the performance on queries dramatically on large installations! Thanks to Stefan Lang for providing this FAQ entry.