[Kolab-devel] Enhancing Kolab decision making(re: Is it okay to commit the samba patch to cvs?)

[Richard Bos]

Op Friday 19 September 2008 13:44:44 schreef Gunnar Wrobel:
> Quoting Richard Bos <ml at radoeka.nl>:
[............]
> > Let's see what difficulties we run into if the samba patch would be made
> > a plugin:
> >
> > The patch provides a template file (samba.php.template.in).  So it
> > needs to be
> > build.  This makes it already much less attractive as a plain plugin.
>
> Why? Any plugin package will have to be build using rpm. That is an
> essential part of package management when using binary packages and I
> don't see a problem with it.

Because it needs a Makefile and the makefile must include the dist-conf file.  
Which is not straight forward to do.  However, Alain suggestion to use kolab.
{global,conf} as much as possible is a good one.  I only don't know if this 
will work for setting which binary to use, e.g. in case of perl, php and the 
like (@PERL@ should be expanded to /usr/bin/perl, etc).

[....]

> > Next is the slapd.conf.template; 2 schema's have to be included,
> > some indexing
> > keys are defined and new acl's are added.  The latter can be achieved
> > when kolab is going to use the new openldap configuration method (what is
> > it called Real Time Configuration, I believe).  The plugin openldap stuff
> > can just be dumped in the RTC openldap directory.  I don't believe that
> > the plugin additions can be easily added to the current slapd.conf file.
>
> Why not? I don't know at the moment if the "include" statement in
> slapd.conf would allow something like "include
> /etc/openldap/plugins/*.conf". If not you could still use such a
> directory and have kolabconf compile the single files in
> "/etc/openldap/plugins" into one file "/etc/openldap/plugins.conf"
> which you include with "include /etc/openldap/plugins.conf" in
> slapd.conf. Does not sound that hard to me.

The problem is more related to the hiearchy in the slap.conf file.  As there 
is a global part (top of file), settings that belong to the database (like 
the syncrepl stuff, which should be under the database config option about 
the middle of slapd.conf file) and there are the access control lists.  The 
latter is about the bottom of the file.  If this conclusion is indeed 
correct, there should be at least 3 include lines:
include /etc/openldap/slapd.global.d/*conf
include /etc/openldap/slapd.db.d/*conf
include /etc/openldap/slapd.access.d/*conf
But doing it this way is like re-inventing openldap Real Time Configuration 
(RTC).  Hence I suggested to move to openldap RTC right away!

> > Last for this patch is the addition of variables to kolab.conf.  This can
> > be achieved when kolab is going to use a conf.d (/etc/kolab/conf.d)
> > directory. Plugins could just dump their variable definitions there and
> > kolabconf would read them.
>
> Sounds pretty easy. Why shouldn't we do it this way?

Just do it, but we / somebody needs to code it.

> > For the RTC slapd.conf there is already an issue.  For all the other
> > challenges there isn't.
> >
> > Perhaps issues should be opened for the ideas mentioned above (and
> > that others
> > agree with).  But I also think it shows that the plugin interface is not
> > available for a long time.  Hence the samba patch should be committed to
> > cvs the way it is now available,
>
> I really don't think so. You had some very good suggestions which are
> not that hard to implement and I think just fixing the
> /etc/kolab/conf.d/ and the /etc/openldap/plugins/ issues would already
> allow you to package the biggest part of the samba patch in a plugin.

Thanks, nice to read :) 

> Of course that still excludes the kolab-webadmin package and I
> acknowledge that this is a problem indeed. File-based extensions are
> currently not possible there.
>
> I started rewriting the code once but I failed to get it done for time
> constraints. I still believe this is a thing that is in dire need of
> full rewrite.

Hmm, full rewrite....  Now that horde is about to be released by default with 
kolab, would a full rewrite be possible with the horde libraries?  Would that 
make it easier to do the rewrite?  It would at least give a consistent 
interface which is an important aspect too.

> Nevertheless: When I look at the discussion above and the good
> proposals you already made, maybe finding a a simple solution for
> kolab-webadmin wouldn't be that hard either? I'm certainly willing to
> discuss that.

Let's take user.php which creates, modify and remove users.  This is probably 
needed by more than 1 plugin => most likely a file based extension is needed.
Let's say the trigger is called 'create-user' to create a user.  Now if the 
plugins store there code in:
/var/lib/kolab/plugins/plugin-1/create-user.php
/var/lib/kolab/plugins/plugin-q/create-user.php

Inside the plugin there is just 1 function that's called create-user-plugin-1 
and create-user-plugin-q, would it be possible to use those functions in 
user.php?

user.php should check for the files, build an array of the available plugins 
and call them one for one on the correct trigger point.  All plugins get the 
same arguments from the trigger point.  Would this be possible?

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.