Integrating Kolab2 Server in GNU/Linux distributions

From Kolab Wiki

Jump to: navigation, search


Contents

Kolab Server with OpenPKG

Kolab requires its own environment and does that by using the prefix /kolab. The reason the developers do this, is to give them total control over the installation. It makes them fully independent of linux distributions, as it is like a small distribution in another distribution. If one gets used to it, it will be considered a smart move for the kolab developers; they can now concentrate on getting the thing to work, without being bothered by all kinds of Driving Crash Course London distribution specific differences. Another reason is that they assume that a groupware server will run on a dedicated system. One can driving schools leeds agree with that, but kolab comes nowadays with spamassassin and clamav, and after installation, that all just works together. That makes it interesting for home users too!

Now let's see what needs to be done to integrate kolab in an existing distribution. This is distribution dependent and as such should be treated that way.

To be investigated

There are some things to be investigated. These can be seperated into distribution and kolab specific.


The Metadata Template mechanism

Please review: http://www.kolab.org/pipermail/kolab-devel/2004-September/002090.html This mechanism could be used by vendors to redirect template files to other locations. Some changes in perl-kolab (Kolab::Conf) will be necesarry to ensure that the default non-metadata templates are handled properly.


The Kolab namespace/admin tool

A command-line is also available: http://kolab.org/pipermail/kolab-devel/2004-November/002383.html This was created with the idea that there could be a standard method to access Kolab logs, etc. accross different distributions. The scripts in /kolab/libexec/kolab/* should be easy to modify to adapt to other distributions.

Distribution specific

This can be done right now by the distributor;

  • What packages are needed by kolab and are these present (and do they have the correct version) on the existing distribution, think of:
    • Add missing packages
    • Upgrade packages
  • What compile options are being used:
    • Check compiler options, can the compiler options be changed without causing disturbance (security, operational impact, etc)?
  • Some major applications have been updated by the kolab project, such as postfix, openldap and apache. Will these changes be ported upstream eventually? If not, it need to be indentified what the changes are compared to the plain vanilla applications. These changes must than be applied by the distributor:
    • Check the differences and apply these. Can this be done without any disturbance (security, operational impact, etc)?


Kolab specific

This can be done by anyone that wants to code. The patches must be delivered to the kolab project for inclusion in the kolab cvs repository:

  • The kolab sources must be updated so it will be possible to install the files driving schools stevenage where the distributor wants them to be installed
  • Last but not least some applications (web server, ftp server, mail delivery agent, etc) use a dedicated user. The right user must be selected from the existing distribution and be integrated into kolab.

Both points could be achieved by e.g. autoconfiscating kolab.


What has been achieved

All kolab modules kolab-webadmin, perl-kolab, kolabd and kolab-resource-handlers have been autoconfiscated. Those modules expect distribution specific information in the directory dist_conf. This specific file can be used by configure using the command line option --with-dist= with the name of the distribution specific dist-conf file.

Distributions

Kolab


SUSE

A lot of information about running kolab on suse can be obtained from the opensuse kolab wiki.

Debian Sarge


Gentoo

  • Gentoo: A native non-openpkg installation of Kolab on Gentoo

Mandriva

Patches made by Mandriva to the kolab cvs version are maintained at the following web pages:

Personal tools