Bug 611773

Is it possible to share the contents of your DB files?  We'd like to examine them to figure out how the problem was caused in the upgrade.

If you could attach the output of these command lines or send them to us, it'll be a great help.
dbscan -f /var/lib/dirsrv/slapd-<ID>/db/NetscapeRoot/id2entry.db4
dbscan -f /var/lib/dirsrv/slapd-<ID>/db/NetscapeRoot/ancestorid.db4 -r
dbscan -f /var/lib/dirsrv/slapd-<ID>/db/UnixDB/id2entry.db4
Thanks!

I forgot to mention in my previous request.  I'd like to see the output from the database before running the upgrade (389 v1.2.5).  If you happen to keep the back up of the old version, you could run the above command lines against the corresponding back'ed up db files.
Thanks.

Sure, it's only a test system. Requested data now sent out-of-band.

Created attachment 435082 [details]
output from "setup-ds.pl -u" and "setup-ds-admin.pl -u"

I could not reproduce the problem.

Here's the test steps I took.
1. Installed 389 v1.2.5 with 2 server instances.
   On server A
      o=netscaperoot
      dc=example,dc=com
   On server B
      dc=sub, dc=example,dc=com
1-1. Set up database link (chaining backend) from server A to B on dc=sub,dc=example,dc=com
     Verified that the search with baseDN "dc=sub, dc=example,dc=com" on the server A returns the data
1-2. Set up Single master replication from A to B on o=netscaperoot

2. Installed 389 v1.2.6 (local build from the git trunk)
2-1. setup-ds.pl -u
2-2. setup-ds-admin.pl -u
     The attached file contains the output from the both upgrade scripts.

The recursive ls "ls -R /var/lib/slapd-*/db" shows there are no empty/corrupted db instance dir after the upgrade.

Do you think there could be any other set up/operations I could try to reproduce the problem?

Hello Alexander,

Can we ask you a favour?  We found a bug and the fix is under review:

Bug 619595  - Upgrading sub suffix under non-normalized suffix disappears

We are interested to see if this proposal affects your symptom or not.  If you could reproduce the problem, may we ask you add one more step?

1. Have an older version which contains your original configuration
2. Get 389-ds-base-1.2.6-0.8.rc3.el5.x86_64.rpm from yum repository (e.g., from http://download.fedora.devel.redhat.com/pub/epel/testing/5/x86_64/)
3. Run rpm -U 389-ds-base-1.2.6-0.8.rc3.el5.x86_64.rpm
4. Add this line to /etc/dirsrv/schema/02common.ldif:
attributeTypes: ( 2.16.840.1.113730.3.1.2094 NAME 'nsslapd-parent-suffix' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Netscape' )

The diff looks like this
@@ -145,6 +145,7 @@ attributeTypes: ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY 1.3.6.1.4.1.1466.109
 attributeTypes: ( 2.16.840.1.113730.3.1.3023 NAME 'nsViewFilter' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Netscape Directory Server' )
 attributeTypes: ( 2.16.840.1.113730.3.1.2063 NAME 'nsEncryptionAlgorithm' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'Netscape Directory Server' )
 attributeTypes: ( 2.16.840.1.113730.3.1.2093 NAME 'nsslapd-changelogsuffix' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Netscape' )
+attributeTypes: ( 2.16.840.1.113730.3.1.2094 NAME 'nsslapd-parent-suffix' DESC 'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'Netscape' )
 #
 # objectclasses:
 #

4. Run setup-ds.pl -u
5. Run setup-ds-admin.pl -u

Then, do yo still observe this problem?
> No databases visible in the graphical console, nothing found in LDAP 
> searches, even though it was there before the upgrade. Errors in the 
> log about "reindex" failure.

Thank you for your help in advance.
--noriko

The patch has been pushed - shall we mark this bug as MODIFIED?

(In reply to comment #8)
> The patch has been pushed - shall we mark this bug as MODIFIED?    

Well, we are still not sure the cause is identical or not.  (I'm really hoping so, of course... :)  I'm setting "needinfo".

And in the steps in Comment 7, I found a "bug"...  Please start the servers after 4 and before 5.  (Sorry...)

4. Run setup-ds.pl -u

service dirsrv start
^^^^^^^^^^^^^^^^^^^^

5. Run setup-ds-admin.pl -u

The latest release candidate of 389 v1.2.6 contains this bug fix mentioned in Comment 7.  Could it be possible to upgrade your test server to the latest v1.2.6 and see if your problem still occurs?
Thank you for your help, in advance.

Since we have not received the response for the NEEDINFO request for more than a month, we are closing this bug for now.  Please reopen this bug if the problem happens again.