[Cubicweb] LDAP + Apache integration

Dimitri Papadopoulos Orfanos dimitri.papadopoulos at cea.fr
Thu Nov 5 14:37:52 CET 2015


Le 05/11/2015 10:02, Julien Cristau a écrit :
>> [...]
>> * Our experience is that Cubicweb freezes for about 10 seconds while it
>> syncs with the "ldapfeed" source. This is not acceptable in a production
>> environment. As a workaround we have increased the synchronization
>> frequency from 1 minute to 30 minutes. Is the freeze expected? Do you
>> have a suggestion on what to try/modify? We have ~100 accounts in the
>> LDAP, this is really far from a large LDAP database!
> I'm not sure why source sync would cause an UI freeze, it doesn't really
> make sense to me.  What I would suggest however is to set the source
> config's synchronize option to false, and run "cubicweb-ctl source-sync
> <instance> <name of the ldap source>" from cron or equivalent.  That way
> the source sync happens in a separate process from the web interface,
> and won't affect its responsiveness.

I haven't looked into the freeze myself. I'll see if we can provide more
detailed information and factual measurements of the "internal" sync.
I've tried the external sync with an LDAP database of ~ 150 accounts:
	$ time cubicweb-ctl source-sync imagen imagen
	real	0m7.712s
	user	0m5.516s
	sys	0m0.224s
I do find this a bit slow, but then I don't really care if it has no
effect on operations.

>> * After creating the account in LDAP and *before* Cubicweb syncs with
>> the relevant "ldapfeed" source, users are of course not recognized and
>> are typically greeted by a an "unknown user" banner. This is a real
>> problem if the delay is 30 mins, still a problem (though less acute)
>> when the delay is 1 min. Do you have suggestions on how to gracefully
>> handle this?
> The above should let you reduce the delay, at least.  Maybe there's also
> a way for you to trigger a source-sync run when your administrators
> validate an account?

As a short term solution, we will have Apache filter out user accounts
for which a specific LDAP attribute (for example employeeType) has not
been set to a specific value, or has not been made member of a specific
group. The specific attribute or group membership will be triggered
either manually or maybe by a Cubicweb hook when LDAP is sync'ed.

My colleagues have learned in the process that Apache itself seems to be
maintaining a cache of LDAP information (with a default delay of 1 min
on our system) as do Linux systems. So that's not specific to Cubicweb.

>> * When Cubicweb eventually syncs with the "ldapfeed" source, *after* a
>> failed attempt at accessing the application before the sync, the
>> relevant new account remains forever de-activated. We have to manually
>> delete it and let it be re-creatd again:
>>   rset = rql("DELETE CWUser U WHERE U login 'user_login'")
>>   session.commit()
>> Is this expected? Shouldn't the account be activated after the LDAP
>> sync? Should I open a ticket in the forge?
> That sounds like a bug, possibly specific to your application, I haven't
> seen anything like that, so it would need some investigation.

Right, since we will try to avoid the problem by filtering at the Apache
level as long as the accoutn has not been sync'ed to Cubicweb, we will
probably won't be able to investigate on our side.

Dimitri Papadopoulos
I2BM, NeuroSpin
F-91191 Gif-sur-Yvette cedex, France

More information about the Cubicweb mailing list