Age | Commit message (Collapse) | Author | Files | Lines |
|
reloading a schema
This allows us to carefully control the loading of the schema.
Andrew Bartlett
|
|
This matches the rest of the function.
Andrew Bartlett
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Thu Aug 9 06:26:36 CEST 2012 on sn-devel-104
|
|
partition_primary_sequence_number
We always want LDB_SEQ_HIGHEST_SEQ here.
Andrew Bartlett
|
|
This simple operation does not need to be encased in generic ldb extended operations.
Andrew Bartlett
|
|
We do not need to reload the partition list to get the global sequence
number, as that number is stored in the metadata.tdb, not the ldb files.
Andrew Bartlett
|
|
metze
|
|
msg->elements on RODC replication
It's very important that the order of msg->elements and md->ctr.ctr1.array
is the same.
metze
|
|
This allows a lastKnownParent from LostAndFound to be replaced.
Andrew Bartlett
|
|
When we call ldb_module_done() rather than just calling the callback, we make log entries
that are critical in debugging.
Andrew Bartlett
|
|
Previously we would only consider renaming the local object, now we can cope with
renaming the remote object as well.
This should avoid most of the cases where Samba AD replication can just stop.
Andrew Bartlett
|
|
parent
This fixes up the lastKnownParent attribute on lostAndFound objects to have a GUID
(found by dbcheck).
Andrew Bartlett
|
|
Autobuild-User(master): Andrew Bartlett <abartlet@samba.org>
Autobuild-Date(master): Sun Jul 29 16:51:34 CEST 2012 on sn-devel-104
|
|
|
|
add debugging
The logic looking for LostAndFound failed for a user, so add extensive
debugging to make this eaiser to trace down in future.
Andrew Bartlett
|
|
This should mean that a samba-tool drs replicate --full-sync forces a
replication of all objects, regardless of if we think the local name
is newer and regards any local name as being in conflict.
Andrew Bartlett
|
|
This allows us to proceed with replication when the source DC is sending us an object
which has a matching object in this NC (by name) but not by GUID.
Andrew Bartlett
|
|
Based on a patch proposal by Matthieu Patou <mat@matws.net>.
Andrew Bartlett
|
|
|
|
Normally this would be a very bad idea, but the specific case of fixing the instanceType
is the only case where this makes sense.
Andrew Bartlett
|
|
|
|
We should prevent this much further up the stack, but at least add a choke
at this point for now.
Additionally, this avoids administrator-forced replications causing
considerable damange to the directory.
Andrew Bartlett
|
|
|
|
|
|
|
|
This checks the type rather than just dereferencing the pointer.
Andrew Bartlett
|
|
|
|
This allows the parent to be renmaed while a new object is added on another replica.
This rename may also be a delete, in which case we must move it to lostandfound.
Andrew Bartlett
|
|
non-critical
|
|
This was an interesting hack, and the local_password module still exists, but
until it has a use case and a test case, remove the bypass of password_hash.
Andrew Bartlett
|
|
|
|
|
|
We need to have the struct dreplsrv_partition_source_dsa around until the end of the
async op, so we use talloc_reference after carefully checking the callers and
making the modifications required.
This prevents a crash when replicating partitions in the vampire_dc test after
adding DNS replication at join time.
Andrew Bartlett
|
|
have to reload it
Autobuild-User(master): Matthieu Patou <mat@samba.org>
Autobuild-Date(master): Sat Jun 23 10:48:13 CEST 2012 on sn-devel-104
|
|
modifyTimeStamp is a generated attribute, for most object it's generated
directly from the whenChanged attribute. But for the CN=aggregate object
in the schema we have to handle it in a different way, that's because
for this object whenChanged!=modifyTimeStamp (as checked against Windows
2003R2 DCs) instead the modifyTimeStamp reflect the timestamp of the
most recently modified and loaded schema object (that is to the one with
the highest USN before the schema was reload due to timeout or by the
reloadSchemaNow command).
Some third party are using this information to know if they have to
update their schema cache and also to check that schema updates have
been correctly reloaded by the DC, a good example of this behavior is
exchange 2010.
|
|
|
|
If the value has changed then reload the schema, this means that now the
schema is only reloaded on a periodical basis or if we have been asked
explicitly to do it and not necesserly if the schema partition has
changed.
|
|
The idea is to signal to other process accessing the database that the
schema was forced to be reloaded and so they should reload as well.
|
|
they have to reload the schema
|
|
|
|
|
|
object
|
|
|
|
|
|
|
|
we are a GC
In theory when presented this control and not a GC we should use the
specified name as the DC to contact for cross-domain link verification.
But for the moment we don't support this so we just fail when we have
this control and are not a GC.
|
|
|
|
We search in the schema if we have already this intid (using dsdb_attribute_by_attributeID_id because
in the range 0x80000000 0xBFFFFFFFF, attributeID is a DSDB_ATTID_TYPE_INTID).
If so generate another random value.
If not check if the highest USN in the database for the schema partition is the
one that we know.
If so it means that's only this ldb context that is touching the schema in the database.
If not it means that's someone else has modified the database while we are doing our changes too
(this case should be very bery rare) in order to be sure do the search in the database.
|
|
Samba 4 use to try to reload the schema every time dsdb_get_schema was
called (which could be 20+ time per ldb request). Now we only reload at
most every xx seconds (xx being the value of dsdb:"schema_reload_interval"
or 120). The timestamp of the last reloaded schema is kept in the
dsdb_schema object. There is also a timestamp in the ldb_context, that
is used by the LDAP server to know if it has to reload the schema after
handling the request. This is used to allow that the schema will be
immediately reload after a schemaUpdateNow request has been issued, the
reload can't occur in the handling of the LDAP request itself because
we have a transaction autostarted.
|
|
|
|
|