Integrating Kolab2 Server in GNU/Linux distributions
From Kolab Wiki
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.
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)?
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.
- kolab-compile-options - This page can be used as reference for other distributions.
- kolab-app-user - Which users are assigned to the involved applications.
- kolab-major-app-patches - Some information about the patches to major applications that are needed to run kolab succesfully.
A lot of information about running kolab on suse can be obtained from the opensuse kolab wiki.
- suse-packages - How do the suse-9.2 packages compare to the packages required by kolab
- suse-compile-options - How do the suse-9.2 compile options compare the compile options used by the kolab obmtool
- suse-app-user - Which users are assigned to the involved applications
- Required Packages - 'Base' Packages
- debian-packages - How do the debian sarge packages compare to the packages required by kolab
- debian-compile-options - How do the debian sarge compile options compare the compile options used by the kolab obmtool
- debian-app-user - Which users are assigned to the involved applications
- debian-required-packages - 'Base' Packages
- debian-horde-packages - Packages needed for Horde webmail fonctionnalities
- Gentoo: A native non-openpkg installation of Kolab on Gentoo
Patches made by Mandriva to the kolab cvs version are maintained at the following web pages: