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

[Gunnar Wrobel]

Bernhard Reiter <bernhard at intevation.de> writes:

> On Tuesday 29 July 2008 11:55, Gunnar Wrobel wrote:
>> I don't see a specific benefit for a completely separate FreeBusy
>> server as described in the Horde bug I referenced. I think you'd need
>> a lot of users in order to make that necessary.
>
> I lack numbers, but my guess is that Horde is one or two magnitudes
> more resource hungry than a native client user on a server machine.
> So if you can have 200 native concurrent users, probably the same machine will 
> only take 20 or less concurrent Horde users.
>
>> But once you split your Horde installation to a different Apache
>> server I believe it makes a lot of sense to combine FreeBusy with the
>> Horde installation. The newer FreeBusy code uses the same IMAP cache
>> as Horde does. So you can reduce the IMAP calls with this. A combined
>> Horde/FreeBusy server also allows you to remove the complete apache
>> from the main server which might be another reason for such a setup.
>>
>> I think I discussed this with Bernhard once and he disagreed but I'd
>> have to look up the thread again.
>
> Yes I disagree because freebusy is a part of the native client
> for which people expect different response times. Web client usage is 
> something very different from the user perspective. And I do not want 
> web users to slow down native client users and email in- and outgoing 
> processing.

Ah, makes sense. Thanks for the reminder.

>
> So standard separation steps would be:
> a) an an SMTP gateways with scanning
> b) seperate web client server (Horde)

>From the different statements in this thread I have the impression
that people consider it a good thing that the Kolab server can be
splitted to cope with various usage scenarios. Scaling the server to
cope with the load is rather easy this way.

In general it might not make sense to split off the smaller, tiny
services but in principle it would be possible if the admin chooses to
do so.

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.

I don't suggest to directly add support for this in the various Kolab
services we currently have as I don't see this as urgent. But if we
define the syntax this way we could at least start supporting this for
the more common splitted Kolab server setups.

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"

Cheers,

Gunnar


>
> Bernhard
>
> -- 
> 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
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ 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 <<                 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~