I did a yum update on my laptop yesterday, and all of the sssd related packages got updated to 1.11.0-1. Since then, when I initially log in, I get this set in my environment: KRB5CCNAME=(null) Note that it's actually setting the value to the string "(null)", not unsetting it in the environment or anything. At that point, I can log out and ssh into the machine, and the shell running under ssh will then *not* have KRB5CCNAME set. I can then log out of gnome-shell and back in and KRB5CCNAME will be set to the correct location. So, my workaround for the time being is to boot the laptop, switch to a VC, log in, ssh into localhost and then log back out. Then I can log into gnome-shell properly. Prior to updating to this version I was running 1.10.0-11.fc19.beta2 and it didn't seem to have this problem. Here are the sss package versions on this host: $ rpm -qa \*sss\* libsss_idmap-1.11.0-1.fc19.x86_64 sssd-krb5-1.11.0-1.fc19.x86_64 sssd-client-1.11.0-1.fc19.x86_64 sssd-ipa-1.11.0-1.fc19.x86_64 sssd-common-1.11.0-1.fc19.x86_64 sssd-1.11.0-1.fc19.x86_64 sssd-proxy-1.11.0-1.fc19.x86_64 python-sssdconfig-1.11.0-1.fc19.noarch sssd-ad-1.11.0-1.fc19.x86_64 sssd-ldap-1.11.0-1.fc19.x86_64 sssd-krb5-common-1.11.0-1.fc19.x86_64
I should also mention that on another machine running 1.10.0-11.fc19.beta2 in the same configuration, it seems to leave $KRB5CCNAME unset on login.
I don't see this behaviour, but granted, I run git HEAD and there's been a bunch of commits that touch the krb5 provider.. Pavel/Lukas, can either of you try with 1.11.0 tomorrow?
(In reply to Jeff Layton from comment #1) > I should also mention that on another machine running 1.10.0-11.fc19.beta2 > in the same configuration, it seems to leave $KRB5CCNAME unset on login. What exactly do you mean by "unset"? Can you paste the output of klist?
(In reply to Jakub Hrozek from comment #3) > (In reply to Jeff Layton from comment #1) > > I should also mention that on another machine running 1.10.0-11.fc19.beta2 > > in the same configuration, it seems to leave $KRB5CCNAME unset on login. > > What exactly do you mean by "unset"? Can you paste the output of klist? My mistake. I had thought that the environment variable wasn't being set at all, but looking now, it's set to: $ env | grep KRB5 KRB5CCNAME=DIR:/run/user/<myuid>/krb5cc ...fwiw: $ klist Ticket cache: DIR::/run/user/4447/krb5cc/tktfFvYF5 Default principal: jlayton Valid starting Expires Service principal 09/22/2013 19:30:26 09/23/2013 05:30:26 krbtgt/REDHAT.COM renew until 09/22/2013 19:30:26 09/22/2013 19:30:29 09/23/2013 05:30:26 imap/mail.corp.redhat.com renew until 09/22/2013 19:30:26 ...which is of course correct. In any case, it seems like something changed between 1.11.0-0.2.beta2 and 1.11.0-1 that made that env var get set improperly on an initial login in some cases.
Right, thanks for checking. If the machine that's exhibiting the NULL behaviour is something you can install test packages on, can you try the packages from: http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo btw when you log in and see the NULL cache, do you log in while connected to the RH VPN (so that SSSD can kinit) or offline (like, resume laptop from sleep and login through GDM before you can connect to VPN)
(In reply to Jakub Hrozek from comment #5) > Right, thanks for checking. If the machine that's exhibiting the NULL > behaviour is something you can install test packages on, can you try the > packages from: > http://jdennis.fedorapeople.org/ipa-devel/ipa-devel-fedora.repo Please note that the packages here are nightly snapshots, so really just something you should install on a test machine (or somewhere you can roll back to a more stable version).
I don't use gnome on my laptop, therefore I tried to reproduce this bug only on virtual machine. After each login, environment variable had value: $ env | grep KRB5 KRB5CCNAME=DIR:/run/user/<myuid>/krb5cc I could not reproduce it. Could you put "debug_level = 0x7770" into domain and pam section (/etc/sssd/sssd.conf)? I hope that log files will contain useful informations. Version of tested software: bash# rpm -qa \*sss\* sssd-tools-1.11.0-1.fc19.x86_64 sssd-proxy-1.11.0-1.fc19.x86_64 sssd-client-1.11.0-1.fc19.x86_64 libsss_idmap-1.11.0-1.fc19.x86_64 sssd-ipa-1.11.0-1.fc19.x86_64 sssd-ldap-1.11.0-1.fc19.x86_64 sssd-krb5-1.11.0-1.fc19.x86_64 sssd-common-1.11.0-1.fc19.x86_64 libsss_nss_idmap-1.11.0-1.fc19.x86_64 sssd-krb5-common-1.11.0-1.fc19.x86_64 python-sssdconfig-1.11.0-1.fc19.noarch sssd-1.11.0-1.fc19.x86_64 sssd-ad-1.11.0-1.fc19.x86_64 bash# rpm -q gdm gdm-3.8.4-2.fc19.x86_64
I think I managed to reproduce the bug, it only ever happens if you log in offline and it's been fixed in the 1.11 branch already which explains why I didn't see the bug with HEAD.. Jeff, here is a scratch build with 1.11.0 + the fixes that made SSSD happily work offline again for me: http://koji.fedoraproject.org/koji/taskinfo?taskID=5970549 Would you mind trying it out?
I'm hitting this bug too since I have to connect to the VPN before the kerberos server is reachable so it's effectively offline. ~]$ klist Ticket cache: FILE:(null) ... ~]$ env | grep KRB KRB5CCNAME=(null) I'l try the koji build in comment 8.
That fixed it for me! Thanks! ~]$ rpm -q sssd sssd-1.11.0-2.fc19.x86_64 ~]$ klist Ticket cache: DIR::/run/user/12345/krb5cc/tkt..... ... ~]$ env | grep KRB KRB5CCNAME=DIR:/run/user/12345/krb5cc After I connect to the VPN, my Kerberos credentials are updated automatically again.
sssd-1.11.0-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/sssd-1.11.0-2.fc19
(In reply to Jakub Hrozek from comment #8) > I think I managed to reproduce the bug, it only ever happens if you log in > offline and it's been fixed in the 1.11 branch already which explains why I > didn't see the bug with HEAD.. > > Jeff, here is a scratch build with 1.11.0 + the fixes that made SSSD happily > work offline again for me: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5970549 > > Would you mind trying it out? Yes! That fixes it for me too. Many thanks!
*** Bug 1010690 has been marked as a duplicate of this bug. ***
Package sssd-1.11.0-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.11.0-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17409/sssd-1.11.0-2.fc19 then log in and leave karma (feedback).
Jeff & Jeff, would you mind adding Karma to the update so that it makes its way to updates proper faster?
sssd-1.11.0-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.