- Issue created by @AaronBauman
- πΊπΈUnited States AaronBauman Philadelphia
Appears to be related to π More graceful handling in GroupUserUpdateProcessor on invalid configuration Fixed where a duplicate email address is confusing ldap module and causing a fatal error during cron, killing the whole process.
- πΊπΈUnited States AaronBauman Philadelphia
There is a "timeout" of 10 seconds set up on the LDAP query, but the query appears to run for 60+ seconds and doesn't time out.
I'm running into this issue as well, have about 10,000 users. Running on the latest dev branch that fixes the issue of stopping when email exists, but it will just randomly stop with no logged message every time, after only 5-10 minutes or so. Anyone have any ideas? Thanks
- πΊπΈUnited States bluegeek9
Which 'periodic update' feature are you using?
There is an orphan processor to handle accounts provisioned from LDAP but are no longer in LDAP. "Periodic orphaned accounts update mechanism". This has a limit of the number of users to check, along with a
There is also an update that requires an LDAP query. "Periodic user update mechanism". This one has an interval. What is your interval?
You can also run the cron with drush and not have a timeout.
- πΊπΈUnited States AaronBauman Philadelphia
This is the periodic update feature I'm referring to from
ldap_user_cron()
:function ldap_user_cron() { ... $ldapUpdateQuery = \Drupal::config('ldap_user.settings')->get('userUpdateCronQuery'); if ( \Drupal::moduleHandler()->moduleExists('ldap_query') && $ldapUpdateQuery != NULL && $ldapUpdateQuery !== 'none' ) { /** @var \Drupal\ldap_user\Processor\GroupUserUpdateProcessor $processor */ $processor = \Drupal::service('ldap.group_user_update_processor'); if ($processor->updateDue()) { $processor->runQuery($ldapUpdateQuery); } } }
Specifically,
$processor->runQuery($ldapUpdateQuery);
issues an LDAP query which may not return within various lower-level time limits (between 59 - 120 seconds on Pantheon, for example), which means my users don't get updated.If I lower the time limit for the query, and the query fails to complete in time, then my users still don't get updated.
Is there a way to paginate the LDAP queries, or maybe update the mechanism to look for recent changes only, or another way you can think of that would reduce the footprint here?
- πΊπΈUnited States bluegeek9
It looks like pagination is implemented like this:
use Symfony\Component\Ldap\Ldap; use Symfony\Component\Ldap\Adapter\ExtLdap\Adapter; use Symfony\Component\Ldap\Adapter\ExtLdap\Query; $config = [ 'host' => 'ldap.example.com', 'port' => 389, ]; $adapter = new Adapter($config); $ldap = new Ldap($adapter); $ldap->bind('uid=my_user,ou=users,dc=example,dc=com', 'my_password'); $query = $ldap->query('ou=users,dc=example,dc=com', '(uid=my_user)'); // Enable pagination with a page size of 50. $query->setOption(Query::OPT_PAGINATION_ENABLED, true); $query->setOption(Query::OPT_PAGINATION_SIZE, 50); $results = $query->execute(); foreach ($results as $entry) { echo $entry->getAttribute('cn')[0]; }