Wowa, that's easy enough. I will do that the next time that I upgrade
in a few weeks.
Dave
Quoting Timo Sirainen <[EMAIL PROTECTED]>:
On Fri, 2008-11-21 at 14:50 -0500, David Cunningham wrote:
Is there any way to force the cache to
check the password for anything that was not previously ca
On Fri, 2008-11-21 at 14:50 -0500, David Cunningham wrote:
> Is there any way to force the cache to
> check the password for anything that was not previously cached as
> being the correct password?
Nope. Hmm. Perhaps there should be a different TTL for that. I don't
really like adding new sett
I think the last thing you say is exactly what is happening to me. I
think the user is updating the password, but a slight delay in my LDAP
replication is causing them to try the new password before it is
actually the new password.
Yes, I was refering to auth_cache_negative_ttl=0. I did
On Fri, 2008-11-21 at 21:38 +0200, Timo Sirainen wrote:
> On Wed, 2008-11-19 at 22:17 -0500, David Cunningham wrote:
> > Well, most of my issues are gone with adding auth cache. However, I
> > am having an issue. Sometimes, even though cache incorrect passwords
> > is disabled,
>
> Do you m
On Wed, 2008-11-19 at 22:17 -0500, David Cunningham wrote:
> Well, most of my issues are gone with adding auth cache. However, I
> am having an issue. Sometimes, even though cache incorrect passwords
> is disabled,
Do you mean auth_cache_negative_ttl=0 by this? It only affects "user not
fou
No one else with opinions on this?
Dave
Quoting David Cunningham <[EMAIL PROTECTED]>:
Yes, i telnet to port 143 and enter everything manually.
Dave
Quoting Charles Marcus <[EMAIL PROTECTED]>:
On 11/19/2008 10:17 PM, David Cunningham wrote:
Well, most of my issues are gone with adding aut
Yes, i telnet to port 143 and enter everything manually.
Dave
Quoting Charles Marcus <[EMAIL PROTECTED]>:
On 11/19/2008 10:17 PM, David Cunningham wrote:
Well, most of my issues are gone with adding auth cache. However, I am
having an issue. Sometimes, even though cache incorrect passwords
On 11/19/2008 10:17 PM, David Cunningham wrote:
> Well, most of my issues are gone with adding auth cache. However, I am
> having an issue. Sometimes, even though cache incorrect passwords is
> disabled, new passwords do not work. It would seem that once a user
> logs in with one password succes
Well, most of my issues are gone with adding auth cache. However, I
am having an issue. Sometimes, even though cache incorrect passwords
is disabled, new passwords do not work. It would seem that once a
user logs in with one password successfully the cache does not
automatically retry
On Wed, 2008-10-08 at 08:01 -0400, David Cunningham wrote:
> After a few hours of running, I get tons of the following errors in my logs:
>
> dovecot: Oct 08 07:41:50 Error: auth(default):
> ldap([EMAIL PROTECTED],x.x.x.x): Request queue is full
BTW. I improved this error message slightly to al
On Wed, 2008-10-08 at 16:13 -0400, David Cunningham wrote:
> Simply changing auth_cache_size to a non-zero number enables caching, correct?
>
> How big is too big?
If it uses up too much of your memory. Although you'll probably also
need to change auth_process_size then, because by default it kil
Simply changing auth_cache_size to a non-zero number enables caching, correct?
How big is too big?
Where does it cache it?
Here is what I set:
auth_cache_size = 1048576
I was hoping for 1GB worth of cache.
I have 16GB of memory on the system, so memory is not an issue if it
stores it in m
Thank you, I will try the caching.
Dave
Quoting Timo Sirainen <[EMAIL PROTECTED]>:
On Wed, 2008-10-08 at 10:48 -0400, David Cunningham wrote:
I agree. In fact, I may have found a DNS issue that may have been
causing login sessions to hang and thus reach max too quickly. The
last few hours h
On Wed, 2008-10-08 at 10:48 -0400, David Cunningham wrote:
> I agree. In fact, I may have found a DNS issue that may have been
> causing login sessions to hang and thus reach max too quickly. The
> last few hours have been stable. So, I am keeping my fingers crossed.
>
> I have also recompi
Unfortantely, it just happened again!
I am going to implement my increased queue change and see what happens.
Dave
Quoting Jurvis LaSalle <[EMAIL PROTECTED]>:
On Oct 8, 2008, at 8:01 AM, David Cunningham wrote:
After a few hours of running, I get tons of the following errors in
my
David Cunningham schrieb:
>>> I have about 5 Thousand users using horde that login ever 1-5
>>> minutes to refresh their page.
Imapproxy can be configured to cache connections only for a defined
amount of time, eg. close connections not used for more than a few
minutes. Setting is cache_expira
I agree. In fact, I may have found a DNS issue that may have been
causing login sessions to hang and thus reach max too quickly. The
last few hours have been stable. So, I am keeping my fingers crossed.
I have also recompiled dovecot and changed the setting in db-ldap.h
that reads:
#
David Cunningham wrote:
I have about 5 Thousand users using horde that login ever 1-5 minutes to
refresh their page. I assume it is a setting, but I am confused as to
This may not related to the real reason of your problem, but I recommend
up-imapproxy (http://www.imapproxy.org/) for such
Here is my dovecot -n:
# 1.1.3: /etc/dovecot.conf
log_path: /var/log/dovecot
info_log_path: /var/log/dovecot-info
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libex
On Oct 8, 2008, at 8:01 AM, David Cunningham wrote:
After a few hours of running, I get tons of the following errors in
my logs:
dovecot: Oct 08 07:41:50 Error: auth(default):
ldap([EMAIL PROTECTED],x.x.x.x): Request queue is full
I removed the username and IP, obviously.
Any idea how
After a few hours of running, I get tons of the following errors in my logs:
dovecot: Oct 08 07:41:50 Error: auth(default):
ldap([EMAIL PROTECTED],x.x.x.x): Request queue is full
I removed the username and IP, obviously.
Any idea how to stop this?
I have about 5 Thousand users using horde
21 matches
Mail list logo
