[Kolab-devel] Modifying the LDAP user representation for a distributed Kolab server system?

[Gunnar Wrobel]

Quoting "Bernhard Reiter" <bernhard at intevation.de>:

> On Friday 15 August 2008 06:41, Gunnar Wrobel wrote:
>> Quoting Bernhard Reiter <bernhard at intevation.de>:
>> > On Tuesday 29 July 2008 14:05, Gunnar Wrobel wrote:
>> >> Inventing a new Kolab user LDAP attribute for each and every service
>> >> of the Kolab server to support such splitting seems like an overhead
>> >> and people did not like the suggestion too much.
>> >>
>> >> So let me suggest an alternative by using the existing
>> >> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
>> >> allow for several settings like:
>> >>
>> >>   "example.org"
>> >>   "MTA:smtp.example.org"
>> >>   "IMAP:imap.example.org"
>> >>   "FreeBusy:fb.example.org"
>> >>
>> >> The default would be the entry without "prefix:" but it would be
>> >> possible to provide redirects for specific services.
>> >
>> > This looks quite ugly to me. Somehow inventing more parsing within
>> > an LDAP attribute really feel wrong to me.
>> > So if we need the attributes, we can for sure come up with enough for
>> > them.
>>
>> Okay, I agree with the parsing thing.
>>
>> > I am not sure that we need it per user, though.
>>
>> p at rdus does :) If you have an array of IMAP servers behind an MTA
>> layer the MTA layer should actually know which IMAP server to deliver
>> to. And that is per user. I know this is not possible with
>> Kolab2/OpenPKG at the moment but such distributed setup are feasible
>> with Kolab.
>
> Ah, you also want to split up below one homeserver.
> Of course, if you want to do this, it needs to be saved somewhere.
> For most deployment I would normally recommend having one imap server (which
> can be a cluster) per homeserver. It does not hurt to have one MTA per IMAP
> server and might help in many situations. I guess this is why I did not get
> the idea.

Yes in general I would agree. Having a seperate MTA layer gives you  
some additional options concerning failover and redundancy though. And  
for me it drastically reduces maintainance efforts but that is of  
course more related to not using the OpenPKG version.

I consider the fact that you can easily split the Kolab server to that  
degree an very important plus for the groupware server. Hence the wish  
for this feature as it is nothing too complex even if it is irrelevant  
in the default setup.

>
>> > For the user, most should be transparent (means: not visible).
>>
>> The admin sets this stuff in the web admin frontend. It should
>> obviously not be editable by the user as this concerns the server
>> infrastructure and is no user setting.
>>
>> > This is why I am also against putting anything server specific in the
>> > login information. This could change during the lifetime of an account.
>>
>> Login information? Sorry, didn't understand this comment. Can you clarify?
>
> I believe I've refered to the upcoming point where I saw "USER:PASS at SERVER"
> and I wanted to outrule this as part of an LDAP entry.
>>
>> >> If I consider the point Bernhard mentioned recently concerning
>> >> splitted IMAP storage per user it might also make sense to have a
>> >> syntax like
>> >>  "imap://USER:PASS@SERVER"
>> >
>> > For what in particular?
>> > The splitted IMAP storage will only be known the the user's client
>> > mostly.
>>
>> So the user would set the storage spaces in Kontact and in the Kolab
>> web client again?
>
> Yes.
> Even if we find a desired way of saving client configuration on one server
> somehow.
>
>> Storing that in LDAP would remove this redundancy or not?
>
> It would, but it would also defeat the security aspect of the idea.
> If you have server A and server B, you would not want admin of server
> A to be able to log into server B to have some separation. :)
> So putting credentials in the directory service of server A
> is not that helpful.

Yes, forget my initial comments. I confused two concepts that were not  
related at all.

Concerning the Kolab web client the user could store the necessary  
configuration on the primary IMAP store. For the web client this might  
actually be the only reasonable solution. Currently we store the  
configuration of the web client in LDAP though.

We would have to think that through once we really start implementing  
such a feature. I must admit that I'm rather interested though. I'd  
like to be able to  add other IMAP storage spaces to my accounts  
(gmail for example). It might also be possible to network to a higher  
degree between the Kolab Konsortium partners if we provide IMAP  
accounts to our partners for joint projects. Just some ideas.

Cheers,

Gunnar

>
>
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.