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

[Buchan Milne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexandre Boeglin wrote:
| Hello,
|
| I would like to install Kolab on one server, and this server would
also act as
| an X/VNC server.
|
| Thus, having the Kolab and Unix accounts (using pam-ldap) synchronized
in LDAP
| would really help me.
|
| So, i'd like to add some features to Kolab's web interface :
|
| - 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).

| - There is no groups (at least in Kolab1). I would like to add the
ability in
| the interface to manage groups (add/remove groups, add/remove users in
| groups), using the objectClass "posixGroup" for the moment, buy I
think it
| could integrate with group ACL i've read about in Proko2 announce.
|

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.

| Now, my questions are :
|
| - Is someone already working on this?
|
| - Does someone else think that this could be usefull?

Yes, I will not deploy Kolab to production systems until it does, since
my LDAP systems already have full LDAP/Samba support (and even more on
some systems in pre-production).

| And is there any chance
| for it to be integrated into Kolab one day? (else, it would be far
easier for
| me to write a separate interface than to sync my changes again and
again with
| Kolab's interface)
|

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

Of course, I am assuming that we have a schema that interoperates with
other schemas ...

Regards,
Buchan

- --
Buchan Milne                      Senior Support Technician
Obsidian Systems                  http://www.obsidian.co.za
B.Eng                                RHCE (803004789010797)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAvf6trJK6UGDSBKcRAvwtAKCS9vpvlioPlkZHoXMA6sO8dVeZXgCgnre2
duzBO3qkjJnVm1tDwG1y+xw=
=LiHa
-----END PGP SIGNATURE-----