[Kolab-devel] Extending Kolab
Gunnar Wrobel
wrobel at pardus.de
Wed Jun 4 07:37:56 CEST 2008
Bernhard Reiter <bernhard at intevation.de> writes:
> On Friday 02 May 2008 14:51, Gunnar Wrobel wrote:
>> >> > We could think about defining a "playground" OID subtree, if there is
>> >> none > in the OID scheme already. (Does something know out of the top of
>> >> their head?) > Before this I would want to document the use of Kolab's
>> >> privat OIDs. > I have already the start
>> >> > http://wiki.kolab.org/index.php/Directory_Service_Schema
>> >>
>> >> Is there any specific reason for having new OIDs for such
>> >> configuration variables? This seems extremely cumbersome as it always
>> >> requires a schema change for any application we might wish to
>> >> configure over the LDAP tree.
>
> "extremely cumbersome" is not the right attribute ... as Alain correctly
> points out
>
>> > Extend the LDAP schema is very easy, just add your new attributes in
>> > the schema file and restart ldap.
>
>> I was thinking of adding new attributes in the Kolab schema that gets
>> delivered with the default distribution. Meaning changes within Kolab
>> CVS and this takes more effort. For local hacks this is of course
>> easy.
>
> Adding and changing attributes too lightly is a call for trouble, especially
> in upgrade situations. So a little resistance is good. And a little it is.
> If the bar is to high at the moment, we could lower it by a set of
> instructions and we might consider a playground subtree of the Kolab OIDs.
>
> The whole idea of LDAP is to be able to control the variables and their
> contents. So if you have a changed or new OID, yes you should do a new number
> and put up a real definition of the type and semantics. The rules out implicit
> definitions, but again I believe this is a good thing when being consistantly
> in LDAP. Overal I think LDAP and is overdesigned, but the abuse would add to
> the complexity from my point of view, making it worse.
When speaking with Thomas Börnert last week I realized that I was not
really precise on what I meant here.
The generic LDAP attribute was meant to be only added to the special
"k=kolab" object.
Something like this:
diff -r 7ef19097e3c6 server/kolabd/kolabd/kolab2.schema
--- a/server/kolabd/kolabd/kolab2.schema Thu May 08 13:05:18 2008 +0200
+++ b/server/kolabd/kolabd/kolab2.schema Wed Jun 04 07:35:28 2008 +0200
@@ -539,6 +539,15 @@
NAME 'proftpd-userPassword'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+######################################################
+# generic Kolab setting #
+######################################################
+
+attributetype ( 1.3.6.1.4.1.19414.2.1.904
+ NAME 'kolabParameter'
+ DESC 'A generic setting for configuring Kolab. Syntax is x=y.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
########################
# kolab object classes #
########################
@@ -580,6 +589,7 @@
proftpd-defaultquota $
kolabFreeBusyFuture $
kolabFreeBusyPast $
+ kolabParameter $
uid $
userPassword ) )
In terms of LDAp "k=kolab" is a pretty special object anyhow as it
basically groups a set of configuration settings that do not really
form a precise object.
Cheers,
Gunnar
>
> Bernhard
>
>
>
> --
> Managing Director - Owner: www.intevation.net (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
--
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ 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 <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the devel
mailing list