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-mo...
>>>> git patch file (master) -- additional fix to the server patch
>>>>
>>>>
https://fedorahosted.org/389/attachment/ticket/48755/0002-Ticket-48755-CI...
>>>> 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/bu...
>>>>
>>>> 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(a)lists.fedoraproject.org
>>>>
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject...
>>>
>>> --
>>> 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(a)lists.fedoraproject.org
>>>
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject...
>>
>>
>>
>>
>> --
>> 389-devel mailing list
>> 389-devel(a)lists.fedoraproject.org
>>
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject...
>
> --
> 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(a)lists.fedoraproject.org
>
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject...
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject...
--
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