Bug 104585 - migrate_base.pl broken with dc=X,dc=Y,dc=Z configuration
migrate_base.pl broken with dc=X,dc=Y,dc=Z configuration
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Zeleny
: Reopened
Depends On:
Blocks: 563155 841533
  Show dependency treegraph
 
Reported: 2003-09-17 12:13 EDT by Steve Bonneville
Modified: 2012-10-15 04:47 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 563155 (view as bug list)
Environment:
Last Closed: 2010-03-30 04:05:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Bonneville 2003-09-17 12:13:09 EDT
Description of problem:

The /usr/share/openldap/migration/migrate_base.pl script doesn't handle
three-part domain component suffixes properly.  Given the following settings:

In /usr/share/openldap/migration/migrate_common.ph
  $DEFAULT_MAIL_DOMAIN="foo.example.com";
  $DEFAULT_BASE="dc=foo,dc=example,dc=com";

In /etc/openldap/slapd.conf
  suffix     "dc=foo,dc=example,dc=com";

...then running migrate_all_offline.sh errors out with
  slapadd: database (dc=foo,dc=example,dc=com) not configured to hold
dn="dc=example,dc=com" (line=5)

If you run migrate_base.pl by itself, the reason becomes clear.  The first two
entries in the LDIF output are:

  dn: dc=example,dc=com
  dc: example
  objectClass: top
  objectClass: domain
 
  dn: dc=foo,dc=example,dc=com
  dc: foo
  objectClass: top
  objectClass: domain

The 'dn: dc=example,dc=com' entry should NOT be generated by the script, for the
same reason that the script does not generate a 'dn: dc=com' entry.

Version-Release number of selected component (if applicable):
  openldap-servers-2.0.27-10
Comment 1 Steve Bonneville 2004-01-19 11:07:47 EST
Still true in RHEL 3 final openldap-servers-2.0.27-11
Comment 2 Jurvis LaSalle 2005-07-23 16:25:36 EDT
it's 2005 and a version of RHEL later (4), and this is still unresolved.  why do you ship these migration 
scripts if they're not robust enough to handle a three level domain name?  weak...
Comment 3 Roger A. Katz 2005-11-02 14:33:22 EST
still true for openldap-servers-2.0.27.20....is there any kind of work around so
I can do a migration
Comment 4 Steve Bonneville 2005-11-16 15:57:07 EST
Roger, you can run the migrate_base.pl migration by hand and then edit the
resulting output to remove the bogus entry, which I believe should be the first
one on the list.  Then manually import the edited LDIF file with ldapadd.
Comment 5 RHEL Product and Program Management 2007-10-19 15:34:33 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.
Comment 6 Steve Bonneville 2007-10-19 15:50:45 EDT
Updated version to RHEL 5.  Problem still exists in openldap-servers-2.3.27-5.
Comment 7 Jan Safranek 2007-10-22 08:32:53 EDT
reported upstream some time ago: http://bugzilla.padl.com/show_bug.cgi?id=236. I
attached a patch there.
Comment 9 Jan Zeleny 2009-11-16 04:51:59 EST
Patch is in CVS, changing status to MODIFIED.
Comment 11 Ondrej Moriš 2009-11-25 09:24:19 EST
Bug-fix verified manually on i386 and x86_64 with success.
Comment 12 Ondrej Moriš 2010-02-09 06:56:11 EST
RHTS test proposed, see QA Whiteboard.
Comment 14 errata-xmlrpc 2010-03-30 04:05:06 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/RHSA-2010-0198.html

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