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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Without this check, receiving empty replica leads to a situation
where we left with a working_schema attached to the ldb.
The problem here is that working_schema is not fully functional
schema cache and keeping it attached to the ldb may lead
to modules failing to accomplish their jobs
working_schema is to be used while committing a Schema replica.
When we replicate Schema, then we most probably won't be
able to convert all replicated objects using the current
Schema cache (as we don't know anything about those new objects).
Thus, during Schema replication, we make a temporary
working_schema that contains both our current Schema +
all objects we get on the wire.
When we commit those new objects, we should use our working_schema
(by setting it to the ldb), and after all changes are commited,
we can refresh the schema cache so we have a brand new,
full-featured Schema cache
Schema is changed and it is quite possible we won't be able
to decode replicated objects using current Schema cache we have.
Thus, when replicating Schema, we will make a temporary Schema
cache, working_schema, so that we can fully decode objects
we recieve.
It is heavily based on implementation in libnet_vampire_cb_apply_schema()
function, except that it actually creates a new copy of the supplied
initial_schema + resolving all incoming objects and add them to
supplied initial_schema.
We are going to need this 'working_schema' later so we are able
to fully resolve all objects we receive on wire during DRS replication.
Working schema created is to be used only as an index to search in.
It is not supposed to be set to an ldb_context as it doesn't
contain all information for classSchema and attributeSchema objects.
This is needed to fix a Tru64 "cc" warning regarding "enum drepl_role_master".
Autobuild-User: Matthias Dieter Wallnöfer <mdw@samba.org>
Autobuild-Date: Sun Nov 28 12:46:19 CET 2010 on sn-devel-104
when a replication fails, we should add the failure to repsFrom
when a notify fails, we need to save it to repsTo
this ensures showrepl always shows the latest status
We need a separate source dsa list for RODCs, as they are not in the
repsFrom for our partitions, but are in the repsTo. This adds a new
'notifies' list, which contains all the source dsas for the DCs that
we should send notifies to, but which we don't replicate from
Autobuild-User: Andrew Tridgell <tridge@samba.org>
Autobuild-Date: Mon Nov 8 06:57:43 UTC 2010 on sn-devel-104
This includes dom_sid.h and security_token.h and will be moved
to the top level shortly.
Andrew Bartlett
Autobuild-User: Andrew Bartlett <abartlet@samba.org>
Autobuild-Date: Tue Oct 12 03:35:36 UTC 2010 on sn-devel-104
This fixes the problem when we fail to replicate with
a partner DC that has a newer Schema with attributeSchema
objects with OIDs that we don't have in our local prefixMap.
- use generic parameter names
- trigger a run of pending ops on all extended ops
- don't prevent parallel fsmo transfers
- moved extended op code into drepl_extended
Multiple calls are allowed to run in parallel as long as they don't
conflict.
This also cleans up the variable names in the extended op calls.
Pair-Programmed-With: Andrew Bartlett <abartlet@samba.org>
With this change we can transfer all roles back and forward, except
for the naming master. Also this commit fixes the naming of
fsmo_role_dn - used to point to the DN from which we read fSMORoleOwner
role_owner_dn - used to point to the NTDSDSA who owns the role
Now we always pass fsmo_role_dn, role_owner_dn to the extended operation
and to drepl_create_role_owner_source_dsa
Conflicts:
source4/dsdb/repl/drepl_ridalloc.c
