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 attachment 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.
Please reopen if this is still relevant.
