Fields changed

description: Groups a looked up by 'objectSIDString' e.g. during a tokenGroups lookup which is used in the AD provider and in IPA server with trust to AD. Indexing this value would speed up cache lookup, especially for users with many groups and save processing time.

Maybe other attributes would benefit from an indes as well? => Groups a looked up by 'objectSIDString' e.g. during a tokenGroups lookup which is used in the AD provider and in IPA server with trust to AD. Indexing this value would speed up cache lookup, especially for users with many groups and save processing time.

Maybe other attributes would benefit from an index as well?

We should also index the principal attributes, NSS responder uses those to search as well.

Michal, your FQDN refactoring patches need a sysdb upgrade, right? Then maybe we should do the indexing in the same sysdb upgrade to avoid running two upgrade routines..

cc: => mzidek@redhat.com

Yes, that makes sense. I will assign the ticket to me.

owner: somebody => mzidek

Lot of indexes can cause problem with insert, delete.
It would be good to measure result of this change with
"almost" real deployment.

when you say "problems", do you mean delays or issues like broken indexes and missing entries in the index?

I meant that updating many indexes can decrease performance of insert/delete ldb entry. So adding index for 'objectSIDString' might help but adding many attributes can be problematic.

We will need to test performance of this change many AD groups and users.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 alpha

internal only change, no cloning

rhbz: => 0

I think this should be moved to the same milestone as this ticket
#2011 sysdb API is not consistent about the RDN of subdomain users
because it will require sysdb upgrade.

sensitive: => 0

We were wondering with Sumit if it would be possible to not do an upgrade if only the index is added. On upgrade (which is rare) we could fall back to unindexed searches.

I am not sure what will happen if the indexation for an attribute is set after some entries with that attribute are already present in the database... I do not think that LDB will automatically add missing indexes for the entries (which is why I thought the update is needed here), but that is just my guess, I will have to try it and see.

Should not block Alpha

milestone: SSSD 1.13 alpha => SSSD 1.13 beta

Should not block Beta either.

milestone: SSSD 1.13 beta => SSSD 1.13

I had to write the indexing patch because one user was not satisfied with adding the index manually:

https://fedorapeople.org/cgit/jhrozek/public_git/sssd.git/commit/?h=sid_index&id=2302b7f53869db17fe6f733f52cce94d9714eeb4

Feel free to use the patch.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1244950

rhbz: 0 => [https://bugzilla.redhat.com/show_bug.cgi?id=1244950 1244950]

Fields changed

milestone: SSSD 1.13.2 => SSSD 1.13.1
owner: mzidek => jhrozek
priority: major => critical
status: new => assigned

Fields changed

patch: 0 => 1

• master: e61b0e4

resolution: => fixed
status: assigned => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3638

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.