<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gunnar Wrobel wrote:
<blockquote cite="mid:87odetaufy.fsf@home.pardus.de" type="cite">
<pre wrap="">Fabio Pietrosanti <a class="moz-txt-link-rfc2396E" href="mailto:lists@infosecurity.ch"><lists@infosecurity.ch></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">Dear all,
i noticed one bad scalability issue of Kolab while you handle a lot of
virtual domains.
The main issues are the 'static' configuration that could be made
dynamic of imapd.conf of Cyrus and main.cf of Postfix.
For Cyrus imapd.conf the "loginrealms:" include the list of all virtual
domains and it's generated by kolabd.
If the list of loginrealms became too much long because you are using a
lot of virtual domains bad things could appens.
</pre>
</blockquote>
<pre wrap=""><!---->
What kind of limits are there and at which point are we going to hit
these limits? What would cyrus and postfix do if this limit gets
exceeded?
</pre>
</blockquote>
I still doesn't know BUT what i found is that loginrealms: is not
required to have kolab working (at least on my kolab 2.1 installation).<br>
<br>
Could we consider removing it or do you think it's required?<br>
<br>
<blockquote cite="mid:87odetaufy.fsf@home.pardus.de" type="cite">
<blockquote type="cite">
<pre wrap="">Solution would be to add something like this loginrealms dynamic lookup
described here:
<a class="moz-txt-link-freetext" href="http://www.irbs.net/internet/info-cyrus/0601/0244.html">http://www.irbs.net/internet/info-cyrus/0601/0244.html</a>
or i am wondering which is the real reasons for which we are requiring
loginrealms, because here they removed it and it worked
<a class="moz-txt-link-freetext" href="http://www.nabble.com/Multidomain-support-in-Cyrus-eGroupware-with-LDAP--solved--t3665722s3741.html">http://www.nabble.com/Multidomain-support-in-Cyrus-eGroupware-with-LDAP--solved--t3665722s3741.html</a>
Now on my multiple-domains (a lot of domains) email servers, i commented
out the loginrealms and it works fine, i can create users, change
password, login, change permissions, etc, etc . It seems to work.
For postfix's main.conf it's the same for the following configuration
line that contains the list of domains:
mydestination
masquerade_domains
Imho we hould map this lists to dynamic lookups to the ldap directory in
order to scale better with a large number of virtual domains.
</pre>
</blockquote>
<pre wrap=""><!---->
Would the lookup only happen when the services are started? Or would
the lookup occur associated with certain user actions? The second
scenario would slow things down so it might be better if this is
configurable or gets only activated if the server has more than a
defined number of virtual domains managed.
</pre>
</blockquote>
<br>
I think that i found a good way to manage both situation in one shot.<br>
<br>
The problem of dynamic lookups is that it would require a high number
of queries under high email load.<br>
The ldap client of postfix doesn't support lookup caching and require
for each new query a new connection.<br>
<br>
Still, the proxymap allow a single permanent connection to be
established to the ldap server and reused by all lookups.<br>
<br>
So, generally speaking, if we apply the proxymap instead of the ldap
direct lookup to all the postfix lookup we can gain the advantage of
connection caching for ALL the ldap lookups removing a great overhead.<br>
<br>
<a class="moz-txt-link-freetext" href="http://archives.neohapsis.com/archives/postfix/2004-03/0806.html">http://archives.neohapsis.com/archives/postfix/2004-03/0806.html</a><br>
<br>
Imho this could give a 'good' performance improvement and allow the
implementation of FULL DYNAMIC lookup of all postfix tables (also
because openldap has it's own cache).<br>
<br>
What do you think about those two proposals?<br>
<br>
<br>
I am just evaluating how to remove what could be somehow a scalability
issue and find out a "not in the choice of the sysadmin" solution.<br>
<br>
Fabio<br>
</body>
</html>