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

[Bernhard Reiter]

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

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

Even if it was, we would need to fully test it, which is a lot more work.

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

Of course, I am quite sure that we will improve this point.
What helps would be a good discussion of the various approaches 
documented in the wiki.

> Why wasn't it used from the beginning? 

As far as I remember we wanted to stay close to the email address,
which must be unique anyway. Akak
   firstname.name at example.org  transfers cn=firstname name, dc=example, dc=org
But we learned the drawback of the approach since then as well.

> The same concept is used for 
> users, so where was the difference to the maintainers/administrators?

The uids for users were introduced later, and if I remember correctly,
was more compatible to do.
Martin knows more details (he currently is on vacation).

Best,
Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- 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/20060831/2957b021/attachment.sig>