On Fri, 2012-05-11 at 09:41 +0200, Jan Zelený wrote:
> 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
> 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.
Well, they did not. And I think that's because I created the mock group
in LDAP *after* installing mock on both systems. (Whoops.)
I then initially created the group in LDAP without realizing that mock
had different GIDs on each system. (Whoops again.)
One thing I'm also curious about is if the user is actually LDAP
user or local
There is no local user "braden" on either system in question:
# cat /etc/shadow | grep braden
If it's a local user, I'd say that might be causing your
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.
I think we're onto something here. The object for my user:
fullName: Braden McDaniel
gecos: Braden McDaniel
... and the object for the mock group:
So, the object for the mock group is out of date with respect to what's
One other idea, try to grep if there is a local group with GID 989,
also be the problem. id -G might give you some more information about this as
Oh, there is. Both systems have a local "mock" group with GID 989.
# cat /etc/group | grep mock
Like "groups", "id" reflects the stale GID:
$ id -G
100 497 988 990
As I mentioned at the top of the thread, I changed the local group GID
on the Fedora 16 installation to 989 (from 990) to match the Fedora 17
installation. Things appear to be working fine on the Fedora 16
installation. (But it occurs to me that if I were to try to join a new
group with GID 990 on the Fedora 16 installation, I might see things go
squirrelly there, too.)
Should I have removed the local mock group on both installations?
Braden McDaniel <braden(a)endoframe.com>