[PATCHES] HBAC performance enhancements
by Stephen Gallagher
https://fedorahosted.org/sssd/ticket/1029
The problem here is that we were trying to perform an "optimization" by
bulk-deleting the contents of the service and host lists in the sysdb
before dumping into it the new data we received from LDAP.
This was causing a major performance hit on large deployments, because
this recursive delete was repeatedly hitting a weak point of the
memberOf plugin. However, upon closer analysis, Sumit pointed out that
we don't actually need to rely on the local memberOf plugin in this
situation.
These patches remove the member/memberOf relationship from
host/hostgroup and service/servicegroup entries in the SSSD. As a
result, we don't invoke the memberOf plugin during the mass-delete and
we see a significant performance increase.
The patches [ab]use the fact that we know the DN structure of the hosts,
service and groups so that we don't need to go and look them up when
constructing the requests. Instead we take the originalMemberOf object
and interpret the value directly from it. This is much faster than
searching the sysdb for the original object to get its fqdn or cn value.
12 years, 6 months
Append PID to sbus server socket name, let clients use a symlink
by Jakub Hrozek
[PATCH 1/2] Add option to follow symlinks to check_file()
This functionality will be used later on
[PATCH 2/2] Append PID to sbus server socket name, let clients use a symlink
Only the Data Provider uses a symlink now -- I don't think it makes
sense for monitor, it cannot be restarted anyway. The proxy provider
spawns the proxy_child processes, so if it goes away, so do the
children.
Related question -- the clients now only reconnect when the dbus connection
goes away. Would it make sense to explicitly instruct them to reconnect when
monitor kills the server or perhaps when a new server is registered? This
might help the clients reconnect more seamlessly when the server does not
go away after receiving the shutdown signal.
12 years, 6 months
[PATCH] Check if dp_requests hash table exists before using it
by Jakub Hrozek
This might be a little artificial bug, but I've hit with one of QE's
reproducers.
They have a test pam client that rapidly does auth in a loop, but
evidently never calls the part of NSS responder that would in turn call
sss_dp_send_acct_req(). After sssd_be was killed and sssd_nss reconnected,
it accessed a NULL pointer in handle_requests_after_reconnect()
12 years, 6 months
[PATCH] SYSDB: New source file for sysdb upgrade routines
by Stephen Gallagher
The file sysdb.c is fairly cluttered. It makes sense to separate the
functional pieces from the setup pieces.
This patch makes no functional changes but moves the internal upgrade
routines into a separate source file. This is just to make the code
easier to navigate and maintain.
12 years, 6 months
Fast reply - offline
by Ondrej Valousek
Hi List,
I experience sometimes sssd reports certain users as not existing - symptoms in log are the following:
(Tue Sep 27 15:30:17 2011) [sssd[nss]] [accept_fd_handler] (4): Client connected!
(Tue Sep 27 15:30:17 2011) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1].
(Tue Sep 27 15:30:17 2011) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1].
(Tue Sep 27 15:30:17 2011) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [paulr] from [<ALL>]
(Tue Sep 27 15:30:17 2011) [sssd[nss]] [nss_cmd_getpwnam_search] (4): Requesting info for [paulr@default]
(Tue Sep 27 15:30:17 2011) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request for [default][4097][1][name=paulr]
(Tue Sep 27 15:30:17 2011) [sssd[nss]] [sss_dp_get_reply] (4): Got reply (1, 11, Fast reply - offline) from Data Provider
In this case sssd reports no such a user 'paulr'.
Also, the connection to the ldap server (AD, Windows Server 2008) seems to be quite unreliable:
(Tue Sep 27 14:26:40 2011) [sssd[be[default]]] [child_sig_handler] (4): child [20098] finished successfully.
(Tue Sep 27 14:26:40 2011) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'dcpra1.dublin.ad.s3group.com' as 'working'
(Tue Sep 27 14:26:40 2011) [sssd[be[default]]] [set_server_common_status] (4): Marking server 'dcpra1.dublin.ad.s3group.com' as 'working'
(Tue Sep 27 14:41:51 2011) [sssd[be[default]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend!
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [be_get_account_info] (4): Got request for [4099][1][name=postfix]
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [be_resolve_server_done] (4): Found address for server dcpra1.dublin.ad.s3group.com:
[192.168.60.203]
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [fo_resolve_service_send] (4): Trying to resolve service 'KERBEROS'
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'dcpra1.dublin.ad.s3group.com' as 'not
working'
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [fo_resolve_service_send] (1): No available servers for service 'LDAP'
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [sdap_id_op_connect_done] (1): Failed to connect, going offline (5 [Input/output error])
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [be_run_offline_cb] (3): Going offline. Running callbacks.
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [acctinfo_callback] (4): Request processed. Returned 1,11,Offline
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [remove_krb5_info_files] (5): Could not remove
[/var/lib/sss/pubconf/kpasswdinfo.DUBLIN.AD.S3GROUP.COM], [2][No such file or directory]
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [remove_krb5_info_files] (5): Could not remove
[/var/lib/sss/pubconf/kdcinfo.DUBLIN.AD.S3GROUP.COM], [2][No such file or directory]
(Tue Sep 27 14:43:50 2011) [sssd[be[default]]] [remove_krb5_info_files] (5): Could not remove
[/var/lib/sss/pubconf/kpasswdinfo.DUBLIN.AD.S3GROUP.COM], [2][No such file or directory]
(Tue Sep 27 15:30:17 2011) [sssd[be[default]]] [be_get_account_info] (4): Got request for [4097][1][name=paulr]
(Tue Sep 27 15:30:17 2011) [sssd[be[default]]] [be_get_account_info] (4): Request processed. Returned 1,11,Fast reply - offline
(Tue Sep 27 15:30:17 2011) [sssd[be[default]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Tue Sep 27 15:30:17 2011) [sssd[be[default]]] [get_port_status] (4): Reseting the status of port 389 for server 'dcpra1.dublin.ad.s3group.com'
(Tue Sep 27 15:30:17 2011) [sssd[be[default]]] [be_resolve_server_done] (4): Found address for server dcpra1.dublin.ad.s3group.com:
[192.168.60.203]
(Tue Sep 27 15:30:17 2011) [sssd[be[default]]] [fo_resolve_service_send] (4): Trying to resolve service 'KERBEROS'
(Tue Sep 27 15:30:17 2011) [sssd[be[default]]] [be_resolve_server_done] (4): Found address for server dcpra1.dublin.ad.s3group.com:
[192.168.60.203]
(Tue Sep 27 15:30:18 2011) [sssd[be[default]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: draco$(a)DUBLIN.AD.S3GROUP.COM
(Tue Sep 27 15:30:18 2011) [sssd[be[default]]] [child_sig_handler] (4): child [20584] finished successfully.
(Tue Sep 27 15:30:18 2011) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'dcpra1.dublin.ad.s3group.com' as 'working'
(Tue Sep 27 15:30:18 2011) [sssd[be[default]]] [set_server_common_status] (4): Marking server 'dcpra1.dublin.ad.s3group.com' as 'working'
(Tue Sep 27 15:38:40 2011) [sssd[be[default]]] [be_get_account_info] (4): Got request for [4098][1][idnumber=203]
(Tue Sep 27 15:38:40 2011) [sssd[be[default]]] [sysdb_attrs_primary_name] (1): Could not determine primary name: [22][Invalid argument]
(Tue Sep 27 15:38:40 2011) [sssd[be[default]]] [sdap_save_user] (1): Failed to save the user - entry has no name attribute
(Tue Sep 27 15:38:40 2011) [sssd[be[default]]] [sdap_save_user] (2): Failed to save user [Unknown]
Is there any help to this? The client is a RHEL-6 machine.
Thanks,
Ondrej
12 years, 6 months