Bug 725542 - Instance upgrade fails when upgrading 389-ds-base package
Summary: Instance upgrade fails when upgrading 389-ds-base package
Alias: None
Product: 389
Classification: Retired
Component: Install/Uninstall
Version: 1.2.9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
Depends On:
Blocks: 434915 639035 389_1.2.9 725912
TreeView+ depends on / blocked
Reported: 2011-07-25 19:45 UTC by Rob Crittenden
Modified: 2015-12-07 17:06 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 725912 (view as bug list)
Last Closed: 2015-12-07 17:06:47 UTC

Attachments (Terms of Use)
0001-Bug-725542-Instance-upgrade-fails-when-upgrading-389.patch (9.83 KB, patch)
2011-07-26 23:04 UTC, Rich Megginson
no flags Details | Diff
0001-Bug-725542-Instance-upgrade-fails-when-upgrading-389.patch (9.70 KB, patch)
2011-07-26 23:06 UTC, Rich Megginson
nhosoi: review+
Details | Diff

Description Rob Crittenden 2011-07-25 19:45:58 UTC
Description of problem:

Installing updated rpm does not upgrade instances.

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


Steps to Reproduce:
1. yum install ipa-server
2. ipa-server-install
3. kinit admin
4. yum -y --enablerepo=updates-testing update 389-ds-base
5. ipa user-add --first=test --last=user testuser
ipa: ERROR: attribute "entryusn" not allowed 
Actual results:

The upgrade seems to be silently erroring out:

# service dirsrv stop
# /usr/sbin/setup-ds.pl -u -s General.UpdateMode=offline
Integer overflow in hexadecimal number at /usr/share/dirsrv/updates/50fixNsState.pl line 51.
Integer overflow in hexadecimal number at /usr/share/dirsrv/updates/50fixNsState.pl line 58.
Invalid type 'Q' in unpack at /usr/share/dirsrv/updates/50fixNsState.pl line 48.

Comment 1 Noriko Hosoi 2011-07-25 20:01:00 UTC
I could reproduce the problem on my 32-bit laptop.

It may not be very accurate, but this diff works around the problem...
# diff  /tmp/50fixNsState.pl.orig  50fixNsState.pl 
<     my $tssecs = ($ts - 0x01B21DD213814000) / 10000000;
>     my $tssecs = $ts / 1000000 - 455204129;

Comment 2 Noriko Hosoi 2011-07-25 21:10:20 UTC
Igmore my previous comment...
0x01B21DD213814000 = 122192928000000000
0x01B21DD213814000 / 10000000 = 12219292800

So, the work around would be:
     my $tssecs = $ts / 1000000 - 12219292800;
     my $tssecs = $ts / 1000000 - 0x2D8539C80;

Comment 3 Rich Megginson 2011-07-26 17:12:13 UTC
Just great - rhel5 32-bit perl is not built with support for long long :-(

Comment 4 Noriko Hosoi 2011-07-26 17:27:57 UTC
(In reply to comment #3)
> Just great - rhel5 32-bit perl is not built with support for long long :-(

Are we filing a bug against 32-bit perl?  I think it's a serious bug for perl users...

Comment 5 Rich Megginson 2011-07-26 17:32:46 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Just great - rhel5 32-bit perl is not built with support for long long :-(
> Are we filing a bug against 32-bit perl?  I think it's a serious bug for perl
> users...

I'll try to find out.  But we may not have a choice - we may have to find a workaround for 32-bit perl

Comment 6 Rich Megginson 2011-07-26 23:04:37 UTC
Created attachment 515383 [details]

Comment 7 Rich Megginson 2011-07-26 23:06:59 UTC
Created attachment 515384 [details]

Comment 8 Rich Megginson 2011-07-26 23:45:21 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   c5bd907..077544c  master -> master
commit 077544cad896413ec32801b565fbe220c91bc04e
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Tue Jul 26 14:46:05 2011 -0600
    Reviewed by: nhosoi (Thanks!)
    Branch: master
    Fix Description: On 32-bit platforms, the pack 'Q' format specifier is not
    available unless perl is explicitly compiled with 64-bit long long support.
    Unfortunately, on RHEL/Fedora platforms, it is not.  Same with native suppor
    for 64-bit values - fortunately, the bigint package is available, so we use
    Additionally, the format flags '>' and '<' for little/big endianness are not
    available on perl 5.8 and earlier, so they are not very portable.  Finally,
    the way we write the 32-bit unique id generator state is simply not usable.
    We already skip it if going from 32-bit to 64-bit, so just ignore it if
    going from 32-bit to 32-bit.  The fix is to unpack the 64-bit integer
    values using two 32-bit values, using 'V' first, then 'N' if we think the
    value might be big-endian (e.g. sparc).  For short values, 'v' or 'n'.
    The 64-bit values are stored with the low part first, followed by the high
    part.  We convert these two 32-bit values to a native 64-bit value to
    perform computations with it, then convert it back to two 32-bit values.
    Then pack the values using the format for the current platform -
    unfortunately we do not use a platform independent way to store the
    nsState values.
    Platforms tested: RHEL6 x86_64 and RHEL5 i386
    Flag Day: no
    Doc impact: no

Comment 10 Rich Megginson 2011-09-12 15:31:30 UTC
Try upgrading from RHEL5 32-bit to RHEL6 32-bit

Comment 11 Sankar Ramalingam 2011-09-22 09:16:19 UTC
Tested upgrade/migration of DS90 from DS8.2 on the listed platforms.

RHEL4-32 to RHEL6-32
RHEL5-32 to RHEL6-32

setup-ds.pl -u, upgraded the instance successfully. Hence marking the bug as verified.

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