[Kolab-devel] Extending Kolab
Gunnar Wrobel
wrobel at pardus.de
Wed Apr 30 13:22:40 CEST 2008
Bernhard Reiter <bernhard at intevation.de> writes:
> On Thursday 24 April 2008 13:05, Alain Spineux wrote:
>> > If you mean the webinterface:
>> > The webinterface mainly shows what is in the directory service.
>> > So just putting in another form usually is not enough as this will
>> > only have the credentials of the user.
>>
>> the user ? The user can be a domain admin or the manger with enough right
>> to update the LDAP db.
>
> Yes, by default any user can change some values in the ldap. :)
> I mentioned it, because this is different from what many people think
> how to build a webinterface for systemadministration. It is more secure,
> but also more involved.
>
>> Also use of shell scrip and SUDO could help for
>> more. This is the responsibility of the plugins developer to make the
>> best choice and make the thinks work.
>
> This would strip the current configuration system of its beauty,
> so I am unsure if I would want to promote such hacks.
> Better would be to promote helping to do the right thing.
>
>> > Yes, we could add hooks where they are useful. :)
>> >
>> > > - add some free attributes to the ldapschema like
>> > > "kolabFreeAttribute" where addon can store
>> > > value like "postgrey:enable" or "postgrey_delay:300"
>> >
>> > This sounds like abusing the directory service a bit.
>>
>> Yes this is a HACK !
>>
>> > If you are happy to add something, why not add real attributes to your
>> > ldap scheme. I believe the hard part here is to grok the involved
>> > technologies (LDAP is a beast, IMO).
>>
>> Extend the ldap schema is not easy for non experimented user.
>> Also register new attribute or object OID is even more difficult.
>
> Registration of your private oid is very painless and involves sending an
> email. Also if you are just doing private modifications you could abuse
> any oid.
>
>> But the plugin developer is free to define its own attributes or not.
>> Likewise The kolab team can help him for a better integration, providing
>> him dedicated attribute from inside the kolab OIDs.
>
> 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.
I'd be in favor of creating something simple like "kolabVariable" that
holds string entries like "postgrey_delay=300". I'm not an LDAP expert
so there might be reasons against this but we had similar suggestions
before and declaring oids seems to be a little bit too much overhead.
Cheers,
Gunnar
>
>> > Alain, I appreciate your insight.
>>
>> We are all living in the same world, trying to make things better and
>> quicker.
>
> Yep, the question is often: What do improve next. ;)
> 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