User:Aeneas jaissle/SDB:Kolab 2

Jump to: navigation, search
Icon-warning.png
Warning: Most of this page is about Kolab 2, which is deprecated. More information is available at features.opensuse.org/307846 and kolab.org as well as docs.kolab.org. Kolab upstream is very willing to help packagers with Kolab 3.
Icon-warning.png
Warning: Due to time restraints Kolab was no longer built and supported on openSUSE. If you want to obtain information about building and maintaining Kolab on openSUSE, contact the retired packager (for the email address see the changelog in the kolab package: rpm -q --changelog kolab).
Packagers are currently working on building Kolab 3.x for openSUSE.

Introduction

All packages will be 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 server:Kolab:UNSTABLE repository are based on code from Kolab git. 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!

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

To install Kolab, you need to add two of the following repositories to your package installer, one of them being Kolab:Extra:

  • Kolab:STABLE: Stable and tested packages. Currently no stable packages are available, so don't use it.
  • Kolab:UNSTABLE The packages in this project are continuously build and changed, so the repository is bit unstable at times.
  • Kolab:UPSTREAM The packages in this project are build from upstream sources (fetched from git) without further changes or tests, so this project might not work out-of-the-box
  • Kolab:Extra This repository hosts additional packages needed by Kolab 3.x.

Here you can find other examples on how to add a repository.

Version: 12.2


Version: 12.3


Version: Factory


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

# zypper|smart|apt install kolab

Packages

Package Version Summary
java-libkolabxml0 0.8.3 Java bindings for libkolabxml
kolab 3.0.0 Kolab Groupware Server (meta package)
kolab-cli 0.5.11 Kolab 3 CLI utilities
kolab-conf 3.0 Kolab Groupware Configuration Utility packages (meta package)
kolab-imap 3.0 Kolab Groupware IMAP component (meta package)
kolab-ldap 3.0 Kolab Groupware LDAP components (meta package)
kolab-mta 3.0 xx
kolab-saslauthd 0.5.11 Kolab SASL Authentication Daemon
kolab-schema 3.0 xx
kolab-server 0.5.11 Kolab 3 Server implemented in Python
kolab-syncroton 2.1-rc xx
kolab-utils 3.0 xx
kolab-webadmin 3.0.3 xx
kolab-webclient 3.0 xx
libcalendaring 4.9.0 xx
libkolab0 0.4.1 xx
libkolabxml0 0.8.3 xx
mono-libkolabxml0 0.8.3 Mono bindings for libkolabxml
php-libkolab0 0.4.3 PHP bindings for libkolab
php-libkolabxml0 0.8.3 PHP bindings for libkolabxml
python-libkolab0 0.4.1 Python bindings for libkolab
python-libkolabxml0 0.8.3 Python bindings for libkolabxml
postfix-kolab 0.5.11 xx
pykolab 0.5.11 xx
pykolab-telemetry 0.5.11 xx
pykolab-xml 0.5.11 xx
roundcubemail-plugins-kolab 3.0 xx
wallace 0.5.11 xx


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
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
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. 

#!/bin/bash
# See: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/architecture/freebusy.txt

# The server that runs the kolab server
SERVER=yourserver
# The user and password that logins to the kolab server (user@domain.tld)
LOGIN_USER=youruser
PASSWORD=youruser_password

# The user for whom the Free Busy information is requested
FB_USER=

if [[ -z "$PASSWORD" ]]; then
  echo "error: password is required" >&2
  exit 1
else
 _PASSWORD=:$PASSWORD
fi

_LOGIN_USER=$(echo $LOGIN_USER | sed 's/@/%40/')
[[ -z "$FB_USER" ]] && FB_USER=$_LOGIN_USER

HTTP=yes
if [[ "$HTTP" == "yes" ]]; then
  PROTOCOLS="http https"
else
  PROTOCOLS="https"
fi

for PROT in $PROTOCOLS; do

  echo === $PROT ifb ===
  curl -k $PROT://${_LOGIN_USER}${_PASSWORD}@$SERVER/freebusy/$FB_USER.ifb
  echo

  echo === $PROT xfb ===
  curl -k $PROT://${_LOGIN_USER}${_PASSWORD}@$SERVER/freebusy/$FB_USER.xfb
  echo

  echo === $PROT pfb with trigger ===
  curl -k $PROT://${_LOGIN_USER}${_PASSWORD}@$SERVER/freebusy/trigger/$FB_USER/Calendar.pfb
  echo

  echo === $PROT pfb ===
  curl -k $PROT://${_LOGIN_USER}${_PASSWORD}@$SERVER/freebusy/$FB_USER/Calendar.pfb
  echo

  echo === $PROT pxfb ===
  curl -k $PROT://${_LOGIN_USER}${_PASSWORD}@$SERVER/freebusy/$FB_USER/Calendar.pxfb
  echo
done


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 2.x 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 prior to 3.x 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

Retrieved from "https://en.opensuse.org/index.php?title=User:Aeneas_jaissle/SDB:Kolab_2&oldid=60270"