Description of problem: Kpropd fails to load database pushed from server Version-Release number of selected component (if applicable): krb5-server-1.7-10.fc12.x86_64 How reproducible: 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) Actual results: /usr/kerberos/sbin/kdb5_util returned a bad exit status (1) and kpropd terminates Expected results: db updated, no errors Additional info:
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 succeeds
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' 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 but: 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: cd /var/kerberos/krb5kdc \rm *~* so the directory does not contain any ~ files kdb5_util load from_master leaves some ~ files: [root@travel krb5kdc]# ls *~* principal~.kadm5 principal~.kadm5.lock 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[1042]: Connection from nest.pheasant Jan 7 22:06:20 travel kpropd[1042]: /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.