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
> > 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.

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 
> user.

There is no local user "braden" on either system in question:

        # cat /etc/shadow | grep braden
        [nothing]

> 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.

I think we're onto something here.  The object for my user:

        dn: name=braden,cn=users,cn=default,cn=sysdb
        createTimestamp: 1334532924
        fullName: Braden McDaniel
        gecos: Braden McDaniel
        gidNumber: 100
        homeDirectory: /home/braden
        loginShell: /bin/bash
        name: braden
        objectClass: user
        uidNumber: 1000
        originalDN: uid=braden,ou=people,dc=endoframe,dc=net
        userPrincipalName: bra...@endoframe.net
        krbLastPwdChange: 20120410082059Z
        failedLoginAttempts: 0
        memberof: name=desktop_admin_r,cn=groups,cn=default,cn=sysdb
        memberof: name=ccache,cn=groups,cn=default,cn=sysdb
        memberof: name=users,cn=groups,cn=default,cn=sysdb
        memberof: name=mock,cn=groups,cn=default,cn=sysdb
        originalModifyTimestamp: 20120507040755Z
        ccacheFile: FILE:/tmp/krb5cc_1000_RDDwll
        cachedPassword: [stuff]
        lastCachedPasswordChange: 1336719109
        lastOnlineAuth: 1336719109
        lastLogin: 1336719109
        initgrExpireTimestamp: 1336746661
        lastUpdate: 1336744383
        dataExpireTimestamp: 1336749783
        distinguishedName: name=braden,cn=users,cn=default,cn=sysdb
        
... and the object for the mock group:

        dn: name=mock,cn=groups,cn=default,cn=sysdb
        createTimestamp: 1336282777
        gidNumber: 990
        name: mock
        objectClass: group
        lastUpdate: 1336282777
        isPosix: TRUE
        originalDN: cn=mock,ou=Groups,dc=endoframe,dc=net
        member: name=braden,cn=users,cn=default,cn=sysdb
        memberuid: braden
        dataExpireTimestamp: 1
        distinguishedName: name=mock,cn=groups,cn=default,cn=sysdb

So, the object for the mock group is out of date with respect to what's
in LDAP.

> 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.

Oh, there is.  Both systems have a local "mock" group with GID 989.

        # cat /etc/group | grep mock
        mock:x:989:

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 <bra...@endoframe.com>

_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

Reply via email to