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).
From: Lukas Slebodnik <lslebodn(a)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
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
sh# ldbsearch -H /var/lib/sss/db/cache_$domain.ldb '(objectClass=group)' name
And if you have many entries also in sssd cache then you can do some additional
processing in shell ... | sort | uniq -c | grep idNumber
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org