Bug 104585

Summary:	migrate_base.pl broken with dc=X,dc=Y,dc=Z configuration
Product:	Red Hat Enterprise Linux 5	Reporter:	Steve Bonneville <sbonnevi>
Component:	openldap	Assignee:	Jan Zeleny <jzeleny>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.0	CC:	dspurek, lasalle, omoris, rak, rvokal
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	563155 (view as bug list)		Environment:
Last Closed:	2010-03-30 08:05:06 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:
Bug Blocks:	563155, 841533

Description Steve Bonneville 2003-09-17 16:13:09 UTC

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 16:07:47 UTC

Still true in RHEL 3 final openldap-servers-2.0.27-11

Comment 2 Jurvis LaSalle 2005-07-23 20:25:36 UTC

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 19:33:22 UTC

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 20:57:07 UTC

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 Program Management 2007-10-19 19:34:33 UTC

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 19:50:45 UTC

Updated version to RHEL 5.  Problem still exists in openldap-servers-2.3.27-5.

Comment 7 Jan Safranek 2007-10-22 12:32:53 UTC

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 09:51:59 UTC

Patch is in CVS, changing status to MODIFIED.

Comment 11 Ondrej Moriš 2009-11-25 14:24:19 UTC

Bug-fix verified manually on i386 and x86_64 with success.

Comment 12 Ondrej Moriš 2010-02-09 11:56:11 UTC

RHTS test proposed, see QA Whiteboard.

Comment 14 errata-xmlrpc 2010-03-30 08:05:06 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/RHSA-2010-0198.html