summaryrefslogtreecommitdiff
path: root/source4/libnet
diff options
context:
space:
mode:
authorTim Beale <timbeale@catalyst.net.nz>2017-07-20 11:14:27 +1200
committerAndrew Bartlett <abartlet@samba.org>2017-08-18 06:07:12 +0200
commit89cf5c3f76e214fbd06ce461470eb64b338c5144 (patch)
tree9f18badc0868f3d537cbdcab18a7b2b7be1afc75 /source4/libnet
parentab12aed7e13a9c9663ba04b6dd4f02acb7bff380 (diff)
downloadsamba-89cf5c3f76e214fbd06ce461470eb64b338c5144.tar.gz
replmd: Don't fail cycle if we get link for deleted object with GET_TGT
We are going to end up supporting 2 different server schemes: A. the old/default behaviour of sending all the linked attributes last, at the end of the replication cycle. B. the new/Microsoft way of sending the linked attributes interleaved with the source/target objects. Normally if we're talking to a server using the old scheme-A, we won't ever use the GET_TGT flag. However, there are a couple of cases where it can happen: - A link to a new object was added during the replication cycle. - An object was deleted while the replication was in progress (and the linked attribute got queued before the object was deleted). Talking to an Samba DC running the old scheme will just cause it to start the replication cycle from scratch again, which is fairly harmless. However, there is a chance that the same thing can happen again, in which case the replication cycle will fail (because GET_TGT was already set). Even if we're using the new scheme (B), we could still potentially hit this case, as we can still queue up linked attributes between requests (group memberships can be larger than what can fit into a single replication chunk). If GET_TGT is set in the GetNcChanges request, then the local copy of the target object should always be up-to-date when we process the linked attribute. So if we still think the target object is deleted/recycled at this point, then it's safe to ignore the linked attribute (because we know our local copy is up-to-date). This logic matches the MS spec logic in ProcessLinkValue(). Not failing the replication cycle may be beneficial if we're trying to do a full-sync of a large database. Otherwise it might be time-consuming and frustrating to repeat the sync unnecessarily. Signed-off-by: Tim Beale <timbeale@catalyst.net.nz> Reviewed-by: Garming Sam <garming@samba.org> Reviewed-by: Andrew Bartlett <abartlet@samba.org> BUG: https://bugzilla.samba.org/show_bug.cgi?id=12972
Diffstat (limited to 'source4/libnet')
-rw-r--r--source4/libnet/libnet_vampire.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/source4/libnet/libnet_vampire.c b/source4/libnet/libnet_vampire.c
index d89256b02a8..aa0ec91e590 100644
--- a/source4/libnet/libnet_vampire.c
+++ b/source4/libnet/libnet_vampire.c
@@ -647,6 +647,10 @@ WERROR libnet_vampire_cb_store_chunk(void *private_data,
is_exop = true;
}
req_replica_flags = c->req10->replica_flags;
+
+ if (c->req10->more_flags & DRSUAPI_DRS_GET_TGT) {
+ dsdb_repl_flags |= DSDB_REPL_FLAG_TARGETS_UPTODATE;
+ }
break;
default:
return WERR_INVALID_PARAMETER;