<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6"> </HEAD> <BODY> On Mon, 2013-11-11 at 10:51 +0100, Jakub Hrozek wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Fri, Nov 08, 2013 at 02:42:21PM -0600, Dean Hunter wrote: > On Thu, 2013-11-07 at 22:17 -0500, Dmitri Pal wrote: > > > On 11/07/2013 06:20 PM, Dean Hunter wrote: > > > > > On Thu, 2013-11-07 at 17:41 -0500, Dmitri Pal wrote: > > > > > > > On 11/07/2013 12:59 PM, Dean Hunter wrote: > > > > > > > > > On Thu, 2013-11-07 at 12:36 -0500, Dmitri Pal wrote: > > > > > > > > > > > On 11/07/2013 12:21 PM, Dean Hunter wrote: > > > > > > > > > > > > > On Thu, 2013-11-07 at 09:44 +0200, Alexander Bokovoy wrote: > > > > > > > > > > > > > > > On Wed, 06 Nov 2013, Dean Hunter wrote: > > > > > > > > > > > > > > > > >After building a new VM and configuring the IPA 3.3.2 client, Gnome > > > > > > > > >seems to only perform a local log-in until the system is rebooted. SSH > > > > > > > > >works with IPA, but not Gnome. Is this correct? Is there anything less > > > > > > > > >disruptive than a reboot that I can do? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Restart gdm.service? > > > > > > > > I'm not sure how gdm handles PAM auth. > > > > > > > > > > > > > > > > > > > > > I have tried: > > > > > > > > > > > > > > ipa-client-install ... > > > > > > > systemctl restart gdm.service > > > > > > > > > > > > > > but the behavior remains the same. The Gnome log in screen > > > > > > > accepts the user name, pauses about 25 seconds, then > > > > > > > displays the log in screen again without any messages or > > > > > > > indication of a problem. This is the same behavior I see > > > > > > > when entering an incorrect local user name before > > > > > > > configuring IPA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Freeipa-users mailing list > > > > > > > <A HREF="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</A> > > > > > > > <A HREF="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</A> > > > > > > > > > > > > Can it be a DIR cache issue and the fact that the directory > > > > > > can't is not created at proper time? > > > > > > > > > > > > > > > Which directory, please? > > > > > > > > > > > > If you are hitting the DIR cache issue (which I am not sure is the > > > > case this is why I asked about AVCs) then the directory we are > > > > talking about is /var/run/usr/<uid> > > > > This directory should be created by kerberos library when it tries > > > > to authenticate a user. But it might not be able to since a parent > > > > directory /var/run/usr might not be created yet. This is one of > > > > the reasons why we decided not to continue the path of DIR cache > > > > but switched to using Kernel based ccache. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you see any AVCs? > > > > > > > > > > > > Question still stands. > > > > > > > > > I see no AVCs: > > > > > > [root@ipa ~]# ausearch --message AVC > > > <no matches> > > > [root@ipa ~]# > > > > > > > > > I did find this in the man page for nsswitch.conf: > > > > > > FILES > > > A service named SERVICE is implemented by a shared > > > object library named > > > libnss_SERVICE.so.X that resides in /lib. > > > > > > /etc/nsswitch.conf NSS configuration file. > > > /lib/libnss_compat.so.X implements "compat" > > > source. > > > /lib/libnss_db.so.X implements "db" source. > > > /lib/libnss_dns.so.X implements "dns" source. > > > /lib/libnss_files.so.X implements "files" > > > source. > > > /lib/libnss_hesiod.so.X implements "hesiod" > > > source. > > > /lib/libnss_nis.so.X implements "nis" source. > > > /lib/libnss_nisplus.so.X implements "nisplus" > > > source. > > > > > > NOTES > > > Within each process that uses nsswitch.conf, the > > > entire file is read > > > only once. If the file is later changed, the > > > process will continue > > > using the old configuration. > > > > > > > > > Is this why the default configuration of nsswitch.conf is changing > > > in Fedora 20, as noted on of the preceeding e-mails? > > > > > > > > > > > Yes I think SSS is now included by default. But if man page does not > > list it it is probably a bug in the man page. > > > Hmm, I just built a Fedora 20 Beta VM. /etc/nsswitch.conf is no > different than after a Fedora 19 build. That's weird, what is the glibc version? sss should be automatically added for quite some time, since <A HREF="https://bugzilla.redhat.com/show_bug.cgi?id=867473">https://bugzilla.redhat.com/show_bug.cgi?id=867473</A> was fixed.. </PRE> </BLOCKQUOTE> <TT>[<A HREF="mailto:root@test">root@test</A> ~]# rpm -q glibc</TT> <TT>glibc-2.18-11.fc20.x86_64</TT> <TT>[<A HREF="mailto:root@test">root@test</A> ~]# </TT> <A HREF="https://bugzilla.redhat.com/show_bug.cgi?id=867473">https://bugzilla.redhat.com/show_bug.cgi?id=867473</A> indicates the problem was fixed in Fedora 18. But the problem still occurs for both Fedora 19 and Fedora 20. Should I reopen the bug report? </BODY> </HTML>