Differences between revisions 52 and 54 (spanning 2 versions)
Revision 52 as of 2016-04-10 09:02:07
Size: 7719
Comment:
Revision 54 as of 2016-08-28 10:40:46
Size: 8397
Comment: Move Zarafa parts into Kopano, that's the new name for the suite
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
= Packaging Giraffe = = Packaging Kopano =
Line 4: Line 4:
Giraffe is the free open source variant of the Zarafa Collaboration Platform packaged for Debian. Kopano is the free open source variant of the Kopano Collaboration Platform from Zarafa packaged for Debian.
Kopano is the renamed Zarafa Collaboration Platform (ZCP) by Zarafa B.V. as a consequence started by a complete license change to AGPL started in 2015. Some parts are completely rewritten (like the archiver functions) and got integrated in the Kopano release from scratch.
Line 11: Line 12:
 * Zarafa SCM: https://anonscm.debian.org/cgit/pkg-giraffe/giraffe.git
 * Zarafa-!WebApp SCM: https://anonscm.debian.org/cgit/pkg-giraffe/zarafa-webapp.git
 * Kopano SCM: https://anonscm.debian.org/cgit/pkg-giraffe/giraffe.git
 * Kopano-!WebApp SCM: https://anonscm.debian.org/cgit/pkg-giraffe/zarafa-webapp.git
Line 15: Line 16:
 * Upstream: https://community.zarafa.com/
 * Upstream Source: https://download.zarafa.com/community/
 * Upstream: https://kopano.com/
 * Upstream Source: https://stash.kopano.io/projects/KC https://download.kopano.io/community/
Line 19: Line 20:
The packages of Zarafa (server) where uploaded for a first time to experimental NEW, but the package was rejected by the ftpmasters due small issues in debian/copyright. zarafa-webapp isn't finally packaged and not available by the Debian repositories, the packaging process is mostly finished, but a upload makes no sense without the Zarafa main packages. There was a first attempt for getting the Zarafa suite into Debian, the packages of Zarafa (the core server components) where uploaded for a first time to experimental NEW, but the package was rejected by the ftpmasters due small issues in debian/copyright. The according zarafa-webapp wasn't finally packaged and is not available by the Debian repositories, the packaging process is mostly finished, but a upload was making no sense without the Zarafa main packages. So now the same state is true for the kopano-webapp now.
Line 25: Line 26:
=== zarafa-server, ... === === kopano-server, kopano-utils, kopano-dagent, ... ===
Line 30: Line 31:
 * Move dlopen'ed libs to private directory
 * To be re done with version 7.2.x
Line 34: Line 33:
 * fix init script  * test and fix init scripts
Line 38: Line 37:
 * systemd unit file (partially done)  * systemd unit files (partially done)
Line 41: Line 40:
 * logrotate (upstream available in installer/linux/zarafa.logrotate, put in zarafa-common, split it per package)  * logrotate (upstream available in installer/linux/kopano.logrotate, put in zarafa-common, split it per package)
Line 44: Line 43:
 * do not run as UID 0 (problematic for zarafa-search, otherwise it is configurable in the config files)
 * zarafa-common: kill it with fire, no useful parts
 * Adding mechanism to not conflict with packages from upstream 
 * do not run as UID 0 (problematic for kopano-search, otherwise it is configurable in the config files and done in the debian packages)
 * kopano-common: kill it with fire, no useful parts, still true?
 * Adding mechanism to not conflict with packages from upstream
 * Autopkgtests
  * gateway IMAP / POP3 (JellevanderWaa has a branch with gateway tests on his Github https://github.com/jelly/giraffe )
  * Caldav (kopano-ical)

Further possible improvements:
 * Tweak default SSL settings in gateway.cfg and server.cfg
 * Add some security features to systemd service files (!PrivateTmp=True, etc.)
Line 49: Line 55:
 * (./) import upstream version 7.2.0
 * (./) switch to debhelper
 * (./) import upstream version 8.0.1
 * (./) switch to debhelper 9
Line 55: Line 61:
 * zarafa-client:
     * (./) Rename zarafa-client to libzarafa-client0 since it contains no client programs
     * (./) make libzarafaclient a proper versioned shared lib (or a private one)
 * kopano-client:
     * Rename zarafa-client to libzarafa-client0 since it contains no client programs ??
     * make libkcclient a proper versioned shared lib (it's currently a private one) ??
Line 59: Line 65:
 * (./) Remove embedded copies of fckeditor via the dfsg-clean branch in git, (use DebPkg:fckeditor package) (webaccess is not packaged anymore)

Packaging Kopano

Kopano is the free open source variant of the Kopano Collaboration Platform from Zarafa packaged for Debian. Kopano is the renamed Zarafa Collaboration Platform (ZCP) by Zarafa B.V. as a consequence started by a complete license change to AGPL started in 2015. Some parts are completely rewritten (like the archiver functions) and got integrated in the Kopano release from scratch.

Resources

Current State

There was a first attempt for getting the Zarafa suite into Debian, the packages of Zarafa (the core server components) where uploaded for a first time to experimental NEW, but the package was rejected by the ftpmasters due small issues in debian/copyright. The according zarafa-webapp wasn't finally packaged and is not available by the Debian repositories, the packaging process is mostly finished, but a upload was making no sense without the Zarafa main packages. So now the same state is true for the kopano-webapp now.

libvmime

kopano-server, kopano-utils, kopano-dagent, ...

ToDo

  • Check place of the database while install (local or remote) -> Debconf

  • Fix Lintian errors and warnings
  • Review and forward patches against libical (and libvmime, see above) on upstream. For now it seems we can run with the versions of the revitalized package.

  • Test full functionality
    • We'd need some Outlook users here, too...
  • test and fix init scripts
    • systemd compatibility
    • error out when database is missing
    • often hangs on stop
  • systemd unit files (partially done)
  • MTA integration
  • check package descriptions
  • logrotate (upstream available in installer/linux/kopano.logrotate, put in zarafa-common, split it per package)
  • check pre-/postinstall scripts: they do no error handling, don't include debhelper snippets
  • z-push upstream update
  • do not run as UID 0 (problematic for kopano-search, otherwise it is configurable in the config files and done in the debian packages)
  • kopano-common: kill it with fire, no useful parts, still true?
  • Adding mechanism to not conflict with packages from upstream
  • Autopkgtests

Further possible improvements:

  • Tweak default SSL settings in gateway.cfg and server.cfg
  • Add some security features to systemd service files (PrivateTmp=True, etc.)

Done

  • (./) import upstream version 8.0.1

  • (./) switch to debhelper 9

  • (./) Use dbconfig-common/Debconf to generate the initial configuration

    • database name
    • database user
    • database login
  • kopano-client:
    • Rename zarafa-client to libzarafa-client0 since it contains no client programs ??
    • make libkcclient a proper versioned shared lib (it's currently a private one) ??
  • (./) Adding some basic autopkgtests

WebApp

ToDo

  • Support more web server configurations (currently only Apache2)
  • Lintian is complaining about
    • tinymce (TinyMCE currently overridden as Debian version is to old)

  • Adding mechanism to not conflict with packages from upstream

Done

The origin of this list is provided by GuidoGünther in https://honk.sigxcpu.org/piki/agx/publications/2011-06-debian-groupware-zs.pdf.

There was also a talk given on the Zarafa Tour 2015 in Hannover (in german)Talk-Hannover-ZarafaTour2015.pdf.

Using KVM for testing

You probably wont use your current system to test the zarafa packages and that's a good idea so far. KVM is a good alternative for testing because it's supporting snapshot mechanism for easy using and resetting of installations.

Installing needed KVM components

Installation is easy as it's simply a one liner.

$ sudo apt-get install qemu-kvm libvirt-bin bridge-utils virt-manager virtinst

Further preparations

After this ensure you are a member of the group 'libvirt'

$ sudo usermod -aG libvirt [YOUR_USERNAME]

The virtual network adapter inside the libvirt environment is disabled per default so before to continue start it.

$ virsh -c qemu:///system net-autostart default
$ virsh -c qemu:///system net-start default

The next calls maybe not really needed, but on the other hand it's no problem if the storage pools already up, so just to throw possible issues away.

$ virsh -c qemu:///system pool-start default
$ virsh -c qemu:///system pool-start boot-scratch

Installation of a virtual image

After the finishing of the preparation from above you can install a first image. The installation can be as known done fully automated by a preseed file, Guido has prepared file preseed.cfg. Download the file for example to the 'Downloads' folder within your home directory.

$ wget -P $HOME/Downloads http://honk.sigxcpu.org/projects/libvirt/preseed/preseed.cfg

Next you can set up a install, for example based on the Jessie release amd64 and named unstable-amd64-zarafa.

$ RELEASE=unstable
$ NAME=zarafa
$ DIST=amd64
$ virt-install --connect=qemu:///system \
               --location="http://ftp.us.debian.org/debian/dists/$RELEASE/main/installer-$DIST" \
               --initrd-inject=$HOME/Downloads/preseed.cfg \
               --extra-args="auto" \
               --name $RELEASE-$DIST-$NAME --ram=512 \
               --disk=pool=default,size=10,format=qcow2,bus=virtio

This will install a image named 'unstable-amd64-zarafa.qcow2' with a size of 10GB under /var/lib/libvirt/images/. After the install the image will boot automatically.

Usage of KVM images

to fill out

pkg-giraffe package repository

Using packages from Alioth

Packages are available at https://pkg-giraffe.alioth.debian.org/packages/ These can be included into sources.list, for sid on AMD64 for example, via

deb http://pkg-giraffe.alioth.debian.org/packages sid/amd64/
deb http://pkg-giraffe.alioth.debian.org/packages sid/all/

Releases are signed with GPG key AF90BD8F which can be added to a system as trusted key using apt-key

Uploading packages to Alioth

In order to upload packages to the repo on Alioth you need to be member of the pkg-giraffe group and have Alioth ssh access set up. Uploads can be done via dput using the following configuration:

[pkg-giraffe]
fqdn = alioth.debian.org
incoming = /home/groups/pkg-giraffe/htdocs/packages/mini-dinstall/incoming
method = scp
allow_unsigned_uploads = 0
post_upload_command = ssh alioth "mini-dinstall -b -c /home/groups/pkg-giraffe/.mini-dinstall.conf"

As signed uploads are needed, your key needs to be in the keyring file "pkg-giraffe-keyring.gpg" on Alioth.