sssd-devel June 2010

sssd-devel@lists.fedorahosted.org

14 participants
74 discussions

[PATCH] Save all data to sysdb in one transaction
by Sumit Bose 23 Sep '10

23 Sep '10

Hi, this patch for master saves all IPA HBAC data in one transaction and proceeds if the sysdb transaction fails. It addresses a review comment from the "Use new schema for HBAC service checks" patch. The first patch changes the handling of the host data to be compatible with the other data. The second removes the individual transactions and introduces a common sysdb transaction. Do we want/need a similar patch for master, too? bye, Sumit

3 9

[PATCH] Check for controls before using them
by Simo Sorce 15 Sep '10

15 Sep '10

Some time ago I added code to fetch the rootdse on connection, but didn't publicize it too much. Attached find 2 patches. 1) Rework the way we store data fetched from the rootdse so the it is more useful and is actually attached to the ldap handle. 2) Check controls are supported before using them. Simo. -- Simo Sorce * Red Hat, Inc * New York

4 10

[PATCH] Add try_inotify option
by Stephen Gallagher 09 Jul '10

09 Jul '10

There are some special cases where inotify cannot be used, even if the host OS claims that it is supported. In these cases, it should be possible to explicitly disable the use of inotify. https://fedorahosted.org/sssd/ticket/484 -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

3 4

LDAP connection tracking, sharing and fail-over retry framework
by Eugene Indenbom 09 Jul '10

09 Jul '10

The patches attached provide a framework for LDAP connection tracking, sharing and fail-over retries in LDAP ID backend, which is designed to address the tickets #468, 464, 465 and 466. The patches are structured as follows: 0001-GSSAPI-ticket-expiry-time-is-returned-from-ldap_chil.patch A small utility patch saving GSSAPI ticket expiry time in sdap_handle for future use. 0002-Added-an-interface-to-query-number-of-configured-and.patch Another utility patch allowing to dynamically determine number of fail-over servers (including resolved through SRV records) 0003-LDAP-connection-usage-tracking-sharing-and-failover-.patch The main patch -- LDAP connection tracking, sharing and fail-over retry framework 0004-Use-new-LDAP-connection-framework-to-get-user-accoun.patch Sample usage of the new LDAP connection framework for user account information request The key object of the framework is sdap_id_op object. It keeps per-request data required for: - LDAP connection usage tracking and sharing - Fail-over retry logic The typical lifespan of sdap_id_op object equals to lifespan of LDAP ID backend request. The usage pattern is as follows: 1. At the beginning of request execution sdap_id_op is created with sdap_id_op_create method 2. When LDAP connection is needed sdap_id_op_connect is called, which obtains the LDAP connection (from cache or establishes new one) and locks the obtained connection for use 3. LDAP query is executed using connection obtained 4. When query completes (succeeds or fails) sdap_id_op_done is called to mark the LDAP connection as no longer used by the backend request. If LDAP query has failed sdap_id_op_done also translates error code into data provider error and provides recommendation for fail-over retry. 5. Fail-over retry continues from step 2. 6. When the backend request completes sdap_id_op is destroyed. Another important object of the framework is sdap_id_conn_cache, which implements LDAP connection caching and sharing logic. As the connection caching logic is completely opaque to BE request code, it can be changed or improved later on with minimal impact on the other code. The connection caching logic proposed in this patch is very similar to the approach implemented in SSSD 1.2: - LDAP connection is established on the first request to LDAP server; - Single LDAP connection is shared between all concurrently executed requests; - LDAP connection is removed from cache when its GSSAPI ticket is about to expire and closed as soon as all BE requests using it (if any) complete; To summarize, this patch will allow us to address the following issues: - To establish only one LDAP connection when 2 or more requests are executed in parallel (ticket #464) - To keep track of LDAP connection usage providing support connection caching and expired (or otherwise unwanted) connection disposal (ticket #468) - Consistent fail-over retry handling: attempt a fail-over retry also when master server goes down during LDAP query execution (ticket #465) - Promptly to close LDAP connection when GSSAPI ticket is about to expire (ticket #466) Please note that the patches are provided only as a material for comments and discussion on solution architecture. I have only made sure that they compile. I am completely open to suggestions and other approaches on how to solve the above problems. Eugene Indenbom

4 38

libnl route callbacks in RHEL5
by Jakub Hrozek 01 Jul '10

01 Jul '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dan, I managed to complete the detection of routes going up/down and the associated SSSD-specific work using libnl 1.1 on Fedora 12/13 based on your code from NetworkManager. However, I ran into some trouble with the RHEL5 version of libnl (1.0-pre5) as it doesn't seem to have support for subscribing to group (nl_socket_add_membership etc.). Can you recall if there is any workaround with the old libnl code? The last resort would be to not support this functionality on RHEL5, but I'd like to avoid that if possible. Thank you for your time! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrlmQACgkQHsardTLnvCV8gwCfYmp6i+7FaK1I9L1Dgfh7TRFX hNcAniGqFI7ZxVToQEdd35GSD+D8bqkx =G1EH -----END PGP SIGNATURE-----

2 1

[PATCH] Add dns_discovery_domain option
by Jakub Hrozek 30 Jun '10

30 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The service discovery used to use the SSSD domain name to perform DNS queries. This is not an optimal solution, for example from the point of view of authconfig. This patch introduces a new option "dns_discovery_domain" that allows to set the domain part of a DNS SRV query. If this option is not set, the default behavior is to use the domain part of the machine's hostname. Fixes: #479 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkwI5IQACgkQHsardTLnvCWHQwCfTLSN7cFHv6X9cSim05EahDiY c6wAoLRlCNnh60K2gmMwgAMd0j5r+6T0 =N4jU -----END PGP SIGNATURE-----

2 7

[PATCHES] Refactor proxy.c
by Stephen Gallagher 30 Jun '10

30 Jun '10

Patch 0001: Rename proxy_ctx to proxy_id_ctx for clarity Patch 0002: Split proxy.c into smaller files proxy.c was growing too large to manage (and some graphical development tools could no longer open it because of memory limitations). This patch splits proxy.c into the following files: proxy_init.c: Setup routines for the plugin proxy_id.c: Functions to handle user and group lookups proxy_auth.c: Functions to handle PAM interactions proxy_common.c: Common utility routines There are no functional changes in these patches (I tested them with nss_ldapd and pam_krb5.so). They simply make the code more maintainable. These changes are for master only. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 2

[PATCH] Make RootDSE optional (master and sssd-1-2)
by Stephen Gallagher 28 Jun '10

28 Jun '10

In violation of the standard, some LDAP servers control access to the RootDSE, thus preventing us from being able to read it before performing a bind. This patch will allow us to continue on if the RootDSE was inaccessible. All of the places that we use the return value of the RootDSE after this are already checked for NULL and use sane defaults if the RootDSE is unavailable. I was poking around related code today and realized that the fix for this was actually very easy (as at present we are only using the result of the rootDSE lookup to determine if we can perform a GSSAPI bind, but it's already covered to just skip the check and assume that the server is capable if the rootDSE object is empty. There is one other place, in sdap_initgr_nested_send() where we have a TODO in place to use the rootDSE to detect deref and ASQ support, but we are not actually doing so yet anyway. I think this will solve https://fedorahosted.org/sssd/ticket/497 easily, and I think it's worth re-targeting to 1.2.2. This patch applies to both master and sssd-1-2. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 4

can't connect to openldap using GSSAPI
by Alexander Gordeev 28 Jun '10

28 Jun '10

Hi All! Sorry if I've chosen the wrong place to write. If there is a better place to ask for support, please tell me. I have problems retrieving user and group data from ldap using sssd. I use openldap as ldap server. The only allowed authentication mechanism is GSSAPI. All other are turned off explicitly. I've read all sssd's man pages and I'm quite sure that this is one of use cases that sssd should be able to handle. But it can't. :( BTW, I use Debian testing and installed it from Debian's repositories. The version is 1.2.0-1 which is actually 1.2.0 unmodified. Here are some appropriate pieces from slapd's debug log: 1. running 'id user' when sssd is enabled through nsswitch.conf Jun 18 13:58:17 authvm slapd[11723]: conn=1950 fd=23 ACCEPT from IP=192.168.0.13:53362 (IP=0.0.0.0:636) Jun 18 13:58:17 authvm slapd[11723]: conn=1950 fd=23 TLS established tls_ssf=128 ssf=128 Jun 18 13:58:17 authvm slapd[11723]: conn=1950 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Jun 18 13:58:17 authvm slapd[11723]: conn=1950 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Jun 18 13:58:17 authvm slapd[11723]: conn=1950 op=1 UNBIND Jun 18 13:58:17 authvm slapd[11723]: conn=1950 fd=23 closed 2. kinit -k -t /etc/krb5.keytab && ldapsearch Jun 18 14:07:03 authvm slapd[29021]: conn=2 fd=15 ACCEPT from IP=192.168.0.13:42560 (IP=0.0.0.0:636) Jun 18 14:07:03 authvm slapd[29021]: conn=2 fd=15 TLS established tls_ssf=128 ssf=128 Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=0 SRCH attr=supportedSASLMechanisms Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=1 BIND dn="" method=163 Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=2 BIND dn="" method=163 Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=2 RESULT tag=97 err=14 text=SASL(0): successful result: Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 BIND dn="" method=163 Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 BIND authcid="host/desktopvm.gnet@GNET" authzid="host/desktopvm.gnet@GNET" Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 BIND dn="uid=host/desktopvm.gnet,cn=gnet,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=128 Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=3 RESULT tag=97 err=0 text= Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=4 SRCH base="dc=gnet" scope=2 deref=0 filter="(objectClass=*)" Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=4 SEARCH RESULT tag=101 err=0 nentries=9 text= Jun 18 14:07:03 authvm slapd[29021]: conn=2 op=5 UNBIND Jun 18 14:07:03 authvm slapd[29021]: conn=2 fd=15 closed You can clearly see the difference. sssd doesn't even try to authenticate using SASL. Here is sssd's debug log at the same time (debug level = 10): (Fri Jun 18 13:58:17 2010) [sssd[nss]] [get_client_cred] (9): Client creds: euid[0] egid[0] pid[24567]. (Fri Jun 18 13:58:17 2010) [sssd[nss]] [accept_fd_handler] (4): Client connected! (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_cmd_get_version] (5): Received client version [1]. (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_cmd_get_version] (5): Offered version [1]. (Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [alex] from [<ALL>] (Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [alex@GNET] (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_dp_send_acct_req_create] (4): Sending request for [GNET][4097][1][name=alex] (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_add_timeout] (8): 0x80998d8 (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sbus_dispatch] (9): dbus conn: 80A7088 (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sbus_dispatch] (9): Dispatching. (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sbus_message_handler] (9): Received SBUS method [getAccountInfo] (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [be_get_account_info] (4): Got request for [4097][1][name=alex] (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP' (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_server_status] (7): Status of server 'authvm.gnet' is 'name resolved' (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_port_status] (7): Port status of port 636 for server 'authvm.gnet' is 'not working' (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_port_status] (4): Reseting the status of port 636 for server 'authvm.gnet' (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [get_server_status] (7): Status of server 'authvm.gnet' is 'name resolved' (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [be_resolve_server_done] (4): Found address for server authvm.gnet: [192.168.0.14] (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_rootdse_send] (9): Getting rootdse (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(objectclass=*)][]. (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_ldap_connect_callback_add] (9): New LDAP connection to [ldaps://authvm.gnet:636] with fd [19]. (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 1 (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_process_result] (8): Trace: sh[0x80acfb0], connected[1], ops[0x80c6a00], ldap[0x80acd50] (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_parse_entry] (9): OriginalDN: []. (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_process_result] (8): Trace: sh[0x80acfb0], connected[1], ops[0x80c6a00], ldap[0x80acd50] (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_get_rootdse_done] (9): Got rootdse (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [fo_set_port_status] (4): Marking port 636 of server 'authvm.gnet' as 'not working' (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [sdap_handle_release] (8): Trace: sh[0x80acfb0], connected[1], ops[(nil)], ldap[0x80acd50], destructor_lock[0], release_memory[0] (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [remove_connection_callback] (9): Successfully removed connection callback. (Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [users_get_connect_done] (0): Authentication mechanism not Supported by server(Fri Jun 18 13:58:17 2010) [sssd[be[GNET]]] [acctinfo_callback] (4): Request processed. Returned 3,95,User lookup failed (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_remove_timeout] (8): 0x80998d8 (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_dispatch] (9): dbus conn: 80999E8 (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sbus_dispatch] (9): Dispatching. (Fri Jun 18 13:58:17 2010) [sssd[nss]] [sss_dp_get_reply] (4): Got reply (3, 95, User lookup failed) from Data Provider (Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam_dp_callback] (2): Unable to get information from Data Provider Error: 3, 95, User lookup failed Will try to return what we have in cache (Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam_callback] (2): No matching domain found for [alex], fail! (Fri Jun 18 13:58:17 2010) [sssd[nss]] [nss_cmd_getpwnam_callback] (2): No results for getpwnam call (Fri Jun 18 13:58:17 2010) [sssd[nss]] [client_recv] (5): Client disconnected! Please help me to get this working. I've searched the net but didn't found anything alike. I've also attached my sssd.conf and ldap.conf for reference. -- Alexander

6 26

[PATCHES] Fix libini_config versions
by Stephen Gallagher 28 Jun '10

28 Jun '10

I realized today that the RPM packages for SSSD had the wrong version for libini_config. The upstream project revision was 0.4.0, but we were building RPMs that claimed it was 0.5.0. To further confuse things, in the master branch we actually HAD bumped to 0.5.0 (with a soname bump as well). In order to fix this, I've attached patches to rev the version of libini_config in SSSD 1.2 to the version of 0.5.1, and we will rename the soname bumped version in master to 0.6.0. The reason for going with 0.5.1 is to guarantee that upgrades occur cleanly (in case someone had inadvertently installed a 0.5.0 package from master, which would be incompatible). The attached patches are as follows: 0001-Drop-release-requirement-from-versions.patch: There's no reason that we should be requiring a specific release number for the subpackages, since we always rev the version number when interfaces are added. 0002-Bump-libini_config-version-to-0.5.1.patch (sssd-1-2 only): Bump the 1.2 branch version to 0.5.1 0002-Bump-libini_config-version-to-0.6.0.patch: Bump the master branch version to 0.6.0 -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel June 2010