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

[Bernhard Reiter]

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.

> > 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. 



-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080826/ada13c7d/attachment.sig>