[Sorry for the delay following up on this...]
On 5/14/12 3:32 AM, Jan Zelený wrote:
You are correct. The object is expired but the problem is that your queries
for mock group don't reach SSSD, thus making it unable to refresh the record.
Try getent -s sss group mock, that might do the trick.
A
> 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
> On 5/11/12 10:22 AM, Stephen Gallagher wrote:
> > On Fri, 2012-05-11 at 10:19 -0400, Braden McDaniel wrote:
> >> 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
On 5/11/12 10:22 AM, Stephen Gallagher wrote:
On Fri, 2012-05-11 at 10:19 -0400, Braden McDaniel wrote:
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
On Fri, 2012-05-11 at 10:19 -0400, Braden McDaniel wrote:
> 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 occ
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 inval
On Thu, 2012-05-10 at 18:59 -0400, Braden McDaniel wrote:
> I'll start out by saying that I don't know if sssd is the culprit in my
> problem or not; but if not, I hope someone here with more knowledge of
> the moving parts at play can point me in the right direction.
>
> I have two machines: one
> 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
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
> 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
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
> I'll start out by saying that I don't know if sssd is the culprit in my
> problem or not; but if not, I hope someone here with more knowledge of
> the moving parts at play can point me in the right direction.
>
> I have two machines: one with Fedora 16 and one with the Fedora 17
> prerelease. I
I'll start out by saying that I don't know if sssd is the culprit in my
problem or not; but if not, I hope someone here with more knowledge of
the moving parts at play can point me in the right direction.
I have two machines: one with Fedora 16 and one with the Fedora 17
prerelease. I had initial
13 matches
Mail list logo
