Ldap query

[Arran Cudbard-Bell]

> On 10 Mar 2016, at 23:26, Alan DeKok <aland at deployingradius.com> wrote:
> 
> 
>> On Mar 10, 2016, at 5:43 PM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks at sath.nhs.uk> wrote:
>> 
>> Thanks Arran,
>> So it seems that disabling "chase referals" might fix things, it's certainly a huge amount quicker and doesn't sit there binding until timeout. If, as part of the redundant-load-balance module handling, the "downed" server gets called, it waits for a search result from the dead server for the res_timeout figure, and then tries to get back it's required pool amount since it deleted the inviable connection, but it tries the same server.
> 
>  The problem here is interaction between the FreeRADIUS fail-over and the LDAP referrals.  FreeRADIUS assumes that an LDAP server is just an LDAP server.  When AD sends a referral... many things can happen.
> 
>> This is the bit I'd like to understand - it then waits "Connecting to..." for about 75-80 seconds before it idles out all the pooled connections, even if the idle option in mods-enabled/ldap is set to something quite a bit lower like 20 seconds. Is this expected?
> 
>  idle_timeout means "used successfully, and then not used for a while".  If it sits in "connecting to" for 75-80 seconds, you want just a connection timeout.  There should be one in the LDAP module configuration.

It's in the pool {} section.  I went through and standardized it, so it's the same for every module that supports a connection timeout.

It's also documented in the pool section for every module.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160310/ba498c29/attachment.sig>