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

Gunnar Wrobel wrobel at pardus.de
Fri Sep 19 13:44:44 CEST 2008


Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> Op Monday 15 September 2008 23:53:59 schreef Alain Spineux:
>> Bernhard asked my advice about the inclusion of this patch in CVS .... :
>>
>> As I say for long time now, I'm more in favor of a plugin interface than
>> the inclusion of any Samba's specific code into Kolab.
>>
>> The pros and cons of the plugin architecture :
>>
>> - require more code than the simple Samba's specific patch
>> + the plugin architecture could be helpful to future Kolab's plugin
>> projects ( Asterisk integration, black and grey listing, ....)
>> + The two projects (kolab and the samba plugin) will be able to
>> evolute independently. Changes in one will not automatically implies
>> change in the other. This is true for bug too.
>>
>> For remember the Kolab's plugin interface should contains a least :
>> - some kolab's perl and PHP "function helper", "
>> - some php "hooks" to add screen and functionalities to the admin
>> interface, - some "hook" from inside the kolabd and the template generation
>> ùprocess
>
> Let me put it this way: let us know when the plugin interface is available we
> can than use it to add the samba functionality.
>
> Of course a plugin interface would be nice, but it is not here

I disagree. Any package management system is meant to be used for  
extensions. Granted the OpenPKG based Kolab Server has a long history  
of not enabling users to choose.

Currently the list of packages you can install when running  
install-kolab.sh is fixed. No choices allowed. But that does not  
change the fact that a user could generate an experimental RPM package  
for the Kolab Server and distribute it. It is actually not that hard.  
You could for example package a PHP web application (e.g. PHP-BB or  
some other fancy stuff) and provide it to other Kolab users so they  
can install it in their server. That is indeed a plugin interface.

Of course that interface is quite limited. It is mainly file based but  
this is enough to reach a lot of things. You actually mention some of  
these things further down and I'll comment them there.

> and I think
> that it will take a long (very long) time till it arrives.  Now with regards
> to the samba patch, it is of course possible to wait till the plugin
> interface arrives or as the patch is about ready to be committed to cvs that
> could be done as well.  If one waits long enough the current patch can't be
> committed anymore as the sources in cvs will have changed and a nice
> oppertunity will have passed to include some samba functionality.  The kolab
> devs could of course state that the patch will be included if someone
> provides the plugin structure, hoping that e.g. Albrecht or Christian (the
> samba patch providers) will provide the plugin structure.  But Albrecht e.g.
> already stated that he won't customize the patch further, so forget he'll
> provide a plugin structure...
>
> 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.

> The
> samba.php include file much be included in the file www/admin/user/user.php.
> How should happen with a plugin structure?  Should there be
> a /usr/lib/php/kolab/plugins directory? Should all the php files in that
> directory be included in the www/admin/user/user.php?  Or should the plugin
> have a kind of  include tag that states that it should be included in
> user.php?  This is I believe still the easy part.  Next is that the plugin
> should be triggered when a new user is saved, or removed and when the
> password is saved.  How is that to be done?  Here some smart plugin mechanism
> needs to be developed.

kolab-webadmin is really the only problem I see. More on this at the  
end of the mail.

>
> 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.

>
> 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?

>
> 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.

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.

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.

In any case thanks for fostering the discussions. Even if the whole  
process is slow I believe we are getting somewhere :)

Cheers,

Gunnar

> if it is to be accepted by the kolab devs at
> all.
>
> My 2ct.
>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the devel mailing list