On 2012-10-19 11:39, Alexander Hartmaier wrote: > On 2012-10-19 11:01, Heikki Vatiainen wrote: >> On 10/18/2012 06:33 PM, Alexander Hartmaier wrote: >> >>> I've upgraded the radiator servers from 4.8 to 4.10 with current patches >>> in hope of a fix but it still shows the same behaviour: >>> >>> Sometimes it works: >>> Thu Oct 18 12:41:42 2012: INFO: Connecting to 10.1.2.1 10.1.2.2:636 >>> Thu Oct 18 12:41:42 2012: INFO: Attempting to bind to LDAP server >>> 10.1.2.1 10.1.2.2:636 >>> >>> Sometimes it doesn't: >>> Thu Oct 18 13:38:43 2012: INFO: Connecting to 10.1.2.1 10.1.2.2:636 >>> Thu Oct 18 13:38:49 2012: ERR: Could not open LDAP connection to >>> 10.1.2.1 10.1.2.2:636. Backing off for 5 seconds. >>> >>> BTW the debug output is really puzzling when you configure more than one >>> server/ip-address and should be changed to only show the server/ip >>> that's used to try the connection! >> The reference manual talks briefly about this: >> >> ... Multiple space separated host names can be specified >> and Net::LDAP will choose the first available one. ... >> >> What happens is radiusd passes all hosts to Net::LDAP which then uses >> its own methods for trying to contact the hosts. For this reason the log >> entry sort of makes sense. In other words, specifying multiple names or >> addresses for Host can be useful, but it takes some of the control away >> from radiusd. >> >> If you want full control for contacting LDAP servers, you can specify >> two AuthBy LDAP2 clauses both with just a single Host. When there's a >> connection or query problem, the AuthBy will return IGNORE and the >> default AuthByPolicy (ContinueWhileIgnore) will then switch to the next >> AuthBy. >> >> AuthBy LDAP2 also support FailureBackoffTime. In case of error, the >> failed AuthBy LDAP2 clause will be left alone to recover for the >> specified time. >> >>> That's our config: >>> >>> <AuthBy LDAP2> >>> # Save time by never looking for a default >>> NoDefault >>> >>> Host 10.1.2.1 10.1.2.2 >>> Port 636 >> Here Net::LDAP will take care of retrying, timeouts etc. until all hosts >> have been tried. >> >> >> Thanks, >> Heikki >> > Thanks for the explanation, can you add this to the manual in all places > where multiple servers can be configured? > > In the meantime I've upgraded Net::SSLeay from version 1.32 to CPANs > current 1.49 on this RHEL4 box which seems to have fixed the problem. > I'll get back to you if the problem occurs again. The problem still persists. Is such an issue known to you for RHEL4 maybe?
> -- > Best regards, Alexander Hartmaier > > > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* > T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien > Handelsgericht Wien, FN 79340b > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* > Notice: This e-mail contains information that is confidential and may be > privileged. > If you are not the intended recipient, please notify the sender and then > delete this e-mail immediately. > *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator