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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
idmap_tdb2_new_mapping() is called from inside a transaction only
with sids, that have been verified not to be mapped directly before
that in the same transaction.
Note that this will not prevent the idmap script from writing its
mappings to the database, but no new unix ids will be allocated via
the allocator and hence no new mappings will be autogenerated.
idmap_tdb2_state should actually be called idmap_tdb2_alloc_context.
This is being removed as the idmap and allocation is moved together.
We use the idmap_tdb2_context * that is sitting in dom->private_data.
This contains the same ranges as those in the state anyways.
Later, when we can also allocate for named domains, this will become
necessary anyways.
This moves the new_mapping feature inside the tdb2 backend to make creations
of mappings atomic.
Note: The new internal function idmap_tdb2_get_new_id() that is used to allocate
a new unix id is prepared to function for multiple explicitly configured idmap
domains, but currently it does only work for the default domain. The extended
allocation support requires extension of the data base format to store multiple
counters (per domain). This will be added in a later step (TODO!).
This is now not available any more, since allocation is moved
below the id mapping layer. The functionality could be
reintroduced on a per domain basis as an e.g
"net idmap secret <domain> alloc" command.
This will be used to be able to put the default idmap config
read only. This can make sense for instance with the tdb2
idmap backend and using the idmap script feature.
The registering of alloc backends is being removed.
The idmap backends are responsible for initializing
their alloc code on their own if necessary.
No list of alloc backends is maintained any more in the top level.
The registering of alloc backends is being removed.
The idmap backends are responsible for initializing
their alloc code on their own if necessary.
No list of alloc backends is maintained any more in the top level.
