Interestingly, that returns nothing unusual. Are those files just placeholders in case they are needed? (I've taken this thread way off topic so this will be my last question on this segue).
thanks =G= ________________________________________ From: Lukas Slebodnik <[email protected]> Sent: Wednesday, October 4, 2017 9:30 AM To: End-user discussions about the System Security Services Daemon Subject: [SSSD-users] Re: sssd email login performance EXTERNAL On (04/10/17 13:23), Galen Johnson wrote: >We have millions of entries in the OU and our clients don't see all the >entries since we do filter them on our side (and we don't manage the server >side). It would be nice to be able to find out which users/groups are >affected on our side so we can take that to the admins of the servers. How >would you review the data files in memory cache to see the content? All I get >back is "data" when I run 'file *_corrupted' which isn't exactly useful. I'm >assuming it's used in sssd somehow. Does sssctl have any functionality to >help here? Trying to learn how to fish (so you guys don't have to keep >feeding me :-)). > You might check sysdb cache for colliding UID/GIDs. But IIRC susch situation shoudl be reported also in sssd domain or nss log files with debug level <=4. sh# ldbsearch -H /var/lib/sss/db/cache_$domain.ldb '(objectClass=user)' name uidNumber sh# ldbsearch -H /var/lib/sss/db/cache_$domain.ldb '(objectClass=group)' name gidNumber And if you have many entries also in sssd cache then you can do some additional processing in shell ... | sort | uniq -c | grep idNumber LS _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
