Learn more about these different git repos.
Other Git URLs
SSSD has a hard restriction in the SysDB that only one group can exist with a particular ID.
When a group is renamed on the server, it becomes an order-of-operations issue whether or not we handle it correctly. If we look up the old group name first, we'll see it's removed and delete it from our cache. If we ask for the new group name, we'll get an error attempting to save it to the cache because the IDs will match.
It's well-documented that we don't support multiple entries with the same GID and that doing so will result in unexpected behaviour, so I'd like to recommend the following change:
When we attempt to save a group to the sysdb and the lookup reveals that another group exists already with that GID, instead of failing we should remove the old group. If there actually ARE two groups with the same GID, the effect will be that they'll regularly remove each other, causing a lot more LDAP lookups (and confusing offline access), but this isn't a supported configuration anyway.
In the case that it's actually a rename, we'll handle things much more gracefully.
A similar (if not the same) issue is being tracked in https://fedorahosted.org/sssd/ticket/1040
Fields changed
resolution: => duplicate status: new => closed
rhbz: => 0
milestone: NEEDS_TRIAGE => void
Metadata Update from @sgallagh: - Issue set to the milestone: void
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/2118
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.