[Kolab-devel] Extending Kolab

Bernhard Reiter bernhard at intevation.de
Fri Apr 25 14:15:23 CEST 2008


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

> >  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080425/a0c060e9/attachment.sig>


More information about the devel mailing list