8 messages in net.sourceforge.lists.courier-usersRe: [courier-users] ldapaliasd failin...
FromSent OnAttachments
Aleksander AdamowskiFeb 5, 2006 3:10 pm 
Sam VarshavchikFeb 5, 2006 5:03 pm 
Aleksander AdamowskiFeb 6, 2006 9:53 am 
Sam VarshavchikFeb 6, 2006 3:24 pm 
Aleksander AdamowskiFeb 7, 2006 4:34 am 
Gordon MessmerFeb 10, 2006 10:35 am 
Aleksander AdamowskiFeb 12, 2006 12:22 pm 
Gordon MessmerFeb 13, 2006 12:13 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] ldapaliasd failing randomly - continuation of the "authldap failing randomly" threadActions...
From:Gordon Messmer (yiny@eburg.com)
Date:Feb 13, 2006 12:13:38 pm
List:net.sourceforge.lists.courier-users

Aleksander Adamowski wrote:

You're right, unless one configures it to spawn enough processes to cover some temporary spikes in blocking time - so that new authdaemon processes temporarily hold incoming queries until the timeous occur or authentication service is restored.

I don't think that's feasible under the current architecture. IIRC, the documentation specifically notes that authentication modules need to process requests in a minimum amount of time in order to avoid refusing connections to clients.

Off topic, but you could consider using another directory server. The new Fedora DS is quite good, and stores ACIs as attributes in the directory. Among other advantages, this ensures that security settings are replicated like the rest of the data.

I would, if it worked under x86_64.

As far as I know, it does. The site for FDS notes that it is a 32-bit application, but there's no reason that it shouldn't work. It just won't use many GB of RAM.