[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