Bug 1028192

Hmm, the fact it works when you specify a particular Kerberos ticket cache *does* suggest something is going wrong with the client trying to read the Kerberos ticket from the default location (I missed that when I first reviewed the bug report).

So we'll have to look into it and try to figure out what changed between F19 and F20 to make the default config break.

(In reply to Nick Coghlan from comment #6)
> Hmm, the fact it works when you specify a particular Kerberos ticket cache
> *does* suggest something is going wrong with the client trying to read the
> Kerberos ticket from the default location (I missed that when I first
> reviewed the bug report).
> 
> So we'll have to look into it and try to figure out what changed between F19
> and F20 to make the default config break.

FWIW, it works for me as in https://bugzilla.redhat.com/show_bug.cgi?id=1028192#c3

(In reply to Amit Saha from comment #8)
> (In reply to Abhishek Koneru from comment #5)
> > Amit,
> > 
> >    Just tried to simulate the same steps as you did, i removed the
> > client.conf and executed the command, but still the same Anonymous access
> > denied message is shown. 
> > 
> >    Are there any specific packages that i need to verify? I just mentioned
> > the ones i thought would be helpful to figure out the problem. The F20
> > machine i use is a VM which i created 2 days back.
> 
> That's rather strange. I have the same kobo version as you. And that is what
> we use to handle the kerberos authentication IIRC. I will try from a freshly
> provisioned VM and update what I see.

Abhishek, I could reproduce this on a Fedora 20 Alpha install updated using 'yum update'. So, it is something we need to look into.

This should be slightly easier to debug with Beaker 0.16, since bkr no longer masks Kerberos exceptions.

Having said that, I cannot reproduce this on Fedora 20 (krb5-libs-1.11.5-2.fc20.x86_64, python-krbV-1.0.90-7.fc20.x86_64). When I log in, KRB5CCNAME=KEYRING:persistent:15550 is set in my environment (not sure whether by pam_sss or systemd or something else). klist shows my ticket cache location as:

Ticket cache: KEYRING:persistent:15550:krb_ccache_DTdGkl1

bkr whoami works correctly when I have a ticket and fails when I do not.

$ bkr whoami
Traceback (most recent call last):
  File "/usr/bin/bkr", line 9, in <module>
    load_entry_point('bkr.client==0.16.0', 'console_scripts', 'bkr')()
  File "/usr/lib/python2.7/site-packages/bkr/client/main.py", line 61, in main
    return cmd.run(*cmd_args, **cmd_opts.__dict__)
  File "/usr/lib/python2.7/site-packages/bkr/client/commands/cmd_whoami.py", line 56, in run
    self.set_hub(**kwargs)
  File "/usr/lib/python2.7/site-packages/bkr/client/__init__.py", line 41, in set_hub
    self.container.set_hub(username, password, auto_login=self.requires_login)
  File "/usr/lib/python2.7/site-packages/bkr/client/command.py", line 277, in set_hub
    self.hub = HubProxy(conf=self.conf, auto_login=auto_login)
  File "/usr/lib/python2.7/site-packages/bkr/common/hub.py", line 62, in __init__
    self._login()
  File "/usr/lib/python2.7/site-packages/bkr/common/hub.py", line 101, in _login
    login_method()
  File "/usr/lib/python2.7/site-packages/bkr/common/hub.py", line 174, in _login_krbv
    cprinc = ccache.principal()
krbV.Krb5Error: (-1765328189, 'No credentials cache found')

Abhishek, are you still able to reproduce this problem? Is KRB5CCNAME set in your environment when you log in? What does klist show as the ticket cache location when you run it without setting KRB5CCNAME? Can you please try beaker-client 0.16.0 and paste the traceback when it fails?

Please re-open if you can still reproduce this problem and can supply the data requested in comment 11.

Sorry for the delay. I am not able to reproduce the issue now. Thanks for the help!