[pkg-kolab] Kolab debian repositories

[Paul Boddie]

On Thursday 20. March 2014 19.48.39 Diane Trout wrote:
> > Yes, the repositories are just revised packaging for the packages I had
> > to (or chose to) change and then rebuild. For the other packages I used
> > the OBS files and rebuilt using pbuilder. For reference, here are my
> > repositories of packaging files:
> Thank you for the pointers to all the repositories.

No problem. Particularly the kolab packaging is an experiment, but it does 
provide a indication of how things like Dovecot and the XMPP-based components 
would be integrated into the package hierarchy.

> > Nice! Especially the last bit with Dovecot and PostgreSQL. It would be
> > interesting to hear of how you did that so that we might broaden the
> > options for setting up Kolab. I can configure Dovecot to function as an
> > IMAP server, but I haven't been able to really test it with Kolab or to
> > integrate it properly.
> 
> For this round of experimenting I started with the kolab from source
> instructions. (http://docs.kolab.org/howtos/build-kolab-from-source.html).
> My current goal is to get the webdav sync working.
> 
> I'm not sure how useful the following story is, but I'll go ahead and share
> it for completeness.
> 
> First I set up roundcube using their instructions for working with
> Postgres. Dovecot just worked. Getting to viewing email was pretty easy.

Right. So, Roundcube on PostgreSQL is an established configuration, then. 
That's potentially very reassuring because it means that some kind of 
equivalent to the MySQL-related stuff in the setup-kolab Roundcube component 
could be developed. Since I'm more comfortable with PostgreSQL, I can see 
myself doing that, and I guess the relevant instructions are found here:

http://trac.roundcube.net/browser/github/INSTALL

I saw that you'd posted a patch to the development list, so I'll take a look 
at that, too.

> Next I added in the roundcube-kolab-plugins and tried to get enough of the
> plug-ins working to show calendaring information. First I tried using the
> php- kolabformant and php-kolab from the debian repositories, but those
> were too old and I had to use the obs versions. Then I had issues with
> needing the IMAP metadata extension and I had to upgrade to dovecot 2.2.10
> from unstable.

The Kolab storage formats are now xCalendar-based rather than iCalendar-based, 
as far as I understand the main difference between 2.x and 3.x, so the old 
Debian packages probably won't work. Meanwhile, I brought in the dovecot-
metadata-plugin package from Ubuntu since it doesn't seem to be in Debian.

> Once all of that was updated and I had to manually configure the
> subscriptions to the calendaring/contact folders in round cube and I used
> the manage folder ui to set what type of data was being stored in each
> folder type.
> 
> Once that was set I was able to see contacts and calendar entries created
> with kontact.
> 
> Up to this point I had avoided setting up an ldap server by commenting out
> kolab_auth.
> 
> Next I tried to set up chwala, using the readme in its source tree and
> discovered that does need an ldap server.
> 
> I setup openldap and copied over some minimal ldap records from a system
> setup with kolab 3.1.

Setting up Kolab for OpenLDAP would also be interesting. The setup-kolab LDAP 
component does stuff with 389-ds specifically, but I guess that the instance 
initialisation process could be automated for OpenLDAP, too, and then the 
schema population process would be very similar.

> For the moment in kolab_auth I changed the kolab_auth_filter from
> objectClass kolabInetOrgPerson to inetOrgPerson as I didn't want to deal
> with needing to convert the schema holding the kolabInetOrgPerson.

Someone on IRC was wanting to know if Kolab could use a less Kolab-specific 
schema. I imagine you would be able to say more about that than I could.

> Once I had those changes I was able to log in to chwala and upload a file.
> Though the files plugin in roundcube still isn't working yet.

I've approached all this from the opposite direction, taking the full system 
with LDAP and everything and then trying to get it all functioning. Chwala was 
one thing I did actually try and did indeed get to work the other week, and it 
became possible to use Roundcube to upload files, so there might be a fix that 
made this work for me. Maybe it's this one:

http://git.kolab.org/kolab-
chwala/commit/?id=e112f1c2b390e06e4d804c5958bfa24db733c475

> Then I tried to setup iRony, and although I made some progress my mess of
> multiple git checkouts and symlinks splicing together plugins and plugin
> configuration files is getting too confusing to extend.
> 
> At this point I'm probably going to step back and try again using your
> packages for roundcube, roundcube kolab plugins, chwala and irony.

One thing that I probably mentioned in my original mail about packages in 
December was that the pykolab code in my packages is a fork of the upstream 
code with my own changes, some added breakage (see below), a lot of 
refactoring, but also a degree of improvement.

The breakage is hopefully minimal, but since I haven't heard anything from 
anyone and I know that I managed to break something that the Postfix 
validators need - I didn't know anything about such things at the start of 
this week ;-) - I guess no-one else has looked at these packages until now. 
(The Postfix stuff should now function, by the way.)

> > P.S. Yesterday, I discovered that we might need to work on the Postfix
> > integration, given that it didn't seem to be set up for secure
> > communication, thus preventing the sending of mail. Again, advice from
> > more experienced packagers and mail admins is very welcome.
> 
> I will try to share whatever progress I can make. My current observation is
> manual configuration is a better choice than setup-kolab if you're trying
> to use kolab components far outside their expected environment.

My aim is to make setup-kolab completely functional and to integrate it into 
the Debian package configuration mechanisms, as described here:

http://blogs.fsfe.org/pboddie/?p=623

Some of my pykolab work has involved getting rid of the "start from scratch" 
approach that is largely incompatible with Debian, and the intention is that 
setup-kolab can be run over and over again without it wanting to overwrite 
things, ask for passwords you don't know or don't want to keep typing, and so 
on.

If it doesn't manage to live up to that ambition, I regard it as something to 
be fixed. There really shouldn't be any need to perform manual configuration 
when there's something like setup-kolab around. Maybe I just have unrealistic 
goals, but you have to aim high to achieve great things, I think. :-)

Paul