Description of problem: Unable to propagate to krb slaves Version-Release number of selected component (if applicable): krb5 1.6.1 How reproducible: 100% Steps to Reproduce: /usr/kerberos/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans /usr/kerberos/sbin/kprop $host /usr/kerberos/sbin/kprop: Software caused connection abort while reading response from server Actual results: This is what I get on the slave: [root@kerberos01 krb5kdc]# /usr/kerberos/sbin/kpropd -d -S Connection from blah.blah.com krb5_recvauth(4, kprop5_01, host/blah.blah, ...) authenticated client: host/blah.blah (etype == DES cbc mode with CRC-32) calling kdb5_util to load database Child PID is 793 load: File exists /usr/kerberos/sbin/kpropd: /usr/kerberos/sbin/kdb5_util returned a bad exit status (1) Expected results: Propagation suceed Additional info: Workaround : scp the slave_datatrans file from the master to the slave. Remove /var/kerberos/krb5kdc/principal* from the slave. Run on the slave: # kdb5_util load /tmp/slave_datatrans This fails, but creates some principal files. Then I ran: # rename '~' '' /var/kerberos/krb5kdc/principal* After this, I ran the DB import again, which succeeded. # kdb5_util load /tmp/slave_datatrans After this, I was able to successfully propagate to the slave and start krb5kdc.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
The problem seems to be that the database lock files aren't present before kdb5_util tries to lock them. Does creating a new dummy database before attempting to load the dumped copy work around this?
This request was previously evaluated by Red Hat Product Management for inclusion in the current Red Hat Enterprise Linux release, but Red Hat was unable to resolve it in time. This request will be reviewed for a future Red Hat Enterprise Linux release.
(In reply to comment #2) > The problem seems to be that the database lock files aren't present before > kdb5_util tries to lock them. Does creating a new dummy database before > attempting to load the dumped copy work around this? I've faced the exactly same problem and creating a dummy database on the slave before running kprop solved the problem.
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
Created attachment 354137 [details] Stash workaround script Found problems in architecture dependent stash file. When copying from one arch to another. This script provided by dev can workaround it by changing first bits of the file. Tested on several architectures.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The format of the stash file, while not architecture-specific, is endian-specific, in that a stash file is not directly portable between big-endian and little-endian systems. When setting up a secondary KDC whose endianness differs from that of the master KDC, the stash file should be recreated by running 'kdb5_util create -s' on the secondary and supplying the original master password. In future releases, the format of this file will be that of a keytab file, and this will not be an issue.
Deleted Release Notes Contents. Old Contents: The format of the stash file, while not architecture-specific, is endian-specific, in that a stash file is not directly portable between big-endian and little-endian systems. When setting up a secondary KDC whose endianness differs from that of the master KDC, the stash file should be recreated by running 'kdb5_util create -s' on the secondary and supplying the original master password. In future releases, the format of this file will be that of a keytab file, and this will not be an issue.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1378.html