[Kolab-devel] New with Kolab (Hello all)

[Jonathan Carter]

Hi Bernhard

Bernhard Reiter wrote:
> welcome! 

Thanks!

>> According to the Kolab roadmap[5], version 2.1 is expected to be
>> released in April 2007. We will be implementing the release candidate
>> versions until the final release is ready.
> 
> This is the right approach from my perspective.

Glad you agree, as Stephan says, the best way to get a release candidate 
stable is to actually use it!

>> We're considering a few options to get it into native Debian packages.
> 
> It would be good to have good native Debian packages, but you must understand 
> the effort it will take to put them up to the same quality 
> with Kolab Server/OpenPKG. 

Understood. What we're doing at the moment is doing a OpenPKG 
installation, remove the parts we won't need in our Kolab distribution, 
and then packaging the /kolab system in about 15 packages. Things that 
are removed from /kolab include /RPM, /includes, /info and /local. Then 
we do an rpm -qa to get a list of all the packages, and then use a 
simple for loop to remove all the packages from /kolab and place it in a 
directory for later packaging:

for file in `/kolab/bin/openpkg rpm -ql $1`; do
   echo Moving $file;
   tar --no-recursion -c $file | tar -C /data/kolab-pkg/$1/ -x
done

You have to use tar, since cp and mv doesn't play too nicely with 
recuring directories that are used by multiple packages.

I ran across a problem, where some files remained behind in the /kolab 
system, there was also a problem where some files were apparently 
installed by two different rpm packages (Debian doesn't allow that), so 
I filtered duplicates out of /kolab to prevent later problems.

for directory in `ls -1 /data/kolab-pkg`; do
     for file in `cd /data/kolab-pkg/$directory ; find`; do
         cd /
         rm -f $file;
     done
done

Agter that, I combine a *lot* of the packages, for example, I combine 
the contents of all the perl-* directories to form one perl directory 
that will be packaged, and all the horde- and PEAR- packages were 
combined for a horde package too.

I then ended up with the following packages:

2.2K  impi-kolab-server_2.1-rc1_i386.deb
442K  kolab-amavisd_2.1-rc1_i386.deb
5.9M  kolab-apache_2.1_rc-1_i386.deb
  12M  kolab-clamav_2.1_rc-1_i386.deb
  53M  kolab-core_2.1-rc1_i386.deb
  36M  kolab-cyrus-imapd_2.1-rc1_i386.deb
117K  kolabd_2.1-rc1_i386.deb
  23M  kolab-horde_2.1-rc1_i386.deb
5.9M  kolab-openldap_2.1-rc1_i386.deb
  21M  kolab-perl_2.1-rc1_i386.deb
8.4M  kolab-php_2.1-rc1_i386.deb
  32M  kolab-postfix_2.1-rc1_i386.deb
876K  kolab-proftpd_2.1-rc1_i386.deb
  51K  kolab-resource-handlers_2.1-rc1_i386.deb
2.2M  kolab-sasl_2.1-rc1_i386.deb
692K  kolab-spamassassin_2.1-rc1_i386.deb
204K  kolab-webadmin_2.1-rc1_i386.deb

impi-kolab server is just a meta-package that contains the other 
packages as dependencies, which includes the rc script, and some 
postinst foo that creates the users and sets up the host system. BTW, I 
had to made some changes to the rc script to be LSB compliant:

1. I had to add the following section:

### BEGIN INIT INFO
# Provides:          kolab
# Required-Start:    $syslog
# Required-Stop:     $syslog
# Should-Start:      $local_fs
# Should-Stop:       $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Kolab groupware environment
# Description:       Kolab groupware environment,
#                    customised for Impi Linux.
### END INIT INFO

2. LSB requires you to have a restart and a force-reload option as well, 
so I added:

   restart ) exec /kolab/etc/rc all stop && /etc/rc all start ;;
   force-reload ) exec /kolab/etc/rc all stop && /etc/rc all start ;;

Not sure if there's a better way do to #2, suggestions are welcome, it 
would be nice to get the LSB compliance in upstream Kolab, although it's 
understandable that LSB isn't that important when your system is meant 
to run on just about every Unix system that is currently supported :)

>> We don't really want Kolab in /kolab since it's not FHS'sy[6] place to
>> put it, and upstream would never approve of it either. 
> 
> I think that this is a minor issue, as far as I remember FHS was not made for 
> such situations having another system layer in there. A standard followed
> too strictly become a problem itself as well. :)
> You can place Kolab Server with OpenPKG anywhere, just use a symlink 
> from /kolab to it.

Yes, I moved everything to /usr/lib/kolab, and the postinst script for 
impi-kolab-server simply creates the /kolab symlink, which means that 
the package doesn't have to copy a single file into /. Lintian and Linda 
still points out that a lot of the files in /usr/lib/kolab doesn't 
belong there, if we're really going to get pedantic over FHS compliance, 
we'll have to split the files up and create symlinks, as done with the 
Firefox packages.

>> We're also 
>> considering using the current Debian versions of kolab-cyrus, etc, and
>> simply packaging the newest Kolab specific packages (kolabd,
>> kolab-resource-handlers, kolab-webadmin and kolabadmin), although that
>> comes with its own complications.
> 
> Each package is quite easy to get, but you need to quality control the whole 
> combination. What would be helpful is, if we all create more methods for 
> automated scripting which could test all flavors of Kolab Servers.
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/utils/testing/ has some helpers
> in there, like send_filtertest_emails.py, but this is just a starting point.

Ooh, that will be quite helpful. Ultimately, I would like to see the 
process I have set out above automated, which at this stage seems 
completely doable.

>> From what I've read so far, it seems 
>> that it might be best to use the OpenPKG installation until Debian
>> upstream has created native packages. 
> 
> This is what we recommend as well, I know Benoit likes to have native Debian 
> packages and UGS shows that it can be done, but the effort is not to be 
> underestimated.

Understood.

> Definately, if you find a Kolab Server installation that is not working as it 
> should, you should compare its behaviour to a Kolab Server/OpenPKG first.
> And Kolab Server/OpenPKG is easiest to install and configure from all variant,
> as far as I know. Just two commands. ;)

Oh really? With our young little package we have now, we already do it 
with just one command :p

-Jonathan