This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 442879 - Kerberos replication problems (RHEL5 master -> RHEL5 slave)
Kerberos replication problems (RHEL5 master -> RHEL5 slave)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: krb5 (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On: 514741
Blocks: 5.4/TechnicalNotes
  Show dependency treegraph
 
Reported: 2008-04-17 07:45 EDT by Adam Stokes
Modified: 2010-10-22 20:13 EDT (History)
11 users (show)

See Also:
Fixed In Version: 1.6.1-33.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:48:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Stash workaround script (440 bytes, application/x-sh)
2009-07-17 08:58 EDT, Zbysek MRAZ
no flags Details

  None (edit)
Description Adam Stokes 2008-04-17 07:45:23 EDT
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@EXAMPLE.COM, ...)
authenticated client: host/blah.blah@EXAMPLE.COM (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.
Comment 1 RHEL Product and Program Management 2008-06-02 16:05:37 EDT
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.
Comment 2 Nalin Dahyabhai 2008-07-22 16:01:42 EDT
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?
Comment 9 RHEL Product and Program Management 2008-10-27 14:23:08 EDT
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.
Comment 10 Miguel Di Ciurcio Filho 2009-02-13 12:15:18 EST
(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.
Comment 15 Chris Ward 2009-07-03 14:02:21 EDT
~~ 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.
Comment 16 Zbysek MRAZ 2009-07-17 08:58:05 EDT
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.
Comment 22 Zbysek MRAZ 2009-08-03 05:13:49 EDT
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.
Comment 24 Ryan Lerch 2009-08-18 23:37:57 EDT
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.
Comment 25 errata-xmlrpc 2009-09-02 07:48:44 EDT
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

Note You need to log in before you can comment on or make changes to this bug.