Bug 485694 - Cross Platform Migration Fails with: Unable to access nsslapd-rundir: Bad address
Cross Platform Migration Fails with: Unable to access nsslapd-rundir: Bad add...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Directory Server
Classification: Red Hat
Component: Migration (Show other bugs)
8.1
All Linux
high Severity high
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
: 427321 (view as bug list)
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2009-02-16 07:19 EST by Jenny Galipeau
Modified: 2015-01-04 18:36 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:10:32 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)
debug output (156.32 KB, text/plain)
2009-02-17 08:11 EST, Jenny Galipeau
no flags Details
cvs commit log (204 bytes, text/plain)
2009-02-17 10:48 EST, Rich Megginson
no flags Details

  None (edit)
Description Jenny Galipeau 2009-02-16 07:19:52 EST
Description of problem:

Environment tested:
RHEL 4 32BIT Directory Server 7.1 --> RHEL 5 32BIT Directory Server 8.1

Running the migrate-ds-admin.pl results in the following error and then hangs:

[root@jennyv4 dirsrv]# /usr/sbin/migrate-ds-admin.pl --cross --oldsroot /opt/redhat-ds --actualsroot /usr/lib/dirsrv General.ConfigDirectoryAdminPwd=Secret123
Beginning migration of Directory and Administration servers from /opt/redhat-ds . . .
Beginning migration of directory server instances in /opt/redhat-ds . . .
Your new DS instance 'slapd-jennyv2' was successfully created.
[13/Feb/2009:15:15:53 -0500] - Unable to access nsslapd-rundir: Bad address
[13/Feb/2009:15:15:53 -0500] - Ensure that user "nobody" has read and write permissions on (null)
[13/Feb/2009:15:15:53 -0500] - Shutting down.



Version-Release number of selected component (if applicable):
8.1

How reproducible:


Steps to Reproduce:
1. Install DS 7.1SP7 RHEL432bit
   Export the backends with db2ldif
   Stop the services
   Tar up /opt/redhat-ds
   Copy the tarball to the RHEL532BIT machine
2. Install DS8.1 on RHEL532BIT
   Untar with -o option (tar -xvof)
   Make sure the ldif backup files are ldifs in /opt/redhat-ds/slapd-instance/db with same name as their backend
   add the original host as alias
3. Run the migration script
  
Actual results:
Unable to access nsslapd-rundir: Bad address
Ensure that user "nobody" has read and write
migration script hangs

Expected results:
Successful migration

Additional info:

Similar bug:
https://bugzilla.redhat.com/show_bug.cgi?id=430368
Comment 1 Jenny Galipeau 2009-02-17 08:11:25 EST
attaching debug output - this attempt was made on Solaris 9 64bit - same machine migration from 7.1 to 8.1.
Comment 2 Jenny Galipeau 2009-02-17 08:11:53 EST
Created attachment 332213 [details]
debug output
Comment 3 Rich Megginson 2009-02-17 10:22:22 EST
Thanks.  This confirms my suspicions - patch on the way.
Comment 4 Rich Megginson 2009-02-17 10:23:20 EST
*** DSMigration.pm.in.~1.25.~	2007-12-13 15:01:46.000000000 -0700
--- DSMigration.pm.in	2009-02-17 08:24:02.000000000 -0700
***************
*** 79,84 ****
--- 79,94 ----
  
  # these are the attributes for which we will always use
  # the new value, or which do not apply anymore
+ # for the next major release e.g. when we support migration from the
+ # current release 1.1.x to 1.2 or 2.0, the old version number will
+ # become quite important for migration - for example, when migrating
+ # from older than 1.1 to 1.1.x, we need to add the attributes in the
+ # table below to the new entry because the attribute didn't exist
+ # at all in the old server version - however, when migrating from
+ # e.g. 1.1.x to 2.0, we must preserve the old value - this means
+ # if the user has deleted the attribute from the entry, we must
+ # "migrate" that deletion by removing the attribute from the new
+ # entry
  my %ignoreOld =
  (
   'nsslapd-errorlog'                => 'nsslapd-errorlog',
***************
*** 91,96 ****
--- 101,109 ----
   'nsslapd-pluginversion'           => 'nsslapd-pluginVersion',
   'nsslapd-plugin-depends-on-named' => 'nsslapd-plugin-depends-on-named',
  # these are new attrs that we should just pass through
+  'nsslapd-allow-unauthenticated-binds' => 'nsslapd-allow-unauthenticated-binds',
+  'nsslapd-saslpath'                => 'nsslapd-saslpath',
+  'nsslapd-rundir'                  => 'nsslapd-rundir',
   'nsslapd-schemadir'               => 'nsslapd-schemadir',
   'nsslapd-lockdir'                 => 'nsslapd-lockdir',
   'nsslapd-tmpdir'                  => 'nsslapd-tmpdir',
Comment 5 Rich Megginson 2009-02-17 10:48:37 EST
Created attachment 332233 [details]
cvs commit log

Reviewed by: nkinder (Thanks!)
Fix Description: Need to add any new attributes added in 8.0 and 8.1 to
the ignoreOld hash table in the migration script.  The way migration
works, it assumes an attribute is supported in both the old version and
the new version.  So if the attribute is absent in the old entry and
present in the new entry, it assumes the user removed the attribute in
the old entry, so removes it in the new entry.  The ignoreOld hash table
holds the list of attributes that we should ignore for the purposes of
attribute comparison.  These are the attributes we just want to pass
through.
Platforms tested: RHEL5
Flag Day: no
Doc impact: no
Comment 6 Rich Megginson 2009-02-17 10:51:58 EST
*** Bug 427321 has been marked as a duplicate of this bug. ***
Comment 7 Jenny Galipeau 2009-03-06 08:11:29 EST
fix verified
Comment 8 Michael Cronenworth 2009-04-20 18:45:04 EDT
This affected me on Fedora 9 going from 1.1.2 to 1.1.3. I had to manually add 'nsslapd-rundir' to my /etc/dirsrv/slapd-name/dse.ldif file before the dirsrv service would start. Should I open a new bug?
Comment 9 Rich Megginson 2009-04-21 11:43:13 EDT
I'm not sure what's happening.  This is what I did:

installed fedora ds 1.1.2 components (ds base 1.1.3, ds admin 1.1.6, etc.) on Fedora 10.  Ran setup-ds-admin.pl.  Confirmed that all services were started correctly.

then did a yum upgrade - which installed the fedora ds 1.1.3 components such as fedora-ds-base 1.2.0 fedora-ds-admin-1.1.7, etc.

ran setup-ds-admin.pl -u

Everything worked fine - I did not see any rundir problems.

What version of fedora-ds-base did you start with?  Any idea?
Comment 10 Michael Cronenworth 2009-04-21 13:20:53 EDT
Before update:
fedora-ds-base-1.1.3-2.fc9.i386
fedora-ds-admin-1.1.6-1.fc9.i386
fedora-ds-dsgw-1.1.1-1.fc9.i386
fedora-ds-console-1.1.2-2.fc9.noarch
fedora-ds-admin-console-1.1.2-1.fc9.noarch
fedora-ds-1.1.2-1.fc9.i386

After update:
fedora-ds-base-1.2.0-2.fc9.i386
fedora-ds-admin-1.1.7-3.fc9.i386
fedora-ds-dsgw-1.1.2-1.fc9.i386
fedora-ds-console-1.2.0-1.fc9.noarch
fedora-ds-admin-console-1.1.3-1.fc9.noarch
fedora-ds-1.1.3-1.fc9.noarch

I had to add "nsslapd-rundir: /var/lib/dirsrv" under cn: config before the "dirsrv" service would start. I was getting the same error "Unable to access nsslapd-rundir: Bad address" until I added that line.
Comment 11 Rich Megginson 2009-04-21 13:31:28 EDT
Had you upgrade from an even earlier version before?  nsslapd-rundir was added in Fedora DS 1.1.0
Comment 12 Michael Cronenworth 2009-04-21 14:29:42 EDT
Yes, my DS is fairly old but I do not remember the first version I used. It may have been prior to 1.1.0. I know it was prior to Fedora 9, was around 2007, and was prior to when the packages were in Fedora.
Comment 13 Rich Megginson 2009-04-21 14:36:09 EDT
Ok.  Just want to make sure this is not a recent problem.  But it is a problem nonetheless.
Comment 14 Chandrasekar Kannan 2009-04-29 19:10:32 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/RHEA-2009-0455.html

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