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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We need to make LDB consistent here (indexed vs unindexed behaviour
differs here!), but for the moment this is the easiest way out of a
segfault.
Andrew Bartlett
Autobuild-User: Andrew Bartlett <abartlet@samba.org>
Autobuild-Date: Thu Dec 16 06:42:56 CET 2010 on sn-devel-104
Otherwise system_session() creates a LoadParm() instance
which resets certain global parameters to their defaults
from smb.conf ("log level" for instance)
Autobuild-User: Kamen Mazdrashki <kamenim@samba.org>
Autobuild-Date: Wed Dec 15 15:10:47 CET 2010 on sn-devel-104
DNS updates from nsupdate against our ldb SAM now work
Autobuild-User: Andrew Tridgell <tridge@samba.org>
Autobuild-Date: Wed Dec 15 12:36:46 CET 2010 on sn-devel-104
this implements the expanded DLZ update driver API, allowing for bind9
to send dynamic updates to the Samba DLZ driver.
This change also adds support for exporting all DNS zones in the SAM
database, which also means we now correctly separate the _msdcs zone
from the main zone.
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
We may have no prefix for the remote ATTID (remote OID strictly speaking)
So this is the place for us to update our local prefixMap
adding a prefix for the numeric OID we've recived
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
in dsdb_attribute_drsuapi_to_ldb() function.
drsuapi_DsReplicaAttribute *in parameter come from remote DC
so we can't rely on in->attid to map it directly to an
dsdb_attribute in our local schema cache
Otherwise we will end up passing whole inheritance chain
every time we create some new fancy classSchema object
(as the 'cls-A' and 'cls-B' ones in test_classWithCustomAttribute test)
Create new Attribute and a Class,
that has value for newly created attribute.
This should check code path that searches for
AttributeID_id in Schema cacheThis test.
It also tests how we replicate a leaf classSchema that
inherits from a new classSchema with attribute added
- tests both dsdb_attribute_drsuapi_to_ldb() and
_dsdb_syntax_OID_obj_drsuapi_to_ldb() syntax handler
Without this change, when a schema is set to ldb, the
effect is that dsdb_get_schema() returns global_schema
preferably.
Thus we end up with two schemas in effect:
- global one, which is the old one and it is still used everywhere
- new one, which is just cached in ldb, but can't be used, as
there is no way to access it
As a server only try the mechs the client proposed
and only call gensec_update() with the optimistic token
for the first mech in the list.
If the server doesn't support the first mech we pick the
first one in the clients list we also support.
That's how w2k8r2 works.
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Tue Dec 14 16:50:50 CET 2010 on sn-devel-104
Make it much harder to import bad data into the password attributes.
This isn't 100% safe, but much better than no checks.
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Mon Dec 13 16:17:36 CET 2010 on sn-devel-104
The DSDB_CONTROL_BYPASS_PASSWORD_HASH_OID control has to data attached to it.
So we can allow it to be send over LDAP.
We'll accept this control over the privileged ldapi socket only.
metze
