Bug 442879

Summary: Kerberos replication problems (RHEL5 master -> RHEL5 slave)
Product: Red Hat Enterprise Linux 5 Reporter: Adam Stokes <astokes>
Component: krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: cward, dpal, ebenes, jplans, k.georgiou, miguel.filho, ohudlick, rryder, sghosh, tao, zmraz
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.6.1-33.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 11:48:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 514741    
Bug Blocks: 513501    
Attachments:
Description Flags
Stash workaround script none

Description Adam Stokes 2008-04-17 11:45:23 UTC
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.

Comment 1 RHEL Program Management 2008-06-02 20:05:37 UTC
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 20:01:42 UTC
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 Program Management 2008-10-27 18:23:08 UTC
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 17:15:18 UTC
(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 18:02:21 UTC
~~ 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 12:58:05 UTC
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 09:13:49 UTC
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-19 03:37:57 UTC
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 11:48:44 UTC
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