Bug 789094

Upstream ticket:
https://fedorahosted.org/389/ticket/309

Did you upgrade from 32-bit to 64-bit?
What version of perl are you using?
Can you provide the output of
perl -V
?

I tried to reproduce by going from 1.2.8.3 -> 1.2.10.3 - it worked - it did not change the value from 0200000000000000ddd92f4f00000000000000000000000001000000000000000100000000000000 to 0200000000000000ddd92f4f00000000000000000000000000000000000000000100000000000000

What should happen is this:

during yum/rpm upgrade, the %posttrans script does this:
shutdown all servers
run setup-ds.pl -u in offline mode - this should fix nsState and update the value directly in the dse.ldif
start up the servers

then, after yum upgrade, when you run setup-ds-admin.pl -u, the value should already have been fixed, so nothing should be done

So I'm not sure why it is trying to update the value in setup-ds-admin.pl -u

No, no upgrades here.  We started with a fresh install of RHEL6 and installed 389-ds 1.2.8.3 on it.  (We had rolled our own from the rhel5 srpms initially, FYI in our own koji instance.)

perl-5.10.1-119.el6_1.1.x86_64

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
   
  Platform:
    osname=linux, osvers=2.6.18-274.3.1.el5, archname=x86_64-linux-thread-multi
    uname='linux hs20-bc2-5.build.redhat.com 2.6.18-274.3.1.el5 #1 smp fri aug 26 18:49:02 edt 2011 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl -Dinc_version_list=5.10.0 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.4.5 20110214 (Red Hat 4.4.5-6)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector'
    libpth=/usr/local/lib64 /lib64 /usr/lib64
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.12'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
                        PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL
                        USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES
                        USE_PERLIO USE_REENTRANT_API
  Built under linux
  Compiled at Oct  4 2011 10:53:24
  @INC:
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5
    .


The only reason I tried to run it by hand is that I noticed that the version in the console was still 1.2.8.3 (and still is even after running it by hand + removing that file to get it to work- but that's a different issue).

If you can't reproduce, feel free to close as WORKSFORME.

(In reply to comment #4)
> No, no upgrades here.  We started with a fresh install of RHEL6 and installed
> 389-ds 1.2.8.3 on it.  (We had rolled our own from the rhel5 srpms initially,
> FYI in our own koji instance.)
> 
> perl-5.10.1-119.el6_1.1.x86_64
> 

ok - does not appear to be perl related

> 
> 
> The only reason I tried to run it by hand is that I noticed that the version in
> the console was still 1.2.8.3 (and still is even after running it by hand +
> removing that file to get it to work- but that's a different issue).

So you started with RHEL6 - then installed your own 1.2.8.3 built from srpm - then did a yum upgrade to 1.2.9.14?

I'm trying to figure out if the upgrade to 1.2.9.14 ran the setup-ds.pl -u while the servers were offline and, if so, why it did not fix nsstate.

The issue is that setup-ds-admin.pl -u must run while the servers are online, and nsState cannot be modified while the servers are online.

You might be able to do this:
shutdown all servers
run setup-ds.pl -u in offline mode
startup all servers
run setup-ds-admin.pl -u

> 
> If you can't reproduce, feel free to close as WORKSFORME.

So far I can't, but I feel I must not be doing exactly what you did.

Looking at the /var/log/yum.logs the history is a little more complicated than I remember: 1.2.7.5 -> 1.2.8.1 -> 1.2.8.3 -> 1.2.9.14.

We have Spacewalk running and pushing out updates automatically, so some 389 packages were updated without me noticing for a few days.  I'm guessing the update scripts were ran properly (although they may have barfed about the nsState then, too).  A look at the rpm scripts says that the upgrade would have stopped, upgraded, started 389.

Again, the only real reason I attempted to (re-?)run the upgrade script was the annoying little Version string in the console that still says 1.2.8.3.  As somewhat of a perfectionist this bothers me :)  If you can't reproduce any of these things then I am perfectly okay with closing this out.