On 4 May 2016, at 09:25, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
If you want visibility into what's going on, it's better to use a template section to configure rlm_ldap, and have one instance per server, referencing them in a redundant-load-balance block.
ldap ldap1 {} ldap ldap2 {}
etc - could all be in one file....
and then use the redundancy load balance block to use them:
redundant-load-balance { ldap1 ldap2 ldap3 }
instead of just calling ldap ?
It's the better way. I've been really tempted to remove support for multiple servers because of how they would mess up the connection pool stats. But... The final design for rlm_ldap involves multiple connection pools, so that we can deal with referrals better. When used with referrals, it would be useful to be able to pre-establish connections to the hosts that may be referred to, so allowing multiple server config items would be better. We'd also then have different pools for each server, so the stats would work ok...
interesting....might give that a go (our current problem is that we set the lifetime/timeout to 0 and it appears that after *seme time* (to be found out) and/or *some event* the server will not connect to the LDAP anymore... it shouldnt have closed connections....)
1) maybe need some kind of keepalive thing going on in the server (to ensure firewalls or linux kernel TCP stuff doesnt play in this?)
Yeah, that'd be my guess, but libldap does allow the TCP keepalive stuff to be tweaked. #ifdef LDAP_OPT_X_KEEPALIVE_IDLE { FR_CONF_OFFSET("idle", PW_TYPE_INTEGER, rlm_ldap_t, keepalive_idle), .dflt = "60" }, #endif #ifdef LDAP_OPT_X_KEEPALIVE_PROBES { FR_CONF_OFFSET("probes", PW_TYPE_INTEGER, rlm_ldap_t, keepalive_probes), .dflt = "3" }, #endif #ifdef LDAP_OPT_X_KEEPALIVE_INTERVAL { FR_CONF_OFFSET("interval", PW_TYPE_INTEGER, rlm_ldap_t, keepalive_interval), .dflt = "30" }, #endif Consult libldap docs for what each of those options actually do.
2) more connection info with eg radmin ?
Yes, in v3.1.x I added per connection pool statistics with high/low triggers. Need to finish plumbing that in, but we now have stats internally on how long a connection was reserved for. It's not necessarily how long an operation took, there may be multiple operations per connection reservation, but it does let you identify when things are moving towards some sort of nasty meltdown.
by the way, we are using OpenLDAP compiled against OpenSSL rather than NSS - which was the default stuff....
Yeah, known problem with NSS/libldap/FreeRADIUS. We always have to build our own for RHEL, it's a bit of a pain.
when we did that (use our own LDAP compiled against OpenSSL) the reconnection after deliberately breaking connectivity worked a treat! :)
Great :) Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2