Gordon Messmer wrote:
For local clients, the return will be slightly greater. However, as
far as I understand it, the logic would really need to be introduced
into all of the processes that use authdaemon, rather than in
authdaemon itself. If authdaemon begins blocking, the other processes
will very quickly be unable to connect to it, and will have to inform
the clients of failure. You won't have solved the problem.
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.
With that in mind, I'm not personally concerned about Courier's
behavior enough to modify it. If you are, the modifications required
for each service are likely to be substantially similar. Give it a shot.
If I have time, I'll do it. Not likely in the nearest future, though :(
* a change to access permissions to the OpenLDAP directory requires
restart of slapd (silly, but true :( ), which causes a 2-4 seconds
LDAP downtime
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.
--
Best Regards,
Aleksander Adamowski
GG#: 274614
ICQ UIN: 19780575
http://olo.ab.altkom.pl
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
