| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case libsss_nss_idmap provides timeout-enabled NSS API, use it.
This solves a problem of too long queries to an NSS backend with
traditional POSIX NSS API. In case SSSD takes too long to respond
to a query, corresponding 389-ds thread running schema-compat plugin
would stuck waiting that response. It can lead to an exhaustion of
389-ds threads.
A refactored interface to NSS backends is introduced with this commit.
A backend API looks like an API an NSS plugin has to implement in glibc
but also allows to handle timeout-based requests internally.
If backend implements timeout-enabled calls, then
backend_nss_set_timeout() function can be used to modify a per-context
state. There is no need for a caller to know whether backend supports
timeout-enabled calls because either way these calls are synchronous
and backend choice is done at compile-time.
schema-compat plugin uses 10 seconds as its default timeout. One can
change it via 'slapi-nss-timeout' attribute in the plugin config entry.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
During password modification ext. op (1.3.6.1.4.1.4203.1.11.1),
if the target entry is in the compat tree, slapi-nis should
remap the entry to the real entry.
This needs to be done in a pre-op extop that calls the callback
function handling a given OID.
The password mod. callback does a reverse mapping of
extop USERID and set it in SLAPI_TARGET_SDN.
https://fedorahosted.org/freeipa/ticket/5955
|
| |
|
|
| |
Resolves: rhbz#1327197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently slapi-nis design assumes the map cache is populated by
scanning the original trees on plugin start up. This has few
consequences:
- LDAP server cannot serve LDAP clients until all plugins are
initialized
- slapi-nis cannot ask SSSD to resolve external identities at
this point as SSSD will need to talk to the LDAP server which
is at this point not listening for connections. SSSD will put
whole IPA domain into offline and always will respond
with negative result
To solve these issues, schedule tree scan after LDAP server startup.
The problem here is that it is not possible to reliably detect when
389-ds starts to listen to the incoming connections. However, it is
possible to schedule an event into 389-ds event queue that will run
shortly after start of the event loop. Given that the call back function
which is registered to be called is called within the event loop thread,
one can fire off another thread and wait in the thread function some
time until the LDAP server is ready for connections.
The time interval is something that would depend on a specific
deployment profile but experiments show that having 5 seconds delay
should be enough as event queue is created just before starting the
listeners.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When slapi-nis plugin responds on a search query, it holds read lock for
the internal structure called 'map cache'. The map cache lock can also be taken
for write when modification would be required like responding to DELETE, ADD, or
MODIFY operations.
As result of the lock semantics, write lock owner is blocked until all read lock
owners release their locks. This is generally not a problem but when readers sent
out LDAP query results, they call into SLAPI function that might take long time
to send out the data due to external reasons (network latencies, clients being
blocked, etc) and all this time map cache is locked for write operations.
When Kerberos KDC issues a TGT, it needs to modify few Kerberos-related attributes
in the principal's LDAP entry. These updates are generating MOD operations visible
by slapi-nis plugin which triggers re-scan of map cache to potentially replace
the affected entries. To perform potential replacement, slapi-nis has to take a write
lock and be blocked by outstanding readers.
Therefore, it is possible to encounter a situation where an LDAP client uses
SASL GSSAPI authentication and existing Kerberos ticket did expire in a course
of outstanding search request. According to LDAPv3 protocol specification, an
LDAP client must perform re-negotiation before reading any outstanding PDUs. It
would ask Kerberos KDC for a new (or renewed) TGT, that would cause MOD updates
for the primary tree which is tracked for changes by slapi-nis. These changes
would be blocked by a slapi-nis reader as the client cannot finish reading
outstanding PDUs yet.
To solve this problem, we avoid sending LDAP entries while keeping map cache
lock. Instead, we generate a linked list of copies of entries which will be
sent out. To allow sharing of entries between multiple parallel queries, we
hash the entry and reference the cached entry in the linked list with increased
reference count. Once entry is actually sent, its reference count decreased and
on reaching zero it is removed from the hash.
The entry in the hash table might become outdated. This is detected by comparing
both modifyTimestamp and entryUSN values of the entry to be sent and entry in the
hash table. If new version of the entry is different, hash table's entry reference
is replaced with a new copy. The old entry is not removed because it is still
referenced by some outstanding query processing. Thus, the hash table always
references the most recent version of an entry but there might be multiple copies
in possesion of the linked lists from the separate parallel queries.
An entry sharing via hash table can be disabled by setting
slapi-entry-cache: 0
in the definition, cn=Schema Compatibility,cn=plugins,cn=config
Resolves: rhbz#1273587
https://bugzilla.redhat.com/show_bug.cgi?id=1273587
|
| |
|
|
|
|
|
|
|
|
|
|
| |
users via NSS
When Schema Compatibility plugin is configured to enumerate users and groups
from Active Directory domains trusted by FreeIPA, use nss_sss module directly
instead of following nsswitch.conf configuration.
The issue with nsswitch.conf configuration is in the fact that for each request
all modules in NSS chain are processed while only one of them is responsible
for users from trusted Active Directory domains, namely, nss_sss.
|
| |
|
|
|
|
|
|
| |
PAM stack requires exclusive access, therefore we need to use a write
lock.
Required for authenticating synthetically created records coming outside
of LDAP store.
|
| | |
|
| |
|
|
|
| |
- put a newline at the end of these two messages
- register callbacks in a consistent order
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Check for BETXN support at build-time, provide options for disabling
or requiring that it be available for build to succeed.
* Track whether or not BETXN support is enabled in the plugin-local
state.
* Skip processing in post/internalpost callbacks if BETXN support is enabled.
* Skip work in betxnpost callbacks if BETXN support is disabled.
|
| |
|
|
|
|
|
|
|
|
| |
When NIS Plugin and Schema Compatibility Plugin config entries include
nsslapd-pluginbetxn: on
(the value could be yes, true or 1, too),
the plugins' update callbacks (add, delete, modify, and modrdn) are
called at the betxn pre/postop timing. By default, the value of
nsslapd-pluginbetxn is off.
(See also https://fedorahosted.org/389/ticket/351)
|
| |
|
|
|
|
|
| |
Transaction support the way we added it is an all-or-nothing proposition
for a server installation, which turned out to be problematic, so 389 is
going to pursue another strategy for that. The new way requires that we
not register as a betxn plugin, ever.
|
| |
|
|
| |
transaction ID, just return, and have faith that we'll be called again in the transaction post
|
| | |
|
| |
|
|
|
|
| |
already have, so that we can pass the transaction ID around; this
includes additional parameters for a number of functions and a new
callback data type for backend_set_config_entry_add_cb()
|
| |
|
|
|
|
| |
misleading debug message
- set IPV6_V6ONLY to avoid logging an expected EADDRINUSE error
|
| |
|
|
| |
passing the TXN ID around, which means we deadlock if we actually do it
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
say we should do
- use whether or not the plugin_base is initialized as in indicator of
whether the plugin's been started or not
|
| |
|
|
| |
startup-time, so that the hooks will only be used if we're enabled
|
| |
|
|
|
| |
ipv4 or ipv6 sockets
- make portmap_register()/portmap_unregister() require the address family
|
| |
|
|
|
| |
- make the nis plugin register two types of internal plugins,
since it can't just be a postop plugin any more
|
| | |
|
| |
|
|
| |
- add a shutdown function to the sch plugin so that it can clean up its cache
|
| |
|
|
| |
the base DN information
|
| |
|
|
| |
later
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
- start adding configuration for the schema plugin
|
|
|
- start factoring out the backend logic where the sch and nis backends overlap
|
