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 lslebodn@redhat.com 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org