[PATCH] Save all data to sysdb in one transaction
by Sumit Bose
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
12 years, 8 months
[PATCH] Check for controls before using them
by Simo Sorce
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
12 years, 8 months
LDAP connection tracking, sharing and fail-over retry framework
by Eugene Indenbom
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
12 years, 11 months
libnl route callbacks in RHEL5
by Jakub Hrozek
-----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-----
12 years, 11 months
[PATCH] Add dns_discovery_domain option
by Jakub Hrozek
-----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-----
12 years, 11 months
[PATCHES] Refactor proxy.c
by Stephen Gallagher
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/
12 years, 11 months
[PATCH] Make RootDSE optional (master and sssd-1-2)
by Stephen Gallagher
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/
12 years, 11 months
can't connect to openldap using GSSAPI
by Alexander Gordeev
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
12 years, 11 months
[PATCHES] Fix libini_config versions
by Stephen Gallagher
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/
12 years, 11 months