Bug 442879
Summary: | Kerberos replication problems (RHEL5 master -> RHEL5 slave) | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Adam Stokes <astokes> | ||||
Component: | krb5 | Assignee: | Nalin Dahyabhai <nalin> | ||||
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 5.3 | CC: | 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
Adam Stokes
2008-04-17 11:45:23 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. 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 |