Red Hat Bugzilla – Bug 551764
kpropd fails with /usr/kerberos/sbin/kdb5_util returned a bad exit status
Last modified: 2010-01-14 12:07:44 EST
Description of problem:
Kpropd fails to load database pushed from server
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Use kprop from server (Centos 5) to push a daabase to the Fedora 12 client
2.kpropd receives from_master and tries to update db
3.kdb5_util fails with "kdb5_util: File exists" and kpropd fails with /usr/kerberos/sbin/kdb5_util returned a bad exit status (1)
/usr/kerberos/sbin/kdb5_util returned a bad exit status (1) and kpropd terminates
db updated, no errors
Forgot to mention that I get the same results when I run kdb5_util manually: a
kdb5_util load from_master fails: kdb5_util: File exists
An update with
kdb5_util load -update from_master
If you create a dummy database on the F12 machine first, does the kprop run initiated on the CentOS box succeed? (The locking code used for 'load' doesn't quite do the right thing when there isn't a database there already.)
No, it does not:
[root@travel krb5kdc]# \rm principal*
[root@travel krb5kdc]# kdb5_util create -s
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'FAZANT.NET',
master key name 'K/M@FAZANT.NET'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
[root@travel krb5kdc]# /etc/init.d/kprop restart
Stopping Kerberos 5 Propagation Server: [FAILED]
Starting Kerberos 5 Propagation Server: [ OK ]
Run kprop from Centos here....
[root@travel krb5kdc]# /etc/init.d/kprop status
kpropd dead but subsys locked
using kdb5_util load maunually fails ONLY when principal~ and/or principal~.ok exist. If i rm them, kdb5_util succeeds. What do these files do/mean?
They're the new/temporary principal database and its associated lock file. After the new database is populated (and the new policy database, too), the set are renamed into place. Having leftovers from a previous, unsuccessful, attempt hanging around triggers an error somewhere else.
I've just built krb5-1.7-16.fc13 in koji (http://koji.fedoraproject.org/koji/taskinfo?taskID=1904346) with what I think is the right fix from upstream's development trunk, and it seems to resolve it when I try it here. If it also resolves it for you, I'll add it to the F12 branch.
Sorry, it does not work. kdb5_util leaves all the ~ files, and fails because of their existance the next time. Should kdb5_util remove them?
I rebuilt the src.rpm on f12, just to be sure I would not run into dependency issues with rawhide
I did some more checking, and here is what I found:
so the directory does not contain any ~ files
kdb5_util load from_master
leaves some ~ files:
[root@travel krb5kdc]# ls *~*
A second kdb5_util chokes on the principal~.kadm5 file as shown in the strace output (see attachment)
The second kdb5_util command leaves more ~files:
[root@travel krb5kdc]# ls *~*
principal~ principal~.kadm5 principal~.kadm5.lock principal~.ok
Created attachment 382110 [details]
This is the strace output of the second (failed) kdb5_util invocation
Created attachment 382111 [details]
This is the strace of the first kdb5_util invocation
Okay, that means I missed part of the upstream fix when I pulled it down from trunk, which doesn't have this problem. Simplest alternative is to pull up the fix from the pending enterprise update. Please give 1.7-17.fc13 from http://koji.fedoraproject.org/koji/taskinfo?taskID=1906159 a try.
This works! Thanks for the help!
ok, correction: it works under strace and if selinux is in permissive mode. In enforcing mode it still fails. /var.log/messages says the following:
Jan 7 22:06:18 travel kpropd: Connection from nest.pheasant
Jan 7 22:06:20 travel kpropd: /usr/kerberos/sbin/kpropd: /usr/kerberos/sbin/kdb5_util returned a bad exit status (2)
but the audit log does not show any AVCs....
Still continuing the search for what is happening. There is progress, but how to find the selinux issue?
False alarm: a restorecon -v in /var/kerberos/krb5kdc solved the issue. I just don't understand why I did not get any AVCs, but who cares
krb5-1.7-18.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
Closing. Please reopen if this crops up again.