sssd & ldap
by François Dagorn
Hello all,
according to my ldap base administrator I'm sending border line ldap
requests. Of course I'm using SSSD configured as follows :
[domain/default]
auth_provider = ldap
ldap_id_use_start_tls = False
chpass_provider = ldap
cache_credentials = False
ldap_search_base = ou=people,dc=univ-xxxx,dc=fr
id_provider = ldap
ldap_uri = ldaps://yyyy.univ-xxxx.fr/
ldap_tls_cacertdir = /etc/sssd/cacerts
What happens : the ldap error_log says the following,
search is not indexed base='ou=people,dc=univ-xxxx,
dc=fr' filter='(&(objectClass=posixAccount)(uid=*)(uidNumber=*)
(gidNumber=*))'scope='sub'
I do not know why there are these counfounded objectClass, uid=*, ...
Any Help would be appreciated.
--
François Dagorn
Université de rennes
France
11 years, 4 months
[PATCHES] Fixes for select_principal_from_keytab()
by Sumit Bose
Hi,
https://fedorahosted.org/sssd/ticket/1635 was reopened because the
provided patch didn't fix the problem for the reporter. I think the
issue is that although we do lookups for all different types of
principals we do not lookup the plain names given by ldap_sasl_authid.
This is fixed by the first patch.
The second patch changes to order of the lookups by moving a wildcards
search after a specific one. I think it make sense to change it this way
but since the old order is used since some time chances are that this
change might break some setups. If you think the old order is better or
changing the order is too risky, please just ignore this patch.
bye,
Sumit
11 years, 4 months
[PATCH] Add extra protection for side request
by Simo Sorce
Add a timeout to side requests so they do not hang forever.
Tested with SIGSTOPping sssd_be and monitor and then waiting for the
request and later the idle timer to fire. Seem to work as expected here.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11 years, 4 months
[PATCH] Always request the auto.master map from Data Provider
by Jakub Hrozek
The attached patches implement functionality the admins have been asking
for in the autofs responder - when the auto.master map is requested,
refresh the mountpoints.
The motivation is that it is quite common for the admin to change the
maps and just SIGHUP the automounter or run automounter -m for testing
and see the current maps.
https://fedorahosted.org/sssd/ticket/1592
I tried to split the patches into small consumable pieces. Hopefully it
will ease the review.
[PATCH 1/7] SYSDB: fix copy-n-paste error
A one-liner
[PATCH 2/7] SYSDB: Add API to invalidate all map objects
This sysdb API will be used later to invalidate the autofs maps
[PATCH 3/7] DP: invalidate all cached maps if a request for auto.master
comes in
If the Data Provider receives a request for the auto.master map, it
passes on a flag to let the actual provider let know he should
invalidate the existing maps
[PATCH 4/7] AUTOFS: allow removing entries from hash table
There is a timed desctructor in the autofs responder that, when the
entry timeout passes, removes the autofs map from the hash table while
the map is freed. This patch adds a hash delete callback so that if the
map is removed from the hash table with hash_delete, its hash table
pointer will be invalidated. Later, when the entry is being freed, the
destructor won't attempt to remove it from the hash table.
[PATCH 5/7] AUTOFS: remove all maps from hash if request for auto.master
comes in
When a request for auto.master comes in, we need to remove all the maps
from the lookup hash table. We can't simply delete the maps, because
another request might be processing them, so instead the maps are
removed from the hash table, effectively becoming orphaned. The maps
will get freed when the timed destructor is invoked.
[PATCH 6/7] RESPONDERS: Create a common file with service names and
versions
The monitor sends calls different sbus methods to different responders.
Instead of including headers of the particular responders directly in
monitor, which breaks layering a little, create a common header file
that will be included from src/responder/common/
[PATCH 7/7] AUTOFS: Clear enum cache if a request comes in from the
sss_cache
In order for sss_cache to work correctly, we must also signal the autofs
responder to invalidate the hash table requests.
11 years, 4 months
[PATCH] Primary server status is not always reset after failover to backup server happened
by Pavel Březina
The problem is when we are about to reset the server status, we don't
get through the timeout (30 seconds) because the "switch to primary
server" task is scheduled 30 seconds after fall back to a backup
server. Thus the server status is resetted after another 30 seconds.
It can be nicely seen in the logs:
[be_primary_server_timeout] (0x0400): Looking for primary server!
[fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP'
[get_server_status] (0x1000): Status of server 'backup.pb' is 'working'
[get_port_status] (0x1000): Port status of port 389 for server
'backup.pb' is 'working'
[get_server_status] (0x1000): Status of server 'ipa-server.ipa.pb' is
'working'
[get_port_status] (0x1000): Port status of port 389 for server
'ipa-server.ipa.pb' is 'not working'
[get_port_status] (0x0010): ===== DIFF = 30 > 30
[get_server_status] (0x1000): Status of server 'backup.pb' is 'working'
[get_port_status] (0x1000): Port status of port 389 for server
'backup.pb' is 'working'
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to
10 seconds
[get_server_status] (0x1000): Status of server 'backup.pb' is 'working'
[be_resolve_server_process] (0x1000): Saving the first resolved server
[be_resolve_server_process] (0x0200): Found address for server
backup.pb: [10.16.78.43] TTL 60
[be_primary_server_timeout_activate] (0x2000): Primary server
reactivation timeout set to 30 seconds
The question is how we should deal with it? The easiest solution (in
the attached patch) is just switching > with >=. But I'm not quite sure
whether it is the best solution. It doesn't really fit into my
understanding of timeout.
My other thoughts were:
1. schedule "switch to primary server" task to 31 seconds
2. reset server status of all primary servers when this task is
triggered
11 years, 4 months