Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add logs in case some users are ignored and aren't returned #104

Closed
wants to merge 2 commits into from

Conversation

jvillafanez
Copy link
Member

Log more errors for owncloud/core#28039

$this->access->connection->writeToCache($cachekey, $ldap_users);
return $ldap_users;
$this->access->connection->writeToCache($cachekey, $ldap_users2);
return $ldap_users2;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to find a way to both:

  1. return just the "good" subset of users (like here); and
  2. return the count of all users in this "batch" $ldap_users_count (or a boolean to say if $limit users were found)
    So that the caller can know when this may not be the last "batch".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't seem possible. Core asks for 500 users and LDAP is returning less. Returning more information from LDAP is useless at the moment because that info won't be used by core.

On the other hand, core needs to handle other backends. The condition to decide whether keep fetching users or not is pretty clear: if core asks for 500 users and 500 users are returned, there could be more users, otherwise it's the last bunch. This way we don't need to count how many users there are, since this is time-consuming specially for LDAP (we need to fetch all the entries)

In addition, if someone asks core for 500 users it should return 500 users. This means that if the backend returns less, core should ask for more. For LDAP, LDAP will need to fetch the next 500 users even though we might only need a few of them (I don't think we can change the page size during a search) which will require complex handling.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that if this method gets 500 users and only 498 of them are "good" then it could query again for the next users, and put the first 2 good ones into the array to return to the caller.
But then when it is called in future with some offset, it needs to know how to adjust that to also skip the "non-good" users that were in previous batches.
And of course this whole thing can be a problem if users are being added or deleted on the LDAP server between query batches - then where the oC end thinks it is up to will be out-of-alignment with LDAPs current set of users.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with the account table getUsers is only used during sync and during login via saml / shibboleth. for the sync case the OutOfBoundsExceptions are a better way to notify core of preblems with accounts. For the saml login this also works, so I'll close this PR.

@PVince81
Copy link
Contributor

PVince81 commented Jul 4, 2017

@jvillafanez finish this ? add review label ?

@jvillafanez
Copy link
Member Author

nothing more to add

$ldap_users_count = count($ldap_users);
$ldap_users2_count = count($ldap_users2);
if ($ldap_users_count !== $ldap_users2_count) {
\OCP\Util::writeLog('user_ldap', "getUsers: fetched $ldap_users_count users but returned $ldap_users2_count", \OCP\Util::ERROR);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we need better message here - i doubt that anybody can do anything reasonable based on this message.
Me personally have no clue on what to do ..... 😕

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new log from the lib/Access file should also pop up, which should help to identify the missing entries. Anyway, I'm opened to suggestions.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'LDAP unable to find user mappings for all the users returned by the search'

@tomneedham
Copy link
Contributor

@jvillafanez can you rebase and update the comment and then we can get this in :)

@tomneedham
Copy link
Contributor

@DeepDiver1975 new review. And looks like it needs a rebase @jvillafanez

@jvillafanez
Copy link
Member Author

Rebased

@PVince81
Copy link
Contributor

PVince81 commented Aug 7, 2017

@DeepDiver1975 @tomneedham second review ?

@tomneedham
Copy link
Contributor

Rebasing..

@tomneedham
Copy link
Contributor

During rebase I realised that the getUsers method has been rewritten - @jvillafanez can you reevaluate whether this PR is still necessary and if so where the code should now reside?

@@ -651,6 +651,8 @@ private function ldap2ownCloudNames($ldapObjects, $isUsers) {
? $ldapObject[$sndAttribute][0] : '';
$this->cacheUserDisplayName($ocName, $nameByLDAP, $sndName);
}
} else {
Util::writeLog('user_ldap', "Setting the owncloud name for LDAP entry {$ldapObject['dn'][0]} isn't possible", Util::ERROR);
Copy link
Member

@butonic butonic Nov 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

logging now done when the OutOfBounds exception in https://github.com/owncloud/user_ldap/blob/master/lib/User/UserEntry.php#L106-L110 is finally logged. Also see owncloud/core#28805 to allow skipping of "broken" users during sync

@butonic butonic closed this Nov 13, 2017
@butonic butonic deleted the more_logs branch November 13, 2017 09:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants