| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When we replicate from a remote DC, we need to note the new uSN that
the local changes have resulted in, and modify the uSN that the notify
task uses to determine if it should send a ReplicaSync message back to
the remote DC. Otherwise we end up always triggering a ReplicaSync
every time we replicate from another DC
|
|
we were setting local_usn after the marshall, so it wasn't going into
the object
|
|
Using DLIST_ADD_END() to construct a long list is very inefficient (it
is O(n^2). These lists are not ordered, so using DLIST_ADD() is much
better.
|
|
|
|
In time, this should avoid the astounding (order) complexity of the
objectclass sorting in objectclass.c eventually.
Andrew Bartlett
|
|
On a rename we need to update uSNChanged, and the max uSN for the
partition
|
|
We could get a double free with multiple linked attributes in a
message
|
|
Windows does not seem to be always setting up repsTo using
DsUpdateRefs(). For now we will fall back to using repsFrom if repsTo
is empty. This is almost certainly incorrect, but it does get
notification based replication working with both w2k3 and w2k8.
|
|
Michael
|
|
The dreplsrv_notify code checks the partition uSN values every N
seconds, and if one has changed then it sends a DsReplicaSync to all
the replication partners listed in the repsTo attribute for the
partition.
|
|
|
|
These are used to load/save the per-partition uSN values managed by
the repl_meta_data module
|
|
You can now attach a partition control to searches to search within a
specific partition. This is used to get at the per-partition
@REPLCHANGED object
|
|
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.
|
|
metze
|
|
The partition module normally makes the sequence number extended op
operate across all partitions. It will be useful in the repl task to
be able to ask for the sequence number of one partition
|
|
These memory leaks were mostly caused by the fact that
refresh_partitions is now called periodically
|
|
we only need to allocate a new sequence number when
replPropertyMetaData is changing or being created on an object
|
|
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.
|
|
If we already have a repsFrom for a particular DC and naming context
then we should not overwrite it, as it contains info on what
replication we've already done
|
|
|
|
|
|
The KCC might have changed repsFrom, which is stored in the partitions
structure
|
|
A KCC is a 'Knowledge Consistency Checker', a fancy name for a daemon
that works out who will replicate with who in a AD domain. This
implements an extremely simple KCC task that just wants to replicate
with everyone :-)
|
|
thanks to Metze for spotting this
|
|
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 a DsAddEntry is used to create a nTDSDSA object we need to also
create the SPNs for the NTDS GUID in the servers machine account.
|
|
|
|
We were trying to encode strings like 'top' as integers, without first
looking them up in our schema. We need special handling for all the
attributes that contain attributeID_id or governsID_id fields that
should be translated first before encoding.
|
|
|
|
This patch implements DsReplicaSync by passing the call via irpc to
the repl server task. The repl server then triggers an immediate
replication of the specified partition.
This means we no longer need to set a small value for
dreplsrv:periodic_interval to force frequent DRS replication. We can
now wait for the DC to send us a ReplicaSync msg for any partition
that changes, and we immediately sync that partition.
|
|
I've found that w2k3 deletes the repsTo records we carefully created
in the vampire join if we don't refresh them frequently. After about
30mins all 3 repsTo records are gone.
This patch adds automatic refresh of the repsTo by calling
DSReplicaUpdateRefs every time we do a sync cycle with the server
|
|
metze
|
|
metze
|
|
|
|
Here we just need to map the oid string in the ldb value to
the ATTRTYP id.
metze
|
|
Previous patch was incomplete regarding the "primaryGroupId" attribute. Complete it.
|
|
|
|
|
|
This fixes up the change of the primary group of a user when using the ADUC
console:
- When the "primaryGroupId" attribute changes, we have to delete the
"member"/"memberOf" attribute reference of the new primary group and add one
for the old primary group.
- Deny deletion of primary groups according to Windows Server (so we cannot
have invalid "primaryGroupID" attributes in our AD).
- We cannot add a primary group directly before it isn't a secondary one of a
user account.
- We cannot add a secondary reference ("member" attribute) when the group has
been chosen as primary one.
This also removes the LDB templates which are basically overhead now.
This should also fix bug #6599.
|
|
|
|
|
|
The parameters "lmNewHash" and/or "ntNewHash" could be NULL and when we perform
write operations on them (look below in the code) we could get SIGSEGVs!
|
|
|
|
|
|
This replace the dsdb_syntax_FOOBAR_ldb_to_drsuapi function,
which was left as a TODO code. Implementation in both added functions
is completely identical and probably should differ in the future.
|
|
This one copes with deleted objects where linked attributes have been
set on the module. We hit this when we do the ldb wipe at the start of
a provision, which trigers linked attribute updates, but for objects
that have disappeared. We need to ensure that the linked attribute
updates only happen on the right object, and if the object gets
re-created (as happens with a provision) then it is not the right
object.
To cope with this we record the GUID of the object when the operation
that triggered the linked attribute update comes in, and then find the
DN by suing that GUID when we apply the change in the prepare commit
hook.
|
|
This allows for safe transaction end aborts
|
