a few more questions

[Jean-Michel Dault]

Le mer 08/09/2004 à 12:15, Gustavo Michels a écrit :
> I "kind of" have Kolab2 working with pam_ldap and nss_ldap. As I nedded an 
> OU to hold all the users (so that nss_ldap works), and kolab creates users 
> on the root of the ldap server, I am doing all user administrative tasks 
> thru an ldap tool (phpldapadmin), since kolab will move the user back to 
> its default if I edited in the web interface. Also, I added the nis schema 
> to the kolab openldap template.

I solved these issues in Kolab 1.0. The hardest part was to hack kolab
so it reads the old entry before doing any modification, so it can use
the original ObjectClasses and doesn't erase the attributes it doesn't
know. 

Another challenge was to be able to "toggle" system user status. That
is, by default, the user is only inetOrgPerson, but you can switch it to
a system account. I created a KolabExtendedSchema auxiliary class that
has all the attributes of posixAccount, shadowAccount and
sambaSamAccount as MAY, instead of MUST. 

> Now my question is: does any developer see any problem in Kolab usability by 
> doing these changes?

There are a couple of problems if you don't have the @domain part in the
user id:
1) You have to manually change the freebusy configuration so it uses an
e-mail address, but authenticates with the uid.
2) You have to modify sasl so it only search on the uid, not the e-mail,
otherwise, if someone tries to authenticate with his email, it will
create the mailbox with the e-mail, and that results in two mailboxes
per user and support problems.
3) You'll have to modify the vacation code not to specify any e-mail
address, otherwise cyrus crashes (I don't know why, but it does).

Other than that, there shouldn't be any problems with Kolab usability.

-- 
Jean-Michel Dault <jmdault at mandrakesoft.com>