[Kolab-devel] using givenName and sn for administrator/maintainer ldap objects

[Tobias Koenig]

On Fri, Aug 25, 2006 at 11:10:55AM +0200, Bernhard Reiter wrote:
> Am Freitag, 25. August 2006 08:54 schrieb Tobias Koenig:
Hi,

> > IIRC Martin mentioned that in future versions the cn should be an unique
> > identifier anyway, which is independend from the name, so why not
> > switching now?
> 
> Because we do not have a full concept of how this unique identifier
> is constructed and all the other use cases work.
Well, the unique identifier should be set by the administrator when he
creates an account. When Kolab is integrated in an existing environment
(e.g. eDirectory) there does exists an uid already, it just have to be
mapped to the uid of the LDAP entries.

For a standalone kolab server the webfrontend could provide 'default'
values like the 3 first letters of the given name and sure name, or the
email address (which shouldn't change anyway!).

> Next we need a migration procedure.
Come on, that's a 10 line python script...

> In addition the 2.1. server series has the goal of staying compatible
> from the LDAP point of view to not cause higher efforts at the tools
> that already have been integrated with Kolab's current LDAP concept.
> E.g. EDS' DirActory, Univention's UCS, Gonicus' GOsa.
> 
> Any proposed change must take this into account as we want to 
> keep Kolab attractive. So for the tasks given above, this is likely
> to happen with a larger development step.
So we can keep it in mind for Kolab3?

Why wasn't it used from the beginning? The same concept is used for
users, so where was the difference to the maintainers/administrators?

Ciao,
Tobias
-- 
Separate politics from religion and economy!
The Council of the European Union is an undemocratic and illegal institution!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20060825/a32a79f4/attachment.sig>