mirror of
https://github.com/samba-team/samba.git
synced 2024-12-25 23:21:54 +03:00
44ca84166e
While running the selftests, I noticed a case where DC replication unexpectedly sends a linked attribute for a deleted object (created in the drs.ridalloc_exop tests). The problem is due to the msDS-NC-Replica-Locations attribute, which is a (known) one-way link. Because it is a one-way link, when the test demotes the DC and deletes the link target, there is no backlink to delete the link from the source object. After much debate and head-scratching, we decided that there wasn't an ideal way to resolve this problem. Any automated intervention could potentially do the wrong thing, especially if the link spans partitions. Running dbcheck will find this problem and is able to fix it (providing the deleted object is still a tombstone). So the recommendation is to run dbcheck on your DCs every 6 months (or more frequently if using a lower tombstone lifetime setting). However, it does highlight a problem with the current GET_TGT implementation. If the tombstone object had been expunged and you upgraded to 4.8, then you would be stuck - replication would fail because the target object can't be resolved, even with GET_TGT, and dbcheck would not be able to fix the hanging link. The solution is to not fail the replication for an unknown target if GET_TGT has already been set (i.e. the dsdb_repl_flags contains DSDB_REPL_FLAG_TARGETS_UPTODATE). It's debatable whether we should add a hanging link in this case or ignore/drop the link. Some cases to consider: - If you're talking to a DC that still sends all the links last, you could still get object deletion between processing the source object's links and sending the target (GET_TGT just restarts the replication cycle from scratch). Adding a hanging link in this case would be incorrect and would add spurious information to the DB. - Suppose there's a bug in Samba that incorrectly results in an object disappearing. If other DCs then remove any links that pointed to that object, it makes recovering from the problem harder. However, simply ignoring the link shouldn't result in data loss, i.e. replication won't remove the existing link information from other DCs. Data loss in this case would only occur if a new DC were brought online, or if it were a new link that was affected. Based on this, I think ignoring the link does the least harm. This problem also highlights that we should really be using the same logic in both the unknown target and the deleted target cases. Combining the logic and moving it into a common replmd_allow_missing_target() function fixes the problem. (This also has the side-effect of fixing another logic flaw - in the deleted object case we would unnecessarily retry with GET_TGT if the target object was in another partition. This is pointless work, because GET_TGT won't resolve the target). Signed-off-by: Tim Beale <timbeale@catalyst.net.nz> Reviewed-by: Andrew Bartlett <abartlet@samba.org> BUG: https://bugzilla.samba.org/show_bug.cgi?id=12972 Reviewed-by: Garming Sam <garming@catalyst.net.nz> |
||
|---|---|---|
| .. | ||
| auth | ||
| build/pasn1 | ||
| cldap_server | ||
| client | ||
| cluster | ||
| dns_server | ||
| dsdb | ||
| echo_server | ||
| heimdal | ||
| heimdal_build | ||
| include | ||
| kdc | ||
| ldap_server | ||
| lib | ||
| libcli | ||
| libnet | ||
| librpc | ||
| nbt_server | ||
| ntp_signd | ||
| ntvfs | ||
| param | ||
| rpc_server | ||
| script | ||
| scripting | ||
| selftest | ||
| setup | ||
| smb_server | ||
| smbd | ||
| torture | ||
| utils | ||
| web_server | ||
| winbind | ||
| wrepl_server | ||
| .clang_complete | ||
| .valgrind_suppressions | ||
| wscript_build | ||