libvirtd wasn't starting for me and I found this in the logs:
libvirtd: Could not find keytab file: /etc/libvirt/krb5.tab: No such file or directory
after ages tracking down the *real* problem, I realized that the keytab message is a harmless warning
i.e. everything works fine without the keytab, because libvirt isn't even configured to use gssapi ... so we really don't need this unconditional warning
*** Bug 577964 has been marked as a duplicate of this bug. ***
What was the real problem?
(In reply to comment #2)
> What was the real problem?
I had an out-of-date glibc
But that's besides the point - this bug is about the harmless condition being reported as an error in syslog and confusing the hell out of people :)
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
libvirt itself sets filename for keytab to /etc/libvirt/krb5.tab via KRB5_KTNAME variable in initscript/job or /etc/libvirt/libvirt.conf but it doesn't create this file before. cyrus-sasl just warns that this file doesn't exist.
We had never actually attempted to /use/ the Kerberos auth at this point though.
Cyrus-sasl should not spew warning messages to the logs until the point where this non-existant file is actually used, because it misleads the user into thinking there is a problem here.
(In reply to comment #6)
> libvirt itself sets filename for keytab to /etc/libvirt/krb5.tab via
> KRB5_KTNAME variable in initscript/job or /etc/libvirt/libvirt.conf but it
> doesn't create this file before. cyrus-sasl just warns that this file
> doesn't exist.
Would touching that file resolve the problem?
I am able to generate this warning only with gssapi included in mech_list in libvirt.conf.
/etc/init.d/libvirtd contains these lines:
62 KRB5_KTNAME=$KRB5_KTNAME daemon --pidfile $PIDFILE --check $SERVICE $PR OCESS --daemon $LIBVIRTD_CONFIG_ARGS $LIBVIRTD_ARGS
Either check if $KRB5_KTNAME exists or touch $KRB5_KTNAME should work.
> I am able to generate this warning only with gssapi included in mech_list in libvirt.conf.
Hmm, perhaps this can be made NOTABUG/WORKSFORME then. IIUC, the original reporter was apparently seeing this even when 'mech_list=digest-md5' ie no gssapi, which is what was confusing
I get it with the default F17 config which is mech_list: digest-md5
Could we just touch that file and silence the message? Mark can't be the only one confused by it.
No, I don't think we should be touching files for this. If you haven't configured 'gssapi', then the code has no business complaining in the logs.
How do we make the warning go away then? I hope I'm not putting words in Peter's mouth, but it sounds like he doesn't think it should be removed, and we're the ones taking the BZs.
This fundamentally isn't a libvirt problem - the same issue can occur with any app using cryus-sasl, so that's the only place where a fix makes sense. If cyrus-sasl doesn't want to fix it, then users will just have to live with the bogus warning message.
Peter (not Petr), I think we're speculating about when this message appears and where it should be fixed. Dan says this must be fixed in cyrus-sasl; Petr appears to be saying it should be fixed in libvirt. Absent better data about the exact behavior, I can take no position on which is correct. Can you look into this and see if you can produce a minimal application that clarifies the behavior? Thanks, Dave
I've sent a patch to libvirt with an easy workaround:
libvirt-0.9.11.7-1.fc17 has been submitted as an update for Fedora 17.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-0.9.11.7-1.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
libvirt-0.9.11.7-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.