Use binary search for finding a new UID #36

Closed
opened 1 year ago by merenber · 0 comments
Owner

Currently, creating a new user with ceo on the CSC machines is quite slow. I suspect that the culprit is the _get_next_uid function in LDAPService.py, where we check every single UID from members_min_id until the next available UID.

We have a couple thousand records in our LDAP, so as you can imagine, this takes a very long time. It's also kind of dangerous to use pwd and grp because if a user was recently deleted, their entry will still be cached by nslcd, which can lead to all sorts of problems.

We should use binary search instead of linear search when trying to find the next available UID. This should be OK as long as we don't leave "gaps" in the UID number space (which I don't think we've ever done). When checking whether a UID number is available, we should always check LDAP directly (so we shouldn't be using pwd and grp anymore).

Currently, creating a new user with ceo on the CSC machines is quite slow. I suspect that the culprit is the `_get_next_uid` function in LDAPService.py, where we check *every single* UID from members_min_id until the next available UID. We have a couple thousand records in our LDAP, so as you can imagine, this takes a very long time. It's also kind of dangerous to use `pwd` and `grp` because if a user was recently deleted, their entry will still be cached by nslcd, which can lead to all sorts of problems. We should use binary search instead of linear search when trying to find the next available UID. This *should* be OK as long as we don't leave "gaps" in the UID number space (which I don't think we've ever done). When checking whether a UID number is available, we should always check LDAP directly (so we shouldn't be using `pwd` and `grp` anymore).
merenber closed this issue 1 year ago
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: public/pyceo#36
Loading…
There is no content yet.