sssd-devel June 2012

sssd-devel@lists.fedorahosted.org

20 participants
65 discussions

[PATCH] Allow more libldap debugging
by Jakub Hrozek 28 Nov '12

28 Nov '12

This patch should not be pushed to master, but I would like to get it reviewed anyway. It should be used to provide a custom build for users experiencing cases where ldap_search_ext would block (c.f. https://bugzilla.redhat.com/show_bug.cgi?id=728343) For example: export SSSD_DEBUG_LDAP_SEARCH="0xffff" would set LDAP_DEBUG_ANY The attached patch applies cleanly on the RHEL6.1 branch. I also have a version that applies on master/1.5 if needed.

4 7

[PATCH] - SIGUSR2 should force SSSD to reread resolv.conf as well
by Ariel Barria 05 Sep '12

05 Sep '12

https://fedorahosted.org/sssd/ticket/1045

5 7

[PRELIMINARY][PATCHES] Primary server support in SSSD
by Jan Zelený 01 Aug '12

01 Aug '12

Hi everybody, I'm sending some patches which implement the primary server support as I see it. It it based on comment #6 in the related ticket https://fedorahosted.org/sssd/ticket/1128 Patch #0001 basically adds the necessary support in failover code Patches #0002 - #0004 extend this support in each provider Patch #0005 documents the new concept in failover section in man pages Patches #0006 - #0008 add new options for each provider which utilize this concept. Just briefly about the approach. When adding a new server to the list of servers related to a service, each server can be marked either as primary or secondary. When selecting new server from failover list, the algorithm iterates over the list twice - first it tries to look for primary server and if none is found, it tries also secondary server. If a server is returned from failover, and it is not primary server, a timeout is set (currently hard-coded for 30 seconds) for primary server lookup. This timeout is rescheduled until a primary server is found. If a primary server (either working or neutral) is found after this timeout, status of the backend is reset, i.e. first all offline and then all online callbacks are called. This is done to interrupt connection to the secondary server in favor of new connection to a primary server. I have just couple concerns about things which I have yet to inspect. First of all when connection to the old server is interrupted, what if an operation is currently in progress on this connection? I know ticket #1027 induces similar scenario. Maybe to kill two birds with one stone I could design an extension to immediately invoke callbacks of all operations running on existing connection. What do you think about that? My second concern is about port status timeout. After some time a port is marked as neutral if originally marked as not-working. That effectively leads to second attempt to primary server reconnection being successful even though the server is still not running. As a result, an unnecessary reconnection to secondary server is performed once some data are needed from the server. Thank you very much for your opinions on this Jan

4 14

[PATCH][PRELIMINARY] sudo: send username and uid while requesting default options
by Pavel Březina 24 Jul '12

24 Jul '12

https://fedorahosted.org/sssd/ticket/1239 [PATCH 1/2] Finally removes EOK constant from sudo api header. It is not used in the SUDO code so it does not require their changes. [PATCH 2/2] This does what is requested in the ticket. It seems to be very huge but in fact it is mainly changing the variable. Basically I tried to get rid of domain ctx where possible, leave it only in initgroups part and use command ctx elsewhere. The in-memory cache is not yet implemented, I want to discuss the possible ways of doing it. The basic problem is that we need to get the domain during the request for default options. How will we do it? I think there are two options: 1. always try to perform the initgroups - find the domain and the check the in-memory cache (which may be slow if the user is in the last domain, but that will be probably handled as part of https://fedorahosted.org/sssd/ticket/1126 2. store uid:username = domain in the in-memory cache (same cache as results or a new one?) This patch contains a modified version of sysdb_get_sudo_user_info() where the uid is not mandatory. I want to replace this function with sysdb_sudo_get_user_groups() (or make it generic and place it in sysdb_ops?) because the groupnames are the only thing we don't know. However this requires a modification of the data provider protocol as well so I'm keeping it for later.

4 32

[PATCH] ding-libs spec file update
by Jan Zelený 24 Jul '12

24 Jul '12

Attached patch contains some changes that I'd like to propose. All modifications are based on spec file for Fedora rawhide. Thanks Jan

3 2

[PATCHES] Add Active Directory identity, auth and chpass providers to SSSD
by Stephen Gallagher 06 Jul '12

06 Jul '12

These patches add a new provider to SSSD: the AD provider. This provider is designed to simplify communication with Active Directory 2008 R2 and later. It may work with earlier versions of Active Directory, but we're not planning to test or support them. This set of patches adds the identity, auth and chpass providers. I will be providing an access provider as well, but it's not ready and I wanted to land these patches sooner rather than later. I also have not added any manpages or the SSSDConfig API entries for the new options yet. Those are also still forthcoming. This provider can be configured for testing as follows: {{{ [domain/AD.DOMAIN] id_provider = ad auth_provider = ad chpass_provider = ad ad_server = dc1.example.com, dc2.example.com, _srv_ ad_domain = AD.DOMAIN case_sensitive = False }}} That should be all the configuration needed. The ad_server line can be ommitted if SRV records for AD domain controllers exist in DNS. I'm working on a way to eliminate the need for 'case_sensitive = False' as well, but that's trickier than it sounds because it needs to be set in the NSS responder, not just the back-end. Patches 0001-0005 are minor enhancements to utility. Patch 0001: Some logging enhancements for krb5_child Patch 0002: KRB5_LOCATOR: Print the filename that couldn't be opened Patch 0003: Drop memctx parameter of krb5_try_kdcip and fix a small memory leak in the process. Patch 0004: Converge the assorted IPA and KRB5 routines for setting up the online/offline handlers into a common function that can also be reused for the AD provider. Patch 0005: Just change the name of the "AD-compatible" schema map for the pure LDAP provider so it won't conflict with the one I'm adding to the AD provider. The following two patches add the "meat" of the new functionality. Sorry for the size of the patches, but I couldn't find a sensible way to break them up any further. Patch 0006: Add AD identity provider Patch 0007: Add AD auth and chpass providers

4 10

Mixing passwd accounts with LDAP groups issue
by Jan Engelhardt 05 Jul '12

05 Jul '12

Hi, I have my user account listed in both /etc/passwd, /etc/shadow and the LDAP tree. However, only the LDAP tree has the supplementary group list info. In sssd-1.8.3 and earlier, issuing `getent passwd jengelh` would return me all the (primary and) secondary groups I am a mamber of. Something like uid=25121(jengelh) gid=100(users) groups=100(users),399(abuild),56485(friends), 27072(netitwork),31327(rdesktop) In sssd-1.8.93, this is no longer the case, and instead I get: uid=25121(jengelh) gid=100(users) groups=100(users),33(video) `getent group 31327` has to say: rdesktop:*:31327:fz,mm,mk `ldapsearch -x cn=rdesktop`: dn: cn=rdesktop,ou=groups,o=borg objectClass: posixGroup objectClass: top objectClass: groupOfNames objectClass: sambaGroupMapping objectClass: zarafa-group cn: rdesktop description: Remote Desktop Users member: uid=jengelh,ou=users,o=company member: uid=fz,ou=users,o=company member: uid=mm,ou=users,o=company member: uid=mk,ou=users,o=company sambaGroupType: 2 displayName: Remote Desktop gidNumber: 31327 zarafaHidden: 1 sambaSID: S-1-5-21-2434340325-2384729352-2357823451-12387 If I comment about my entry in /etc/passwd, I do receive the groups from LDAP again, but naturally I am missing out on the local groups: uid=25121(jengelh) gid=27072(netitwork) groups=27072(netitwork),33(video),56485(friends), 31327(rdesktop),399(abuild) It seems like if the user entry is satisfiable from /etc/passwd, group lookup is also only limited to passwd. This breaks with behavior of all previously seen implementations (pam_ldap,..) which strictly separated user and group lookups like NSS's design set forth a handful of decades ago. Side-note supplement: And then there is the cache coming into play, which provided for a handful of surprises on its own. Removing the comment hash mark # from my entry in /etc/passwd again after the previous lookup, I then get *all* memberships from both local and LDAP: uid=25121(jengelh) gid=100(users) groups=100(users),33(video),56485(friends),31327(rdesktop), 27072(netitwork),399(abuild) so the look-in-passwd-only "misfeature" is not even consistent :)

2 5

My solution to keep an update cache of all LDAP entries. Is there a better way?
by Mark London 03 Jul '12

03 Jul '12

Here is my solution to have a persistant uptodate local cache of all ldap entries, so as to avoid very long delays when a user issues a command that causes a large number of LDAP lookups, i.e. by doing a "ls -l /home": enumerate = true enum_cache_timeout = 86400 ldap_purge_cache_timeout = 0 ldap_enumeration_refresh_timeout = 300 I set the cache timeout to be 24 hours, and do an enumerate every 5 minutes. What I would like to know, is why such long delays (i.e. minutes) occurs when doing an "ls -l /home". Is it because it has to write out each entry into the local database? Just curious. :) Thanks. Mark London

3 2

No negative cache with sssd_nss
by Jan Engelhardt 03 Jul '12

03 Jul '12

Hi, it seems that sssd does not cache negative responses from the shadow/NSS backend. This is particularly observable when repeatedly querying for groups that do not exist in /etc/group, but do exist in LDAP. sssd is configured to search local db, plus another server's LDAP tree. If the group "clients" is in LDAP, the following testcase below runs in about ~8.5 sec on the reference machine. However, if I add the "clients" group to the end of /etc/group, it completes in like 1.3 sec. When only in LDAP, tcpdump shows no activity on port 389, so at least the positive caching does work. However, the negative response from NSS increases the execution time significantly, which leads me to believe that part is not cached. ---8<--- #include <stdio.h> #include <stdlib.h> #include <pwd.h> #include <grp.h> int main(void) { unsigned int i; struct group *g; for (i = 0; i < 50000; ++i) { g = getgrnam("clients"); } return EXIT_SUCCESS; }

3 12

[PATCH] LDAP: Print extended failure message for SASL bind
by Stephen Gallagher 02 Jul '12

02 Jul '12

Adds a useful DEBUG message if SASL binds fail. This was helpful in tracking down issues while working on the Active Directory ID provider.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel June 2012