Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 25485 - Req: ebuild for kolab server
Summary: Req: ebuild for kolab server
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Net-Mail Packages
Keywords: EBUILD
: 55774 (view as bug list)
Depends on: 55537
  Show dependency tree
Reported: 2003-07-29 01:11 UTC by Christian Parpart (RETIRED)
Modified: 2005-12-25 13:28 UTC (History)
21 users (show)

See Also:
Package list:
Runtime testing required: ---

kolab-1.0.20.ebuild (kolab-1.0.20.ebuild,4.73 KB, text/plain)
2004-07-03 04:22 UTC, Andreas Pokorny
41_mod_ssl.default-vhost.conf.template (41_mod_ssl.default-vhost.conf.template,8.36 KB, text/plain)
2004-07-03 04:23 UTC, Andreas Pokorny
kolab-1.0.20-conf.d (kolab-1.0.20-conf.d,1.96 KB, text/plain)
2004-07-03 04:25 UTC, Andreas Pokorny
kolab-1.0.20-init.d (kolab-1.0.20-init.d,5.42 KB, text/plain)
2004-07-03 04:25 UTC, Andreas Pokorny
kolab-1.0.20-root_dir.patch (kolab-1.0.20-root_dir.patch,44.61 KB, patch)
2004-07-03 04:26 UTC, Andreas Pokorny
Details | Diff
kolab-1.0.20.ebuild (kolab-1.0.20.ebuild,4.63 KB, text/plain)
2004-07-03 11:16 UTC, Andreas Pokorny
kolab-1.0.20.ebuild (kolab-1.0.20.ebuild,4.78 KB, text/plain)
2004-07-03 12:13 UTC, Andreas Pokorny
kolab-1.0.20-root_dir.patch (kolab-1.0.20-root_dir.patch,44.49 KB, patch)
2004-07-03 12:14 UTC, Andreas Pokorny
Details | Diff
kolab-1.0.20.ebuild (kolab-1.0.20.ebuild,6.25 KB, text/plain)
2004-07-04 01:48 UTC, Andreas Pokorny
kolab-1.0.20-init.d (kolab-1.0.20-init.d,962 bytes, text/plain)
2004-07-04 01:50 UTC, Andreas Pokorny
kolab-1.0.20-root_dir.patch (kolab-1.0.20-root_dir.patch,45.06 KB, patch)
2004-07-04 01:53 UTC, Andreas Pokorny
Details | Diff
kolab-1.0.20.ebuild (kolab-1.0.20.ebuild,6.28 KB, text/plain)
2004-07-09 14:46 UTC, Andreas Pokorny
kolab-1.0.20-root_dir.patch (kolab-1.0.20-root_dir.patch,39.43 KB, patch)
2004-07-09 14:52 UTC, Andreas Pokorny
Details | Diff
kolab-1.0.20.ebuild (kolab-1.0.20.ebuild,6.31 KB, text/plain)
2004-07-22 12:11 UTC, Juha Luotio

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Parpart (RETIRED) gentoo-dev 2003-07-29 01:11:04 UTC
having kolab running on gentoo linux would be very very nice. 
also this should integrate in already running postfix servers somehow, 
I mean, it shall depend on >=net-mail/postfix-x.y e.g. 
Comment 1 Tiago Freire 2003-07-31 11:39:43 UTC
Yes, this would be very good. I am waiting for an opportunity to give it a try. But the clients need ebuilds also, at least until KDE 3.2 comes out...
Comment 2 Arnaud Burlet 2003-08-01 09:43:42 UTC
BTW, ebuild for the client (kde-pim fork until kde 3.2 is released) is available at : 
As it is a kind of "pre-3.2" this ebuild replaces your old kdepim and kdenetwork ... 
Only ebuilds for the server are missing on gentoo, too bad 
Comment 3 Brian Jackson (RETIRED) gentoo-dev 2003-08-03 14:35:26 UTC
If somebody writes an ebuild for it, I'll check it and commit it. I'm not writing it though. Kolab suffers from the same problems that opengroupware does, it's too distro centric, and the installation is unnecessarily complex. IMO, not worthy of being released as a 1.0.0 product yet.
Comment 4 Stuart Herbert (RETIRED) gentoo-dev 2003-10-04 04:46:00 UTC

Kolab isn't a web-application - it's a KDE-centric mail server solution.
 Please re-assign.

Comment 5 Christian Parpart (RETIRED) gentoo-dev 2004-04-25 09:49:03 UTC

noone intereseted in having gentoo serving kolab clients?

Comment 6 Caleb Tennis (RETIRED) gentoo-dev 2004-04-25 16:27:33 UTC
yo - someone going to write up an ebuild?
Comment 7 Christian Parpart (RETIRED) gentoo-dev 2004-04-30 08:05:38 UTC
you are funny....

I am now waiting for someone who *can* do this for countless months...

it seems, that we both are the only one, who want kolab running on gentoo :(
Comment 8 Rene Androsch 2004-05-20 13:32:38 UTC
Hm, maybe I should try opengroupware, until there is a Kolab ebuild....
Comment 9 Caleb Tennis (RETIRED) gentoo-dev 2004-05-20 13:54:42 UTC
It's just waiting for someone to write an ebuild.  The lack of one thus far makes me think nobody must use the product.
Comment 10 Rene Androsch 2004-05-20 14:03:08 UTC
Me too.
So far, there is no easy way to install a kolab server.
KDE 3.2.2 is released, but officially the support for kolab server is not enabled!

So the KDE developers still have some work to do...

I personally think, that I either go for Opengroupware, or hope the Novell's GroupWise will be easy to install on non-suse and non-redhat systems and use this (since for about 5 users you get the license for free from them...)
Comment 11 Aaron Peterson 2004-06-18 21:16:15 UTC
I heard that mandrake has a version with kolab...

aperantly installing kolab isn't as easy as make, make install :(

but it might be...
and if it is, then there should be an ebuild by a week from now.

common kde 3.3...

I installed an alpha build just to try to get kolab...
Comment 12 Andreas Pokorny 2004-07-03 04:22:53 UTC
Created attachment 34698 [details]

I tried instlling kolab using the openpkg script, but it failed because of some
rpm problems, so i started working on an
ebuild( In the current state the
ebuild fetches the kloab-rpm, which consists of the kolab server script, the
conifg templates and the php admin frontend. The ebuild has to patch several
files, because i chose not to use the /kolab/ prefix. 
The /etc/kolab/kolab_boostrap and the ssl-cert-creation scripts work fine. Also
the kolab configuration updater seems to do its job well, but could not really
test it. The init script needs still some work. The apache configuration too. 
There are still a lot of issues with bad right settings for openldap and

I should mention that I chose to integrate apache-2, so one should look at the
httpd.conf.template with that in mind. I do not know much about configuring

The ebuild depends on since it
creates /etc/cyrusimap/

So there is still a lot to test and fix, but we have a starting point.
Comment 13 Andreas Pokorny 2004-07-03 04:23:53 UTC
Created attachment 34699 [details]

A slightly altered mod_ssl configuration using the certificates generated by
Comment 14 Andreas Pokorny 2004-07-03 04:25:03 UTC
Created attachment 34700 [details]

the kolab conf.d file, I just merged the config files of all servers of kolab
Comment 15 Andreas Pokorny 2004-07-03 04:25:54 UTC
Created attachment 34701 [details]

A particularly working kolab init script.
Comment 16 Andreas Pokorny 2004-07-03 04:26:59 UTC
Created attachment 34702 [details, diff]

The big patch which removes the /kolab prefix 
and fixes a lot of paths which differ on gentoo,
Comment 17 Dominik Stadler (RETIRED) gentoo-dev 2004-07-03 08:22:15 UTC
*** Bug 55774 has been marked as a duplicate of this bug. ***
Comment 18 Dominik Stadler (RETIRED) gentoo-dev 2004-07-03 08:22:51 UTC
Setting depend based on previous comment.
Comment 19 Christian Parpart (RETIRED) gentoo-dev 2004-07-03 09:29:29 UTC
The kolab.ebuild directly writes to /var/www/localhost/ which is not suggested by now, since we have webapp-config.

Is it possible to make this ebuild webapp-config aware?

Christian Parpart.
Comment 20 Andreas Pokorny 2004-07-03 11:16:29 UTC
Created attachment 34720 [details]

This update should add webapp support.
Could anyone track down the ldap problems?
The webinterface currently says that it cannot bind ldap anonymously, but the
scripts are using the probably correct php account and password to log into
Comment 21 Christian Parpart (RETIRED) gentoo-dev 2004-07-03 11:39:32 UTC
IMHO(!) each webapp ebuild shall add it in DEPEND, shouldn't they?

Although, I propose to "need postfix" in the init script instead of starting it by "/usr/sbin/postfix start".

The same goes for openldap (+slurpd), saslauthd, cyrus-imapd, and apache.

So, that only the lines between ebegin "Starting kolab..." end eend $? are in start().

I may be wrong, but if so, please let me know why

Christian Parpart.
Comment 22 Christian Parpart (RETIRED) gentoo-dev 2004-07-03 11:54:22 UTC
Well, I actually had a look into kolab-1.0.20-root_dir.patch.
This also provides its own httpd.conf as provided from kolab officially, too.
But at least on Gentoo, it may be very possible to have different DocumentRoot's then suggested by default, just like virtual hosts, etc.
That's why webapp-config came into mind. Now, this tool also supports webapp-special webserver configs (I read somewhere in the man pages) and though, we should use this facility to provide the "relevant" webserver 
config modifications as the original httpd.conf as seen in this patch
provides a complete config (not needed, not very usefull/scaleable).

Christian Parpart.
Comment 23 Andreas Pokorny 2004-07-03 12:13:46 UTC
Created attachment 34722 [details]

I forgot to update the session_vars.php handling, now the kolab script writes
into the webapp share directory, so updates to the php_bind and php_pass are
writen there. Is that behaviour ok? Because i cannot guess the installation
directory chosen in the webapp-config call.
Comment 24 Andreas Pokorny 2004-07-03 12:14:51 UTC
Created attachment 34723 [details, diff]

This changes the kolab script regarding the new location of session_vars.php
Comment 25 Andreas Pokorny 2004-07-03 12:19:40 UTC
<a href=>Comment 21:</a>
Yeah that might be a good idea .. we should start kolab and then maybe make the other services reload their configuration.
In the case of apache2 we have to ensure that it gets started with php and ldap  options.

<a href=>Comment 22:</a>
Just tell me how to change the config templates! The whole webapp-config thing was new to me, and it looks like a really good idea.
Comment 26 Christian Parpart (RETIRED) gentoo-dev 2004-07-03 19:37:06 UTC
Well, I believe, the template files shall contain some @@@variables@@@ that can be replaced (using sed) on webapp host installation. So, we can - step by step - remove the /etc/kolab/bootstrap mechanism that I (personally) find very ugly.

Sorry, I did *not* took a look at these files directly, since it's 4:36 morning, and I had already to much to do over 20 hours human uptime now *g*...

good night/morning,
Christian Parpart.
Comment 27 Christian Parpart (RETIRED) gentoo-dev 2004-07-03 19:40:43 UTC
Naaa! Yes! one thing yet to put before I go to sleep.

grep -E "^APACHE2_OPTS=[^#]*-D PHP" /etc/conf.d/apache2 || die "No Apache PHP support enabled"

furthermore, the .ebild DEPEND shall say that >=apache-2.0.0 
is required, as all patches I took a look in said something 
about apache2 (not 1 or any1)
Comment 28 Andreas Pokorny 2004-07-04 01:48:28 UTC
Created attachment 34756 [details]

This update (and the next root_dir patch file) fixes the proftp template file.
Also the webapp-config integration works "better" now. 

Comment #26:
Kolab is not just a web application, the bootstrap process also creates
certificates used by ldap and apache ... and the ldap database. 
The kolab perl script which resides in /etc/kolab/kolab then looks for updates,
replaces the config files and restarts the daemons when needed.

Comment #22:
As far as i understand the admin frontend only needs to have the ssl-files set,
and the session_vars.php needs to be created, so we could drop the httpd
template soon. Currently the kolab_boostrap and kolab itself replace the empty
session_var.php file generated in the webapp tree by the ebuild with the
correct user and password settings for ldap login with cn=nobody. So how would
i add a script to the webapp --install process?
The script should read ldap passwords url and user settings from the
/etc/kolab/kolab.conf and generate session_vars.php. Then apache should be
configured to use certificates of kolab.
Comment 29 Andreas Pokorny 2004-07-04 01:50:56 UTC
Created attachment 34757 [details]

The new init script of kolab, with the changes of Comment #21
Comment 30 Andreas Pokorny 2004-07-04 01:53:25 UTC
Created attachment 34758 [details, diff]
Comment 31 Christian Parpart (RETIRED) gentoo-dev 2004-07-04 11:24:17 UTC
According to the latest kolap init script, congratulations, 
this is really what I expected to. Many thanks :)

Well, of course, kolab is not a web app, but it has a web front-end, so it could be split up into two parts, the core part (kolab daemon) and the web front-end. maybe even two ebuilds, dunno....

Christian Parpart.
Comment 32 Rene Androsch 2004-07-08 12:26:47 UTC
I'm posting this comment on these two gentoo bugs:

Opengroupware (
Kolab (

And I hope, that I don't get killed for doing so :) !!

Since gentoo now has Opengroupware and Kolab Ebuilds, I'm dreaming of the perfect world, of having both of them combined as mentioned in this link:

Ogo with Kolab server-HOWTO:

I think it would be 
Comment 33 Rene Androsch 2004-07-08 12:26:47 UTC
I'm posting this comment on these two gentoo bugs:

Opengroupware (
Kolab (

And I hope, that I don't get killed for doing so :) !!

Since gentoo now has Opengroupware and Kolab Ebuilds, I'm dreaming of the perfect world, of having both of them combined as mentioned in this link:

Ogo with Kolab server-HOWTO:

I think it would be über-superb to have (for example) an use flag in the Ogo that could also install and setup Kolab in one go :)
I now is difficult and maybe impossible, but if not, this would be very cool!

Extra information:
Opengroupware and Kolab (in general)::

Comment 34 Andreas Pokorny 2004-07-09 14:46:13 UTC
Created attachment 35079 [details]

This is just a minimum update of the install script, adding webapp as a
dependency ,fixes some typos and the explanation that end of the ebuild
Comment 35 Andreas Pokorny 2004-07-09 14:52:23 UTC
Created attachment 35080 [details, diff]

This update of the kolab patch removes php.ini from the configuration files
that get replaced, removes big parts of the httpd.conf. httpd.conf.template is
no longer used as a apache2 configuration file, the file will be copied into
the vhost directory. The second '//' in the ldap url should also no longer
There were problems within saslauthd and cyrusimap with the permissions of the
certificate files. These issues should be fixed now.

This will be my last update, people with more ebuild and ldap and apache2
knowledge should continue.
Comment 36 Juha Luotio 2004-07-22 12:11:39 UTC
Created attachment 35960 [details]

I added "inherit eutils" -line just before IUSE to make ebuild working. Without
the line I was getting errors about not finding epatch.
Comment 37 Juha Luotio 2004-07-22 13:06:08 UTC
ebuild doesn't enable SSL and PHP4 at /etc/conf.d/apache2.  Maybe it should at least give some info to user the file should be updated?

Also if there is allready emerged version of proftpd on the machine it should be rebuilded with ldap support.
Comment 38 Juha Luotio 2004-07-23 02:09:22 UTC
Also pam should have pwdb support which is not build by default. This needs also be checked and if necesarry pam rebuild with pwdb support.
Comment 39 Stephan Diederich 2004-08-01 11:28:56 UTC
Hi there,
im wanted to use the current kolab ebuild, but i'm running into the following problems. I reemerged all packages needed by kolab. And yes, i ran the kolab_bootstrap -b :)

My use flags: 
"-X berkbd -qt -gtk -gnome -alsa -kde python ssl apache2 imap ldap pam ssl maildir samba sasl pwdb"
And this is the error i get:
Aug  1 20:07:19 rudi kolab[22063]: kolab initialization starts
Aug  1 20:07:19 rudi kolab[22063]: generating new config
Aug  1 20:07:22 rudi master[22097]: about to exec /usr/cyrus/bin/imapd
Aug  1 20:07:22 rudi imap[22097]: executed
Aug  1 20:07:22 rudi imapd[22097]: accepted connection
Aug  1 20:07:22 rudi perl: No worthy mechs found
Aug  1 20:07:22 rudi PAM_pwdb[21265]: check pass; user unknown
Aug  1 20:07:22 rudi imap(pam_unix)[21265]: check pass; user unknown
Aug  1 20:07:22 rudi imap(pam_unix)[21265]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Aug  1 20:07:24 rudi saslauthd[21265]: DEBUG: auth_pam: pam_authenticate failed: User not known to the underlying authentication module
Aug  1 20:07:24 rudi saslauthd[21265]: do_auth         : auth failure: [user=manager] [service=imap] [realm=] [mech=pam] [reason=PAM auth error]

And another questions: Is this the right place to post this?

Thx for any help...
Comment 40 mren 2004-08-26 17:47:53 UTC
I think proftpd is missing in the DEPEND. Or am I wrong?
Comment 41 Jose Gonzalez Gomez 2004-10-22 02:10:27 UTC
Rene, (from comment #32)

I think that the only thing you get doing what is described at the link you provide is tha possibility of accesing mail from OpenGroupware.

As far as I know (please, correct me if I'm wrong) OpenGroupware and Kolab stores contact, calendar, task... information in completely different formats and places, so colaboration between both is impossible as long as you don't write some kind of intercommunication bridge.

They are also overlapping in the functionalities they provide:

Kolab intents to be an all-in-one solution, providing prepackaged and preconfigured versions of Apache, postfix, cyrus... plus an administration interface and (I think) a experimental web interface, containing groupware functionality.

OpenGroupware relies on your already installed and configured-as-you-want Apache, postfix (or whatever SMTP server you have) and Cyrus (or whatever IMAP server you have), adding server side filtering support with Sieve if you use Cyrus (although at the moment they don't support for reading pre existing filters). OpenGroupware offers a web platform as groupware solution but it's also very focused on exporting the service through several interfaces so external GUI clients can access them.

Best regards
Comment 42 Andreas Pokorny 2005-02-16 11:43:42 UTC
Did anyone try kolab2 yet?
Comment 43 Martin Honermeyer 2005-02-16 11:51:25 UTC
Yes, runs perfect on Gentoo! The installation is very similar to Kolab1.
Comment 44 Christian Parpart (RETIRED) gentoo-dev 2005-02-16 13:12:26 UTC
What is "very similar" supposed to be?

I'm not a friend of that **** /kolab root directory, though, I'd rather see to get it more transparent supported - by using current postfix/apache/blah ebuilds with kolab based patches (enabled using USEflags) of course.
Comment 45 Carsten Lohrke (RETIRED) gentoo-dev 2005-02-16 14:35:32 UTC
>I'd rather see to get it more transparent supported

Me too. But it'll need dedicated maintainership, imho. If someone in this thread has the balls to do this, raise your voice. And please be so nice and open another bug to track kolab2 efforts. :)
Comment 46 Martin Honermeyer 2005-02-16 15:30:41 UTC
* Download everything.
* obmtool kolab
* kolab_bootstrap
* /kolab/bin/openpkg rc all start

It still has its own directory tree in /kolab. The package management with OpenPKG seems to be really distribution independent. It works quite good. 

I don't believe it would be easy to replace every Kolab package with Gentoo ebuilds. Kolab depends on exactly those versions which are available from the site. Some things are patched in order to work as expected.

In my opinion, it is the best choice to leave Kolab in its own sub-tree. Installation is possible without much effort. You don't have to supervise the whole installation process, as it works much by itself.

Updating also is not very difficult. Just download the new packages from the site and run obmtool again. Then you have to update configuration files (not quite as nice as with etc-update) and restart Kolab.
Comment 47 Christian Parpart (RETIRED) gentoo-dev 2005-02-16 16:20:16 UTC
As kolab1 is about to fade off, I don't think we need a seperate bug thread.
It indeed(!) needs dedicated work, however, I can spend time helping out for the apache side as I'm in this herd. So, we still need help for postfix, cyrus-* and for proftpd.
Though, I propose an kolab USE-flag, so, that the kolab ebuild finally is more lightweight as it depends on their respective "external" packages (postfix/apache/....) HAVING the kolab USE-flag enabled.

As portage *still* lags in support for describing such dependencies, I got told to pre-validate the DEPENDs in pkg_setup until portage supports it.

Unfortunately, it seems, that the upstream kolab seems to use plain old versions, like apache 1.3 (instead of supporting apache2).
Comment 48 Stefan Schweizer (RETIRED) gentoo-dev 2005-05-16 14:30:16 UTC
Does kolab2 support apache2?

Any progress on this?
Comment 49 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2005-05-16 14:42:30 UTC
No, see:

I have a vested interest in getting this ebuild into portage, I will be looking into this very soon.
Comment 50 Carsten Lohrke (RETIRED) gentoo-dev 2005-05-16 15:08:37 UTC
> The package management with OpenPKG seems to be really distribution independent. It works quite good.

It works, but it's a maintanence nightmare, having a lot of packages duplicated in the tree. And users will ask "why does this and that tree package not transparently work with Kolab". Also it's not only unnecessary work for those who maintain the package, but for security and architecture herds as well. I for one don't see the OpenPKG version ever to be integrated into the official repository.

>As kolab1 is about to fade off, I don't think we need a seperate bug thread.

I'd rather like to start with a clean bug, than with this one, including all this Kolab 1 junk.

Benjamin: When you do it, please open a new bug for each package, which need to be added to the tree and a new Kolab 2 tracker bug, depending on the other ones.
Comment 51 Gunnar Wrobel (RETIRED) gentoo-dev 2005-06-21 14:08:01 UTC
Kolab 2 has been released and I added a tracker bug for the Gentoo ebuild.

bug #96732

You can check my progress on converting Kolab 2 to Gentoo here:

These are just some notes I took while working on the ebuilds.

I expect to have the ebuilds ready for testing by the end of this week.
Comment 52 Stefan Schweizer (RETIRED) gentoo-dev 2005-12-25 05:57:13 UTC
is there still any ongoing effort to get this into portage?
The ebuilds on seem to be a bit outdated.
Comment 53 Benjamin Smee (strerror) (RETIRED) gentoo-dev 2005-12-25 06:14:28 UTC
Yep. Seemant has recently expressed an interest and Gunnar is still helping out. At this point we are waiting on the next version, 2.1, which is due out soon.

One of the things that is really problematic about getting kolab into gentoo is that kolab is comprised of many different parts, almost all of which are already in portage. This means that in order to get kolab into the tree you have to either try and package things up separately just as one big kolab ebuild, which in turn then will block everything else and is not really feasible, or you have to maintain patches against all the different components. The kolab devs realise how badly they have packaged things (from the point of a distro maintainer) and are making changed, most of which we hope to see in 2.1. Until then though its seriously problematic to get a semi decent, maintainable version into the tree.
Comment 54 Carsten Lohrke (RETIRED) gentoo-dev 2005-12-25 13:28:46 UTC
(In reply to comment #52)
> One of the things that is really problematic about getting kolab into gentoo is
> that kolab is comprised of many different parts, almost all of which are
> already in portage. This means that in order to get kolab into the tree you
> have to either try and package things up separately just as one big kolab
> ebuild, which in turn then will block everything else and is not really
> feasible, or you have to maintain patches against all the different components.

Well such a set of packages should of course base on the packages within Portage. The number of needed patches is low and the Kolab guys are actively working to get them into mainline. The only point is that this package needs a dedicated guy who does the integration into Gentoo and keeps on maintaining the relevant packages.

I don't think anyone is attempting to get Kolab 1 supported and there's bug 96732 for Kolab 2, so it should be fine to close this one.