[SSSD] Cached user info?
Jan Zelený
jzeleny at redhat.com
Fri May 11 07:41:18 UTC 2012
> On Fri, 2012-05-11 at 09:10 +0200, Jan Zelený wrote:
> > > On Fri, 2012-05-11 at 08:38 +0200, Jan Zelený wrote:
> > > > I guess SSSD cache is probably the reason why you still have the old
> > > > GID. Try running sss_cache -G to invalidate all groups and if you
> > > > have queried SSSD for that group in last few minutes, wait for the
> > > > client in-memory cache to expire as well (or you can just restart
> > > > SSSD).
> > >
> > > Sounds promising... but I tried that (as well as -U and -N), restarted
> > > sssd, logged out and logged back in... and still the user appears to be
> > > a member of pulse-access (rather than mock).
> >
> > And when you run getent group mock, the GID is correct or still wrong?
>
> $ getent group mock
> mock:x:989:
>
> That's correct (that is, it's consistent with that's in LDAP); but it
> was correct before, too.
Ah, sorry for that, I guess I misunderstood.
When I return to the beginning: first of all I'm not sure what do you mean by
your two installations having different GID for group mock - if they both use
SSSD + the LDAP server, they should both have the same GID.
One thing I'm also curious about is if the user is actually LDAP user or local
user. If it's a local user, I'd say that might be causing your problems. If
it's LDAP user, could you try to run ldbsearch -H
/var/lib/sss/db/cache_<sssd_domain_name>.ldb and paste me the object
representing the user? You can also look if there is a group object with GID
990 just to be sure.
One other idea, try to grep if there is a local group with GID 989, that might
also be the problem. id -G might give you some more information about this as
well.
Thanks
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20120511/1415280f/attachment.sig>
More information about the sssd-devel
mailing list