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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
this replaces "return LDB_ERR_OPERATIONS_ERROR" with "return ldb_operr(ldb)"
in places in the dsdb code where we don't already explicitly set an
error string. This should make is much easier to track down dsdb
module bugs that result in an operations error.
The schema refresh operation itself starts requests from the top of the LDB
modules stack (see call "dsdb_schema_set_attributes" - search operations).
This doesn't work well when these do perform "dsdb_get_schema" calls. Since the
new schema isn't marked as "refreshed" atm (but in fact it still is - we didn't
terminate the reload/refresh yet) we could perform other calls to
"dsdb_schema_refresh" and run into serious trouble (segfault).
This commit reworks Samba4's schema loading code to detect when it
needs to reload the schema. This is done by watching the @REPLCHANGED
special DN.
The reload happens by means of a callback, which is only set when the
schema is loaded from the ldb - not when loaded from an LDIF file or
DRS.
We also rework the global schema handling - instead of storing the
pointer to the global schema in each ldb, we store a flag indicating
that the global schema should be returned at run time. This makes it
much easier to switch to a new global schema.
Andrew Bartlett
This choses an appropriate talloc context to attach the schema too,
long enough lived to ensure it does not go away before the operation
compleates.
Andrew Bartlett
This loads the defaultObjectCategory DN as an extended DN, so we can
apply it, with the associated GUID, when setting this on records in
the objectClass module.
Previously we would not store the extended DN components for
objectCategory.
Andrew Bartlett
By splitting the module this way, we can load the schema at startup, after
the partitions module is operational, but we leave the 'mess with details of
entries in the partitions' module to operate only on the partitions module.
Loading the schema later allows us to set the @ATTRIBUTES correctly on all
the databases.
Andrew Bartlett
