IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When we vampire from w2k8-r2, the DC sends us a linked attribute for
our machine account which has a target DN with a GUID of the OU=Domain
Controllers objects, but has a DN of CN=Computers. We need to use the
GUID to resolve the real DN.
With a w2k8-R2 DC, we sometimes get linked attribute updates via DRS
which are duplicates of entries that we already have. We need to cope
with this by using a remove/add pair in the ldb_modify() to avoid a
"entry already exists" error
This object tracks the highest uSN in each partition. It will be used
to allow us to efficiently detect changes in a partition for sending
DsReplicaSync messages to our replication partners.
I think these modules ended up LGPL because someone based the module
on an existing LGPL module in the core ldb, and it spread from
there. Certainly there is no reason for the ldb modules that are not
distributed as part of ldb to be LGPL.
When changing non-replicated attributes we should not update the
uSNChanged attribute on the record, otherwise the DRS server will
think this record needs replicating.
Every time we change a ldb object with the repl_meta_data module
loaded we need to update the replPropertyMetaData attribute to fix the
timestamps and USNs of the attributes being changed.
When running at functional level 2 or above, the repl_meta_data module
can receive linked attribute structures from the repl replication
task. These attributes can come through DRS before the associated
objects have been created. To cope with this, we need to process
linked attributes in the end_transaction hook.
Added simple DRS rename support in replication. This should be done
async, and I'm not sure if we should also do any repl data updates to
indicate the rename. I'm still learning how this stuff works, but at
least this allows a rename on a DC to propogate correctly
This means that, except when we back onto LDAP, when it will be
replaced with the mapping backend, we will keep this codepath tested.
Andrew Bartlett
(This used to be commit e8fb5da5a18c1c3bd788b1ab3f814ffb847b00fd)
The main change here is to work with the current module stack,
replacing only the objectGUID module, rather than a number of modules.
However, two changes were key:
- Fixing a typo search_req->handle -> change_req->handle
- Allowing an error of NO_SUCH_OBJECT - it is quite valid
for the object not to exist when being replicated in.
Other small changes were required to the ejs provision to match
changes in that code.
Andrew Bartlett
(This used to be commit 7b87a58502a052de391f4e1c56ac78a8d35b4e34)
