Bugzilla Bug 96732

This is intended to track the various bugs necessary to make Kolab2 work
natively in Gentoo.

See bug #25485  

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

I'll test as soon as you release the ebuild. 
 
Thanks! 

I noticed your bugs for USE flags for kolab for various packages (bugs 96734
96728 for example) and I think that this approach won't really work. The
reasoning being that doing it that way (a way I considered) means that the
maintainer has to support each patchset against each version of each of the sub
packages. It's just infeasible. What is probably the best way of doing this is
making kolab2 one big package and blocking the other packages in portage that
usually provide that functionality. I am writing some ebuilds now based along
that concept.

I basically followed the suggestion made in bug #25485. The kolab use flag
would
only apply to two packages: cyrus-imapd (bug #96728) and mod_auth_ldap (bug
#96734). All other kolab patches (e.g. amavis, postfix) have been integrated
upstream and are available through the standard packages in portage. 

I don't think the single patch for mod_auth_ldap will be much of a burden.
Cyrus-Imapd is a different thing since Kolab uses several patches for this
package. The Kolab devs still try to get the patches integrated upstream. But
it
might be better to add a special kolab-cyrus-imapd package. I guess this
depends
on the cyrus-imapd maintainer.

Using a large, single Kolab ebuild that blocks other packages providing
services
like LDAP, HTTP, FTP etc. would not really provide much benefit over the
current
situation with OpenPKG. I believe that Kolab integrated into Gentoo should use
the standard packages as much as possible instead of blocking them.

The source code of Kolab is also nicely split up into four different packages
which can each be represented by a single ebuild. 

I was unaware that most of the patches for all the components had been accepted
upstream, that does change the feasibility of using a USE flag for kolab. I will
investigate precisely what patches do remain and what would need to be supported
on an ongoing basis and make a call from there. 
Re the kolab-cyrus-imapd, thats more of a question for the kolab dev's as I
seriously doubt any of us have the time to keep the patchset current against
cyrus as it rev's fairly frequently. On the other hand its not a problem if the
kolab dev's keep their patchset up todate as well. I was under the impression
that they probably wouldn't be doing that though as they used openpkg for
precisely that reason.
Re large blocking ebuild, I agree its not elegant and it wasn't my preferred way
of doing it either, but I didn't see any other choice given the amount of work
involved and keeping patchsets up to date against so many packages. Still it do
one thing, it gave kolab on gentoo :)

Perl-Kolab ebuild added.

Kolabd ebuild added.

Added the kolab-webadmin and kolab-resource-handlers ebuilds.

I added all six ebuilds necessary for kolab2. Do not expect to get a working
kolab server yet. Currently the ebuilds should simply install without
complaining - if they don't, I screwed up ;) 

---

You can download an overlay here:
http://www.gunnarwrobel.de/downloads/kolab-overlay.tar.bz2

Once you installed the ebuilds you can run /etc/kolab/kolab_bootstrap -b

Do not do this if you have a system that runs any of the services that are part
of kolab. Their config files will be overwritten. 

There are probably a few manual fixes necessary after running the script. See
bug #96815 for details.

If you are really lucky you can then run /etc/init.d/kolabd and all servers come
up with [OK]. This is unlikely though ;) Simply post any problems here...

----

Do you think the kolab_bootstrap script does an acceptable job of configuring
all the server elements of kolab? What kind of fixes on the way kolab is
configured are needed in order to make this an acceptable Gentoo ebuild?

The kolabd ebuild should now check for the necessary use flags on the packages
kolabd depends on.

Created an attachment (id=62132) [details]
Config file for gensync

Fixed missing patches in my tar packages.

Set up rsyncd so you can use gensync.

Thanks for your note Ian!

Short progress report:

Most patches for the perl-kolab code have been integrated upstream. I added the
fixed ebuild (and the remaining three patches).

I fixed the ebuild for cyrus-imapd (incorrect patching) and the config template
for cyrus-imapd. 

I updated the packages and ebuilds on my site as well as the rsync directory.

At the moment you need to perform five steps after installation:

gpasswd -a ldap kolab-r
gpasswd -a cyrus kolab-r
/etc/kolab/kolab_bootstrap -b
chown -R ldap\: /var/lib/openldap-data
/etc/init.d/kolab start

Cyrus-imapd seems to work and you should be able to add users using the webadmin
interface at http://localhost/admin

I verified that thunderbird can connect to the cyrus server and that the mailbox
is accessible.

Currently there are still problems with postfix so sending or receiving mail
might be a problem but I hope to fix that this weekend.

Progress:

Changed template configuration handling on perl-kolab.

Split package kolab-resource-handlers in kolab-resmgr (bug #99930) and
kolab-freebusy (bug #99931).

Fixed kolabd to depend on these packages.

With the new kolab-resmgr package postfix should be working now. I have been
able to create users on my installation and send/receive mails. 

Free/Busy does not work yet. I am working on that.

There are still some bugs in the bootstrapping script and you need to fix the
ownership of /var/lib/openldap-data after bootstrapping. I added some
troubleshooting notes to my webpages.

Gensync is still the method of choice to get all necessary packages. I do not
version the ebuilds yet so if you have old source packages you need to remove
them before installing. The digest will not match.

I still consider it alpha but it should move to beta in two weeks at the latest.

I restarted the project about two months ago and got it to a working state now. 
I did set up an overlay at 

http://projects.gunnarwrobel.de/kolab

You'll find installation instructions there.

It is still alpha stage and I expect it to have a number of bugs. But as far as
I can tell it should be possible to get the basic features up and running
(managing users, sending/receiving mails). I'd be happy about bug reports :)

I don't know if this will go into the main portage tree any time soon. At the
moment the overlay should be a good solution. Currently the ebuilds is still
based on the kolab cvs sources which leads to frequent updates.  I'll try to
fork a stable overlay once kolab-2.1 is released. 

Just a short note that the free/busy part is working now. So all features you
would expect from the standard kolab server should now also be available on
Gentoo.

All the depends are marked as wontfix - this usually means the tracker gets
closed. What is up with this one?

When will kolab get into portage?

The initial plan was to move the kolab project into portage once the stable 2.1
version of kolab would be available. This release was initially announced to
happen at the end of last year. At that point I was no dev myself and since the
release seemed imminent I added the ebuilds to bugzilla. But 2.1 is still
unavailable and the last announcement was for august this year.

As a consequence all ebuilds from the kolab overlay are still purely CVS based
which I consider a poor working model. The kolab code still has some important
bugs. I marked the dependent bugs as 'wontfix' at some point because it made no
sense to update them month after month in sync with the overlay.

I feel it makes sense to keep the tracker bug open so that people interested in
kolab find the current project site at http://projects.pardus.de/kolab and can
start using kolab on gentoo if they don't mind a few bugs.

So I would expect no movement toward portage before 2.1 comes out. To be honest
I do like the overlay method very much by now so that I do not feel a strong
urge to push kolab into portage. But I guess that can be discussed once there
is a stable version. 

Gunnar, have you taken care of this one:

CVE-2007-4510 [1]:
  ClamAV before 0.91.2, as used in Kolab Server 2.0 through 2.2beta1
  and other products, allows remote attackers to cause a denial of
  service (application crash) via (1) a crafted RTF file, which
  triggers a NULL dereference in the cli_scanrtf function in
  libclamav/rtf.c; or (2) a crafted HTML document with a data: URI,
  which triggers a NULL dereference in the cli_html_normalise function
  in libclamav/htmlnorm.c.  NOTE: some of these details are obtained
  from third party information.

Kolab is not mentioned here exactly, but if Kolab ships a copy of it, you might
 want to consider this, too:

CVE-2007-4560 [2]:
  clamav-milter in ClamAV before 0.91.2, when run in black hole mode,
  allows remote attackers to execute arbitrary commands via shell
  metacharacters that are used in a certain popen call, involving the
  "recipient field of sendmail."

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4510
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4560

@robert: the Kolab2/Gentoo version uses the plain clamav package from Gentoo.
So this is clamav-0.91.2 at the moment. The main Kolab version (that I like to
call Kolab2/OpenPKG) is based on the OpenPKG distribution and if you install
this type of server you are expected to listen to the Kolab security
announcements.

If you run Kolab2/Gentoo on the other hand you are expected to listen to our
GLSA's :)

Ok finally this moves again and I'm trying to get it into Portage now. This
will at first rely on acceptance of the Kolab patches in the cyrus-imapd
package:

see bug #194361

Any progress on this? I see Kolab 2.2 was released in July.