[Kolab-devel] Kolab, LDAP, and Unix acounts

Alexandre Boeglin alex at nexedi.com
Thu Jun 3 11:00:58 CEST 2004


Le mercredi 2 Juin 2004 18:22, Buchan Milne a écrit :
> Alexandre Boeglin wrote:
> | - When an user is created, it curently inherits from the objectClass
> | "inetOrgPerson" (for Kolab). I want to make it inherit also from
> | "posixAccount", "shadowAccount" (for Unix accounts) and maybe from
> | "sambaSamAccount" (for Samba).
>
> There is no need for this, you can add these (auxiliary) objectclasses
> as is. You will notice samba already uses inetOrgPerson when adding
> accouts (since it needs a structural objectclass).

What i meant is that i would like to have one single interface to create 
entities that are Kolab users as well as Unix and Samba users.

My goal is to be able to manage users in an easy way, so that people 
that will 
use this interface in the future to add users won't have to bother about 
Kolab, Unix or Samba specificities...

They will just add one user, fill some infos (phone, location...), and 
right 
after that, the new user can log in to Kolab, Unix and Samba.

> | the interface to manage groups (add/remove groups, add/remove users 
in 
> | groups), using the objectClass "posixGroup" for the moment, buy I
> 
> IMHO this is not necessary. If your samba setup is done right you can
> use User Manager for Domains or smbldap-tools for this. It would be
> nice, but rather first fix the real issues preventing interoperation.

But, then : what about Unix groups? And this solution doesn't meet my 
requirement "manage everything at the same place".

> IMHO the two biggest obstacles currently are:
> -Kolab trashing previous slapd.conf's (or user edits). This is the
> reason I don't run Kolab on my own laptop at present (since it
> overwrites all my changes all the time unnecessarily)

This is not a bug, it's a feature (that allows you to recreate config 
files 
from templates and the kolab LDAP entry). So, you just need to adapt the 
templates.

> -Namespace conflicts should be avoided (using the person's name as the
> naming attribute is ridiculous as it is not guaranteed to be unique).

I aggree, and I think that this fact is clear for everyone.


Regards,
Alexandre Boeglin




More information about the devel mailing list