Again "Failed to remove backlin of memberOf when deleting" with debug info
Andrej Gessel
andrej.gessel at janztec.com
Wed Mar 14 11:13:06 UTC 2018
Hello Douglas,
you suggestion doesn't help me, as i wrote in my last message. The
problem is, that the member attributes of the group in ldb file are not
sorted.
Can someone point me to lines of code, where member attributes are
sorted, before they were added to ldb? It was fresh join and I can't
understand, why the forward links are not sorted.
Or give me some hint, where i should start to search.
Andrej
Am 12.03.2018 um 19:01 schrieb Andrej Gessel via samba-technical:
> Please ignore my last message.
>
> Andrej
>
> Gesendet mit meinem HTC
>
> ----- Nachricht beantworten -----
> Von: "Andrej Gessel via samba-technical" <samba-technical at lists.samba.org>
> An: "samba-technical" <samba-technical at lists.samba.org>
> Betreff: Again "Failed to remove backlin of memberOf when deleting" with debug info
> Datum: Mo., März 12, 2018 16:01
>
> Hello Douglas,
>
> your suggestion doesn't help me. I got the same error.
>
> My currently fix is linear search. I think the search is not the
> problem, but the sorting while adding objects.
>
> diff --git a/source4/dsdb/common/util_links.c
> b/source4/dsdb/common/util_links.c
> index cf1f4be..6c7e153 100644
> --- a/source4/dsdb/common/util_links.c
> +++ b/source4/dsdb/common/util_links.c
> @@ -121,7 +121,7 @@ int parsed_dn_find(struct ldb_context *ldb, struct
> parsed_dn *pdn,
> const char *ldap_oid,
> bool compare_extra_part)
> {
> - unsigned int i;
> + unsigned int i, _e, _r;
> struct compare_ctx ctx;
> if (pdn == NULL) {
> *exact = NULL;
> @@ -200,8 +200,18 @@ int parsed_dn_find(struct ldb_context *ldb, struct
> parsed_dn *pdn,
> ctx.compare_extra_part = compare_extra_part;
> ctx.err = 0;
>
> - BINARY_ARRAY_SEARCH_GTE(pdn, count, &ctx,
> la_guid_compare_with_trusted_dn,
> - *exact, *next);
> + (*exact) = NULL; (*next) = NULL;
> + if ((count) > 0) {
> + for (_e = 0; _e <= (count)-1; _e++ ) {
> + _r = la_guid_compare_with_trusted_dn(&ctx,
> &pdn[_e]);
> + if (_r == 0) {
> + (*exact) = &pdn[_e];
> + break;
> + }
> + }
> + }
> + /*BINARY_ARRAY_SEARCH_GTE(pdn, count, &ctx,
> la_guid_compare_with_trusted_dn,
> + *exact, *next);*/
>
> if (ctx.err != 0) {
> return ctx.err;
>
> Difference to BINARY_ARRAY_SEARCH_GTE is, that next will not be set.
>
> Additionally I tested the sorting function as follow:
>
> 1) print array
> 2) sort: TYPESAFE_QSORT(pdn, count, la_guid_compare_with_trusted_dn);
> 3) print array, result: array is sorted (not the same order as in 1))
> 4) sort again: TYPESAFE_QSORT(pdn, count, la_guid_compare_with_trusted_dn);
> 5) print array, result: array is sorted again, order of objects is
> different to 1) and 3)
>
> Code I used:
>
> diff --git a/source4/dsdb/common/util_links.c
> b/source4/dsdb/common/util_links.c
> index cf1f4be..9a3b458 100644
> --- a/source4/dsdb/common/util_links.c
> +++ b/source4/dsdb/common/util_links.c
> @@ -121,7 +121,7 @@ int parsed_dn_find(struct ldb_context *ldb, struct
> parsed_dn *pdn,
> const char *ldap_oid,
> bool compare_extra_part)
> {
> - unsigned int i;
> + unsigned int i, _e, _r;
> struct compare_ctx ctx;
> if (pdn == NULL) {
> *exact = NULL;
> @@ -199,7 +199,48 @@ int parsed_dn_find(struct ldb_context *ldb, struct
> parsed_dn *pdn,
> ctx.partial_extra_part_length = partial_extra_part_length;
> ctx.compare_extra_part = compare_extra_part;
> ctx.err = 0;
> -
> + DEBUG(0,("\tbefore sort 1\n"));
> + (*exact) = NULL; (*next) = NULL;
> + if ((count) > 0) {
> + for (_e = 0; _e <= (count)-1; _e++ ) {
> + _r = la_guid_compare_with_trusted_dn(&ctx, &pdn[_e]);
> + if (_r == 0) {
> + (*exact) = &pdn[_e];
> + }
> + }
> + }//*/
> + TYPESAFE_QSORT(pdn, count, la_guid_compare_with_trusted_dn);
> + DEBUG(0,("\tafter sort 1\n"));
> + if ((count) > 0) {
> + for (_e = 0; _e <= (count)-1; _e++ ) {
> + _r = la_guid_compare_with_trusted_dn(&ctx, &pdn[_e]);
> + if (_r == 0) {
> + (*exact) = &pdn[_e];
> + }
> + }
> + }
> + DEBUG(0,("===========================================\n"));
> + DEBUG(0,("\tbefore sort 2\n"));
> + (*exact) = NULL; (*next) = NULL;
> + if ((count) > 0) {
> + for (_e = 0; _e <= (count)-1; _e++ ) {
> + _r = la_guid_compare_with_trusted_dn(&ctx, &pdn[_e]);
> + if (_r == 0) {
> + (*exact) = &pdn[_e];
> + }
> + }
> + }//*/
> + TYPESAFE_QSORT(pdn, count, la_guid_compare_with_trusted_dn);
> + DEBUG(0,("\tafter sort 2\n"));
> + if ((count) > 0) {
> + for (_e = 0; _e <= (count)-1; _e++ ) {
> + _r = la_guid_compare_with_trusted_dn(&ctx, &pdn[_e]);
> + if (_r == 0) {
> + (*exact) = &pdn[_e];
> + }
> + }
> + }
> + DEBUG(0,("===========================================\n"));
> BINARY_ARRAY_SEARCH_GTE(pdn, count, &ctx,
> la_guid_compare_with_trusted_dn,
> *exact, *next);
>
>
> Andrej
>
>
> Am 09.03.2018 um 21:20 schrieb Douglas Bagnall:
>> Hi Andrej,
>>
>>> I'm testing new Samba version 4.8.0rc4 as an RODC with Windows server 2008R2 as RWDC.
>> Thank you.
>>
>>> 1) join is done with following command:
>>>
>>> samba-tool domain join SAMDOM.LOCAL RODC --domain-critical-only --configfile /path/smb.conf --username admin --dns-backend SAMBA_INTERNAL --server RWDC --site NewSite
>>>
>>> 2) After RODC was joined and samba was started i saw following error in log:
>>>
>>> Failed to apply records: ../source4/dsdb/samdb/ldb_modules/repl_meta_data.c:4373: Failed to remove backlink of memberOf when deleting CN=_User.Name\0ADEL:4cab6805-fd33-4edb-9bb2-702f7dce1210,CN=Deleted Objects,DC=samdom,DC=local: Attribute member doesn't exist for target GUID 4cab6805-fd33-4edb-9bb2-702f7dce1210: Operations error
>>> Failed to commit objects: WERR_GEN_FAILURE/NT_STATUS_INVALID_NETWORK_RESPONSE
>>> dreplsrv_op_pull_source(WERR_BAD_NET_RESP) for DC=samdom,DC=local
>>>
>>> 3) ldbsearch -H /path/DC=SAMDOM,DC=LOCAL.ldb '(distinguishedname=CN=_User.Name\0ADEL:4cab6805-fd33-4edb-9bb2-702f7dce1210,CN=Deleted Objects,DC=samdom,DC=local)' memberof
>>> # record 1
>>> dn: ...
>>> memberof: <GUID=...>;<SID=...>;CN=GROUP,OU=GROUPSX,DC=SAMDOM,DC=LOCAL
>>>
>>> 4) ldbsearch -H /path/DC=SAMDOM,DC=LOCAL.ldb '(distinguishedname=CN=GROUP,OU=GROUPSX,DC=SAMDOM,DC=LOCAL)' member
>>> # record 1
>>> dn: ...
>>> member: ...
>>> member: <GUID=4cab6805-fd33-4edb-9bb2-702f7dce1210>;<RMD_ADDTIME=0>;<RMD_CHANG
>>> ETIME=0>;<RMD_FLAGS=0>;<RMD_INVOCID=...>;<RMD_LOCAL_USN=1>;<RMD_ORIGINATING_
>>> USN=1>;<RMD_VERSION=1>;<SID=...>;CN=_User.Name\0ADEL:4cab6805-fd33-4edb-9bb
>>> 2-702f7dce1210,CN=Deleted Objects,DC=samdom,DC=local
>>>
>>> 5) I think that the problem is in the "comparison_fn"(la_guid_compare_with_trusted_dn) that is ONLY used in BINARY_ARRAY_SEARCH_GTE (https://github.com/samba-team/samba/blob/60c7969e20ddc72d1d2a9dd1bd116d47df07ab02/source4/dsdb/common/util_links.c#L203) . I replaced this macro with simple for-loop and it works again.
>> Right. It is of course OK that the function is only used here if it is
>> doing the same effective comparison as the sort, but looks like that
>> might not be the case. (c.f.
>> source4/dsdb/samdb/ldb_modules/repl_meta_data.c:1988).
>>
>> This should help in your case (though presumably break something else):
>>
>> diff --git a/source4/dsdb/common/util_links.c b/source4/dsdb/common/util_links.c
>> index cf1f4be58bd..8192da43245 100644
>> --- a/source4/dsdb/common/util_links.c
>> +++ b/source4/dsdb/common/util_links.c
>> @@ -74,16 +74,7 @@ static int la_guid_compare_with_trusted_dn(struct compare_ctx *ctx,
>> }
>> cmp = ndr_guid_compare(ctx->guid, &p->guid);
>> - if (cmp == 0 && ctx->compare_extra_part) {
>> - if (ctx->partial_extra_part_length != 0) {
>> - /* Allow a prefix match on the blob. */
>> - return memcmp(ctx->extra_part.data,
>> - p->dsdb_dn->extra_part.data,
>> - MIN(ctx->partial_extra_part_length,
>> - p->dsdb_dn->extra_part.length));
>> - } else {
>> - return data_blob_cmp(&ctx->extra_part,
>> - &p->dsdb_dn->extra_part);
>> - }
>> + if (cmp == 0) {
>> + return data_blob_cmp(&ctx->extra_part, &p->dsdb_dn->extra_part);
>> }
>>
>> return cmp;
>>
>>> ldb_index.c:
>>>
>>> The array is assumed to be sorted by the same comparison_fn as the
>>> search (with, for example, qsort)
>>>
>>> I do not have fix for it now, so i hope, that you can help me to find the best solution.
>> I'll think about it on Monday.
>>
>> cheers,
>> Douglas
>
More information about the samba-technical
mailing list