Adjusting virt-install instruction after name change to kopano
Use FQDN on ssh command
|Deletions are marked like this.||Additions are marked like this.|
|Line 168:||Line 168:|
|post_upload_command = ssh alioth "mini-dinstall -b -c /home/groups/pkg-giraffe/.mini-dinstall.conf"||post_upload_command = ssh alioth.debian.org "mini-dinstall -b -c /home/groups/pkg-giraffe/.mini-dinstall.conf"|
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.
- Current State
- Using KVM for testing
- pkg-giraffe package repository
Alioth Project: https://alioth.debian.org/projects/pkg-giraffe/
Kopano-WebApp SCM: https://anonscm.debian.org/cgit/pkg-giraffe/zarafa-webapp.git
Mailing List (Discussing): https://lists.alioth.debian.org/mailman/listinfo/pkg-giraffe-discuss
Mailing List (Maintaining/Packaging): https://lists.alioth.debian.org/pipermail/pkg-giraffe-maintainers
Upstream Documentation: https://documentation.kopano.io/
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.
repackage done libvmime
kopano-server, kopano-utils, kopano-dagent, ...
Check place of the database while install (local or remote) -> Debconf
- Fix Lintian errors and warnings
- 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
Further possible improvements:
- Tweak default SSL settings in gateway.cfg and server.cfg
Add some security features to systemd service files (PrivateTmp=True, etc.)
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
- 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
- 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
Basic packaging, Alioth git repo: https://anonscm.debian.org/cgit/pkg-giraffe/zarafa-webapp.git/
- Lintian was complaining about
Default website is available via https, http is redirected to https (This requires finally a valid vhost!)
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
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 done 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 unstable release amd64 and named unstable-amd64-kopano.
$ RELEASE=unstable $ NAME=kopano $ 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-kopano.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 by the following command:
wget -O - https://pkg-giraffe.alioth.debian.org/EDC3775DAF90BD8F.asc | sudo apt-key add -
To delete the key in the local key store run:
sudo apt-key del 0xEDC3775DAF90BD8F
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.debian.org "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.