Kolab

From openSUSE

Kolab is a free software groupware solution. From version 2.0 on it allows full seamless support of mixed clients environments (Outlook/KDE/Web).

The following functionality is provided by; emailserver, spam and virus filtering, webinterface. Kolab supports secure protocols as; imaps, https, smtps, https, etc.

The web interface can be used to add, modify and remove users, domains, distributions list, shared folders, among other things. The groupware functionality seem to be working.

You are very much encouraged to help testing the kolab functionality! Any changes that are needed can be emailed (for the email address see the changelog in the kolab package: rpm -q --changelog kolab).



Contents

Introduction

All packages are available via openSUSE's build service, they are retrieved from several repositories, such as php:applications and a kolab specific repository. The packages in the UNSTABLE repository are based on code from kolab cvs. Hopefully, this page helps you to get kolab installed natively on openSUSE.

In case you're an openSUSE community member you can vote to have openSUSE support Kolab. Make sure to vote, if you like kolab on openSUSE!

Live CD

This is probably outdated


A live CD, showing off kolab, and some of it's available clients such KDE's kontact and horde can be downloaded from gwdg.de. The live-cd can be used to easily obtain a sneak preview of the capabilities of the involved applications that make up the kolab groupware server. The live-cd is build with the packages mentioned above.

Installation

The packages can be installed with yast, yum, smart, zypper or with apt.
Kolab on openSUSE-10.3 and later needs the non oss repository, to be able to install the rpm unace. That package is required by amavisd-new.

You also have to add the server:php:applications and server:Kolab:UNSTABLE buildservice projects to your packagemanager in order to fulfill all dependencies. Kolab can be installed with, YaST, Zypper, Smart and apt. Which one to use is up to reader.

Repositories

Make the following repositories known to your software package installer:

Version:
Factory

http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_Factory
http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/openSUSE_Snapshot

Version:
11.2

http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_11.2
http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/openSUSE_11.2

Version:
11.1

http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_11.1
http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/openSUSE_11.1

Version:
11.0

http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_11.0
http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/openSUSE_11.0


Once the repositories have been configured, kolab and all it's dependent packages can be installed:

zypper|smart|apt install kolab

Don't be surprised if this command pulls in 50 - 140 packages, among them are at least 30 php5-pear packages!

Service configuration

The changes that are needed for kolab to the sysconfig files can be performed by running the script:

/usr/share/kolab/scripts/kolab_opensuse_bootstrap

The script will make the following changes to get kolab running:

The instructions given below are not needed to be executed manually, as that is done by the script mentioned above!


Edit the file /etc/sysconfig/apache2 and add the following apache2 modules to the APACHE_MODULES variable:

ldap authnz_ldap dav dav_fs rewrite authn_alias php5
  • Also add the flag SSL to the APACHE_SERVER_FLAGS variable in /etc/sysconfig/apache2 file
  • Set OPENLDAP_START_LDAPS to yes in the file /etc/sysconfig/openldap or use yast2 to configure it. Yast2 -> System -> Editor for /etc/sysconfig files -> Network -> LDAP, find the right variable and set it to yes.
  • Set SASLAUTHD_AUTHMECH to ldap in the file /etc/sysconfig/saslauthd (the default value is "pam")
  • Set MAIL_CREATE_CONFIG to no, in the file /etc/sysconfig/mail to prevent SuSEconfig to report md5sum errors

If freshclam is installed as dependency of kolab, the ownership of the freshclam log file is wrong. The file must be owned by vscan. In case the ownership is not correct (please check), it can be corrected with the following command:

touch /var/log/freshclam.log
chown vscan /var/log/freshclam.log

The amavisd log file and the clamav log file must be created with the right user:

touch /var/log/amavisd
chown vscan /var/log/amavisd
touch /var/log/clamav
chown vscan /var/log/clamav

Make sure that you run freshclam before you start the clamd-daemon, otherwise it'll complain during the next step

freshclam

Bootstrap Kolab

Bootstrap kolab, some errors might be seen during the initial run of kolab_bootstrap. Ignorable errors are:

  • tar: /etc/saslauthd.conf: can not stat
  • mv: can not execute mv on *.pem
  • chown: can not get acces to /var/lib/ldap/*
kolab_bootstrap -b

Create the aliases.db and the postfix indexed maps:

# build the /etc/aliases.db file
newaliases
# build the canonical map
postmap /etc/postfix/canonical
# build the relocated map
postmap /etc/postfix/relocated

It is now possible to start kolab:

rckolab start

Go to the kolab admin webpage (url is shown by kolab_bootstrap) and create a user.

  • Now you should have the domain in the cyrus directory /var/spool/imap/domain
Note: When no users appear in the directory mentioned above, check the file /var/log/messages for errors from cyrus.


If it does not work (see note), check /var/log/messages if you see a line with:

DBERROR db4: /var/lib/imap/mailboxes.db: unexpected file type or format

Stop cyrus:

rccyrus stop

Remove all the files in /var/lib/imap (only the files, not the directories!)

rm $(find /var/lib/imap/ -type f)

Start cyrus

rccyrus start

Now magically all the created users should appear in /var/spool/imap/domain....

  • It should be possible to sent an email to that user, with:
echo $(date) | mailx -s test user@domain.tld
Note: here Clam Antivirus-clamd av-scanner might fail with the error message: Can't connect to UNIX socket /var/lib/clamav/clamd-socket (see /var/log/messages). If this happens stop clamav (rcclamd stop), remove the socket (rm /var/lib/clamav/clamd-socket), restart clamav (rcclamd start). Wait a bit and after some time the socket should appear and clamav will be working fine.


  • Interesting logfiles can be found in /var/log, being: mail, messages, apache2/error_logs etc
  • For more verbose logs increase the loglevel from 2 to 4 in /etc/kolab/kolab.globals

If kolab seems to work, it is now possible to activate all services during system startup:

After this you can enable the involved using yast:

yast -> system -> runlevel editor:
enable the service kolabd.

This will activate many other services as dependencies as well, like: ldap, saslauthd, cyrus, apache2. But the services: spamd, freshclam, clamd and amavis are not activated automatically as in some cases kolab does not need them (when spam and virus scanning are not required). In case you want those services activated you have to do this manually, either with yast or with chkconfig (e.g.):

chkconfig --set amavis

By enabling kolabd, the following message:

Starting kolab groupware inter process daemon

is printed twice. If you don't like that, do not enable kolabd, as kolabd will only start all kolab required services. With the following command:

kolabsrv list

it is possible to check that all required services are active. Use this tool instead of enabling kolabd. If a service is not enabled, enable it with the command:

chkconfig --set <service to activate>


Hint

Add an alias to one of your users, that will accept email from root@domain.tld. In case e.g. cron sents an email notification, the email will arrive at the user that has the alias set for the root.

An even nicer solution is, to have the emails sent to a distribution list e.g. cron@domain.tld. In your cron scripts you should have your emails sent to cron@domain.tld in that case.

Groupware testing

  • Open a browser and point it to:
    • https://servername/freebusy/user@domain.tld.ifb
    • https://servername/freebusy/user@domain.tld.xfb
    • https://servername/freebusy/trigger/user@domain.tld/FOLDER.pfb (replace FOLDER with your Kalendar folder for instance)

All of these urls should show you ical formatted data.

In the urls above user@domain.tld is a user you have created with the kolab web admin interface before.

  • Curl could be used for testing the freebusy components as well (it's ten times faster than doing everything with the preferred browser):
curl -u user@domain.tld:password -k -X GET \
https://servername/freebusy/trigger/user@domain.tld/FOLDER.pfb

Use this freebusy test script to test the freebusy functionality.

Clients

KDE client Configuration

The client configuration, based on KDE's Kontact is described in kolab server 2 and kde client configuration

If the groupware functionality works and Kontact is configured correctly, you should see should be able to see the following picture:

Groupware functionality provided by kolab on openSUSE in korganizer


Webclient

Kolab has it's own modified Horde for webclient to use it install package kolab-webclient

zypper|smart|apt install kolab-webclient

After installing webclient you must run kolabconf -n and add following lines to /etc/crontab file if you want notifications to work

# crontab -u wwwrun -e

and add the following:

#horde alarms
*/5 * * * *     /usr/bin/php5  /srv/www/htdocs/client/scripts/alarms.php
#kronolith reminders
0 2 * * *       /usr/bin/php5  /srv/www/htdocs/client/kronolith/scripts/reminders.php

then you can access it from http://servername/client . Note that servername should be the same as given while running kolab_bootstrap.

If you have problems getting the login from webclient, check the error_log of apache for an php error on the Timezone database. You can fix this by defining your timezone in the value "date.timezone" of the php.ini.

Don't forget to check your calendar!

Don't forget to check your calendar, as shown on the screenshot om the right. If the calendar is not checked it is not displayed. Although you can schedule events succesfully....

Personal Information synchronization

this is untested
 If you want to synchronize e.g. your mobile phone with your information stored in the kolab server you can do this by installing the kolab-z-push package (zyp in kolab-z-push).  This package seems to make this possible...  Additional configuration must be performed, which is described in the kolab wiki.

Backups

During kolab_bootstrap many config files are written to disk. Some of these will overwrite your config files. The config files to be created during kolab_bootstrap, can be determined with:

/etc/kolab/templates # sed -n 's/^.*TARGET=//p' *

For example:
/etc/amavisd.conf
/etc/clamd.conf
/etc/cyrus.conf
/etc/freshclam.conf
/etc/imapd.conf
/etc/kolab/kolab_smtpdpolicy.conf
/etc/openldap/ldap.conf
/etc/postfix/ldapdistlist.cf
/etc/postfix/ldaptransport.cf

The original config files are saved (backed up) to /var/adm/backup/kolab/kolab_backup-orig.tar.bz2 during the first execution of kolab_bootstrap.

Please, let us know if things can be improved. This can be done on the talk page of the wiki page, and on the kolab-devel (at) kolab (dot) org emaillist. In case you use the talk page, inform the packagers with an email to the before mentioned emaillist. Include in the email that it concerns kolab on suse.

Troubleshooting

Package upgrading

  • After upgrading kolab packages, it can happen that an ldap error is reported for the freebusy urls mentioned in the Groupware testing section. This can be resolved by running kolabconf -n as root with all kolab related services active. The latter can be checked by running kolabsrv rc all status.

Postfix doesn't start

If Postfix doesn't start correctly have a look into the /var/log/mail file.

/var/log/mail
postfix/postfix-script: starting the Postfix mail system
postfix/master[numbers]: fatal: bind: public/post-cleanup: Operation not permitted

For 10.1: stop rcapparmor (or add "flags=(complain) to the postfix-profiles) as it prevents postfix to run succesfully:

rcapparmor stop

Disable apparmor permanently using yast:

yast2 -> System -> System service (runlevel) -> export mode -> disable boot.apparmor

Or from the command line:

chkconfig -d boot.apparmor (to disable the service)
chkconfig -s boot.apparmor (to enable the service)

ClamAV (clamd) fails to start

If the clamAV demon (clamd) fails to start than upgrade to the most recent clamav version (0.90). Then try to restart the clamAV demon:

# rcclamd restart

If this fails with:

ERROR: Problem with internal logger. Please check the permissions 
on the /var/log/clamav file.

Than change the settings of the clamav log file to:

/var/log # ls -l clamav
-rw-r----- 1 vscan root 62441 mrt  6 20:18 clamav

php segfault

In a very special case, a php segfault might be seen in /var/log/messages. The details are described in kolab issue 3629. If anybody can help to debug this, that would be great.


openldap (2009-11-28)

(Seen under both suse 11.1 & 11.2)

Openldap will refuse to start if certs located in /etc/kolab are changed/updated or relocated elsewhere. Error is:

rckolab start Starting ldap-serverstartproc: exit status of parent of /usr/lib/openldap/slapd: 1 failed

ERROR: /etc/init.d/ldap start failed Run: kolabsrv rc all stop to stop all services

Even trying to restart it alone with rcldap start|restart doesn't work anymore...

Remember that kolab-related certs located under /etc/kolab should have file group ownership set to "pki", like:

# chgrp pki *.pem

Updating WebClient from Horde Groupware 1.2.0 to 1.2.4 (2009-11-28)

Work nicely under 11.1 with PHP 5.2.11 (NOT 11.2 and php 5.3)

Here is a little Step-By-Step "How-to":

Install Kolab-webclient 1.2.0 through your favorite tool (zypper|apt|yast | else). Check if you're able to log on and if all is working properly (don't waste your time to customize options yet). Then, logoff.

# rckolab stop
# cd /srv/www/htdocs
# mv -R ./client ./client120

Just in case (a bit of recovery planning doesn't hurt) :

# cp -a /srv/www/htdocs/client120 /path/to/somewhere/safe/client120_OK 

Get the latest Horde Groupware archive and horde passwd tool, untar:

# mkdir /local/horde
# cd /local/horde
# wget http://ftp.horde.org/pub/horde-webmail/horde-webmail-1.2.4.tar.gz
# wget http://ftp.horde.org/pub/passwd/passwd-h3-3.1.2.tar.gz
# tar zxvf horde-webmail-1.2.4.tar.gz
# tar zxvf passwd-h3-3.1.2.tar.gz

Now, add passwd to the groupware folder and relocate the resulting stuff under apache2:

# mv ./passwd-h3-3.1.2 ./horde-webmail-1.2.4/passwd
# mv ./horde-webmail-1.2.4 /srv/www/htdocs/client

Create a storage space for horde parameters (starts under ./client like the one found under ./client120, You can move it later when all is done)

# cd /srv/www/htdocs/client
# mkdir ./storage
# touch horde.bd

Adjust files' ownership for apache2 (usually wwwrun:www under suse)

# chown -R wwwrun:www ./client

Just in case (useful indeed...):

# cp -a /srv/www/htdocs/client /path/to/somewhere/safe/client124_OK

Time to upgrade with the nice Horde utility located in ./client/scripts

# cd /srv/www/htdocs/client/scripts
# php setup.php

The utility provides a easy mean to upgrade Horde Groupware, First asking for the web root directory, which is /client (the default) then select option 5 (Update from an older Horde Groupware Webmail Edition version) for some config.

1- The web root repository from which the config should be taken: /srv/www/htdocs/client120
   <Some files copying> 
2- Database Admin username (just leave it blank - it's sqlite)
3- Database Admin password (blank again)
4- Do you want to create the tables (Y/N): Y 
   <tables created>
   <schemas upgraded>

Exit (option 0)

You're good to go. Last step:

# kolabconf
# kolabsrv rc all restart

Just in case (again, if something happens while you're playing with the configs afterwards...):

# cp -a /srv/www/htdocs/client /path/to/somewhere/safe/client124_READY

Enjoy!

Some facts

Normally kolab is installed using packages build with openpkg. The user needs to download just under 200MB of source rpms. These have to be build requiring about 850MB of disk space and quite some time on a not so modern system. On openSUSE one now only needs to download 12 MB of binary rpms, which are installed in just a second even on this not so modern system! Of those 12 MB, about 10 MB is needed for a patched rpm that is normally provided by suse. This rpm is cyrus-imapd that count for roughly 8.5 MB. The patches have been sent upstream but the respective projects are slow to include them. Imagine if those patches would be part of the projects and as such just be part of suse. Only 12 MB (2 in the future?) is needed for kolab on openSUSE, while using openpkg just under 200MB has to be downloaded!

See Also