[389-devel] Re: Please review (additional fixes): [389 Project] #48755: moving an entry could make the online init fail

On 06/17/2016 09:16 PM, Noriko Hosoi wrote:

On 06/17/2016 08:49 AM, Ludwig Krispenz wrote:

On 06/17/2016 05:31 PM, Noriko Hosoi wrote:

On 06/17/2016 12:17 AM, Ludwig Krispenz wrote:

Hi Noriko,

I still have a doubt on your fix. You now base the entries to be sent only on the parentid index, but when creating a tombstone, the entry is removed from the parentid index. So you will miss the tombstones in the total init.

Well, I don't think a tombstone entry is removed from the parentid index...

but in ldbm_back_delete() we remove the entryID from all inexes and if create_tombstone_entry add it back to specific indexes

This is an example of a tombstone in id2entry.db

id 16
        rdn: nsuniqueid=bd90578a-2f6311e6-9346e70f-8f7f52e7,uid=tuser0
        entryid: 16
        parentid: 20

This is the corresponding item on parentid.db.  The entry 16 is still there as a child of parent id 20...
# dbscan -f parentid.db -k =20 -r -n
=20                                     3
    10 16 19

was dbcache already flushed to disk when you did run dbscan ? I get
dn: nsuniqueid=bd76ad01-322c11e6-a5389989-c3cc84f8,cn=x,ou=People,dc=example,dc=com
entryid: 30
parentid: 2

dn: cn=y,ou=People,dc=example,dc=com
entryid: 31
parentid: 2

 dbscan -f /var/lib/dirsrv/slapd-elkris3/db/example/parentid.db -k =2 -r -n
=2                                      1
    31

I have a question about your tombstone entry...  You are using entrydn instead of entryrdn?

no, sorry for the confusion, I was using ldapsearch to get teh tombstones, not dbscan

> dn: nsuniqueid=bd76ad01-322c11e6-a5389989-c3cc84f8,cn=x,ou=People,dc=example,dc=com
> entryid: 30
> parentid: 2

Is that the default configuration for IPA?  Does that mean IPA has no move issue?

  27 ldbm_back_delete( Slapi_PBlock *pb )
 781         if(create_tombstone_entry)
 903             if (entryrdn_get_switch()) /* subtree-rename: on */
 907                 /* To maintain tombstonenumsubordinates,
 908                  * parentid is needed for tombstone, as well. */
 913                     retval = index_addordel_values_sv(be, LDBM_PARENTID_STR,
 914                                                       svals, NULL, e->ep_id,
 915                                                       BE_INDEX_ADD, &txn);

But in that case total update is supposed to have no change...

313 repl5_tot_run(Private_Repl_Protocol *prp)
441     if (is_entryrdn) {
                // NEW BULK IMPORT
493     } else {
494         /* Original total update */
    [...]
525     }

Thanks,
--noriko

Besides, the tombstone entry is found on the consumer server after the total update/bulk import...
# ldapsearch [...]  -b "dc=example,dc=com" "(|(objectclass=nstombstone)(objectclass=ldapsubentry))" dn
dn: cn=repl keep alive 10000,dc=example,dc=com
dn: nsuniqueid=bd90578a-2f6311e6-9346e70f-8f7f52e7,uid=tuser0,ou=ou3,dc=example,dc=com
[...]

But obviously there are still issues, with which it does not pass the IPA CI test...  Continue looking into it...

Thanks,
--noriko

Ludwig

On 06/17/2016 03:05 AM, Noriko Hosoi wrote:

https://fedorahosted.org/389/ticket/48755

https://fedorahosted.org/389/attachment/ticket/48755/0001-Ticket-48755-moving-an-entry-could-make-the-online-i.3.patch

git patch file (master) -- additional fix to the server patch

https://fedorahosted.org/389/attachment/ticket/48755/0002-Ticket-48755-CI-test-test-case-for-ticket-48755.3.patch
git patch file (master) -- additional test case to the CI test patch

I also built copr build including the patch:
https://copr.fedorainfracloud.org/coprs/nhosoi/389-ds-base-1.3.5.7.f24/builds/

Martin, could it be possible to use this tentative build in the IPA acceptance test?  (I don't want to break IPA again...)

Thanks!
--noriko

--  389-devel mailing list  389-devel@lists.fedoraproject.org  https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org  

--   Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,   Commercial register: Amtsgericht Muenchen, HRB 153243,  Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander

--  389-devel mailing list  389-devel@lists.fedoraproject.org  https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org  

--  389-devel mailing list  389-devel@lists.fedoraproject.org  https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org  

--   Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,   Commercial register: Amtsgericht Muenchen, HRB 153243,  Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander

--  389-devel mailing list  389-devel@lists.fedoraproject.org  https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org  

--  389-devel mailing list  389-devel@lists.fedoraproject.org  https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org  

--   Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,   Commercial register: Amtsgericht Muenchen, HRB 153243,  Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander