Before opening a bug report, I wanted to discuss a new issue here.
I have ldap users that are in 1500 groups (yeah, I know ... not my choice either), ldap is using rfc2307 scheme (openldap, redhat EL7).
Now, when connecting sssd to this ldap server, I've already set enumeration=false, and also ignore_group_members=true (performance ...).
However, with ignore_group_members=true, I'm getting this in the sssd_nss.log when doing a 'groups <userid>" command:
[sssd[nss]] [sss_mc_find_record] (0x0010): Corrupted fastcache. name_ptr value is 16
(once when the cache is empty, and after that once or twice per groups-request).
I also see this in /var/log/messages (related of course):
sssd[nss]: Stored copy of corrupted mmap cache in file '/var/lib/sss/mc/group_corrupted#012'
As a result, this prevents the use of the sssd fast cache, so group requests at best take 5.5 seconds.
Now this problem happens 95% of the cases (which leads me to believe it is a timing bug), but when I set ignore_group_members=false, this is not happening (and when groups are ok in the fast cache: 0,03 secs response time).
Ideas? Hints? Or should I just go and open a bug report? Is there a real performance drawback to setting ignore_group_members=false?
I must be doing something stupid but how can I view the schema for the domain cache? A few weeks ago, Sumit helped me update the schemas to add a missing index and fix a case sensitivity issue for the mail attribute?:?
When I went to apply the ldif today, both entries failed as "(Attribute or value exists)". I looked at the yum changelog and I don't see anything that refers to actually having fixed this. What arguments can I feed to ldbsearch to confirm that the changes actually exist (note, I'm completely removing the cache file so it shouldn't exist).
First, sorry if this is easily findable information elsewhere, I did search
but couldn't find anything that seemed relevant .. although I'm not sure I
was searching using proper terminology...
I have SSSD auth semi-working on an Arch system. When it's working, I can
auth against Active Directory, SSH logins work, GDM logins work, sudo
works, id <user> returns full group information, getent seems to work as
expected, polkit appears to work correctly inside og Gnome..everything
seems great. Untill approx ~10 - ~20 minutes passes, and then SSSD seems
to stop authenticating. id <username> returns only the ID, primary group,
and a single other group membership, although correct for the information
it does return. getent passwd <username> seems to work. getent group
<groupname> returns all the users in the group, even though id doesn't list
extended group information anymore. Polkit and SSH stop working. Even
users not previously checked return information in the same shortened way
-- uid, primary gid, and one extended gid. GDM no longer allows logins.
The SSSD process seems to be running ok. Stopping and restarting the SSSD
service, and even rebooting doesn't change anything at this point.
However, if I stop SSSD, delete the [cache?] db (rm /var/lib/sss/db/*) and
restarting sssd brings me back to a fully working state --- again only for
several minutes, and then it's right back to partial information and not
Where do I even start with the troubleshooting? Or is this some known
configuration issue that I've missed?
Thanks in advance.