| Summary: | Req: ebuild for kolab server | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christian Parpart (RETIRED) <trapni> |
| Component: | New packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | alpeterson, arnaud_oss, bugs, diemumiee, ehmsen, genstef, guigui, hhielscher, jgonzalez.openinput, jlambert, kde, m.debruijne, maze, ramon, S.Diederich, timmy, warwick, wiredcoder, wrobel, yann.lugrin, ziga.boehm |
| Priority: | High | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://kolab.kroupware.org/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 55537 | ||
| Bug Blocks: | |||
| Attachments: |
kolab-1.0.20.ebuild
41_mod_ssl.default-vhost.conf.template kolab-1.0.20-conf.d kolab-1.0.20-init.d kolab-1.0.20-root_dir.patch kolab-1.0.20.ebuild kolab-1.0.20.ebuild kolab-1.0.20-root_dir.patch kolab-1.0.20.ebuild kolab-1.0.20-init.d kolab-1.0.20-root_dir.patch kolab-1.0.20.ebuild kolab-1.0.20-root_dir.patch kolab-1.0.20.ebuild |
||
|
Description
Christian Parpart (RETIRED)
2003-07-29 01:11:04 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... BTW, ebuild for the client (kde-pim fork until kde 3.2 is released) is available at : http://dev.gentoo.org/~stuart/packages/. 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 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. Hi, Kolab isn't a web-application - it's a KDE-centric mail server solution. Please re-assign. Thanks, Stu hello? noone intereseted in having gentoo serving kolab clients? greets, christian. yo - someone going to write up an ebuild? 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 :( Hm, maybe I should try opengroupware, until there is a Kolab ebuild.... It's just waiting for someone to write an ebuild. The lack of one thus far makes me think nobody must use the product. 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...) 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... Created attachment 34698 [details] kolab-1.0.20.ebuild I tried instlling kolab using the openpkg script, but it failed because of some rpm problems, so i started working on an ebuild(http://bugs.gentoo.org/show_bug.cgi?id=55774). 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 apache. 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 apache. The ebuild depends on http://bugs.gentoo.org/show_bug.cgi?id=55537 since it creates /etc/cyrusimap/imapd.group. So there is still a lot to test and fix, but we have a starting point. Created attachment 34699 [details]
41_mod_ssl.default-vhost.conf.template
A slightly altered mod_ssl configuration using the certificates generated by
kolab.
Created attachment 34700 [details]
kolab-1.0.20-conf.d
the kolab conf.d file, I just merged the config files of all servers of kolab
Created attachment 34701 [details]
kolab-1.0.20-init.d
A particularly working kolab init script.
Created attachment 34702 [details, diff]
kolab-1.0.20-root_dir.patch
The big patch which removes the /kolab prefix
and fixes a lot of paths which differ on gentoo,
*** Bug 55774 has been marked as a duplicate of this bug. *** Setting depend based on previous comment. 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? Greets, Christian Parpart. Created attachment 34720 [details]
kolab-1.0.20.ebuild
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
ldap.
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 Greets, Christian Parpart. 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). thanks, Christian Parpart. Created attachment 34722 [details]
kolab-1.0.20.ebuild
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.
Created attachment 34723 [details, diff]
kolab-1.0.20-root_dir.patch
This changes the kolab script regarding the new location of session_vars.php
<a href=http://bugs.gentoo.org/show_bug.cgi?id=25485#c21>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=http://bugs.gentoo.org/show_bug.cgi?id=25485#c22>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. 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. 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) Created attachment 34756 [details] kolab-1.0.20.ebuild 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. Created attachment 34757 [details] kolab-1.0.20-init.d The new init script of kolab, with the changes of Comment #21 Created attachment 34758 [details, diff]
kolab-1.0.20-root_dir.patch
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.... Greets, Christian Parpart. I'm posting this comment on these two gentoo bugs: Opengroupware (http://bugs.gentoo.org/show_bug.cgi?id=24247) Kolab (http://bugs.gentoo.org/show_bug.cgi?id=25485) 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: http://mail.opengroupware.org/pipermail/users/2003-July/001248.html I think it would be I'm posting this comment on these two gentoo bugs: Opengroupware (http://bugs.gentoo.org/show_bug.cgi?id=24247) Kolab (http://bugs.gentoo.org/show_bug.cgi?id=25485) 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: http://mail.opengroupware.org/pipermail/users/2003-July/001248.html 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):: http://www.opengroupware.org/en/related/kolab/ Created attachment 35079 [details]
kolab-1.0.20.ebuild
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
Created attachment 35080 [details, diff]
kolab-1.0.20-root_dir.patch
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
occure.
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.
Created attachment 35960 [details]
kolab-1.0.20.ebuild
I added "inherit eutils" -line just before IUSE to make ebuild working. Without
the line I was getting errors about not finding epatch.
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. 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. 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... I think proftpd is missing in the DEPEND. Or am I wrong? 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 Jose Did anyone try kolab2 yet? Yes, runs perfect on Gentoo! The installation is very similar to Kolab1. 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. >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. :)
* 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. 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). Does kolab2 support apache2? Any progress on this? No, see: http://kolab.org/pipermail/kolab-devel/2005-April/003319.html I have a vested interest in getting this ebuild into portage, I will be looking into this very soon. > 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. 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: http://www.gunnarwrobel.de/projects/Kolab.html 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. is there still any ongoing effort to get this into portage? The ebuilds on http://www.gunnarwrobel.de seem to be a bit outdated. 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. (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. |