sssd-devel January 2017

sssd-devel@lists.fedorahosted.org

18 participants
61 discussions

[sssd PR#122][opened] Port integration tests to python3
by fidencio 17 Jan '17

17 Jan '17

URL: https://github.com/SSSD/sssd/pull/122 Author: lslebodn Title: #122: Port integration tests to python3 Action: opened PR body: """ Attached patches fixed python 2/3 compatibility of integration tests. You will need to install following packages in fedora: python3-ldb, python3-pyldap, python3-requests And for testing purposes you can use ``` make intgcheck-run PYTHON2=/usr/bin/python2 make intgcheck-run PYTHON2=/usr/bin/python3 ``` I will need to figure out how to incorporate it into CI script. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/122/head:pr122 git checkout pr122

1 4

[sssd PR#125][opened] RESPONDER: Adding of return value checking
by fidencio 16 Jan '17

16 Jan '17

URL: https://github.com/SSSD/sssd/pull/125 Author: celestian Title: #125: RESPONDER: Adding of return value checking Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/125/head:pr125 git checkout pr125

1 4

[sssd PR#124][opened] Fix a segfault in IFP's GetUserAttr
by fidencio 16 Jan '17

16 Jan '17

URL: https://github.com/SSSD/sssd/pull/124 Author: jhrozek Title: #124: Fix a segfault in IFP's GetUserAttr Action: opened PR body: """ This PR fixes a crash in GetUserAttr. To reproduce, it's enough to: dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:admin array:string:name """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/124/head:pr124 git checkout pr124

1 8

[sssd PR#119][opened] Remove unused Attr type
by fidencio 16 Jan '17

16 Jan '17

URL: https://github.com/SSSD/sssd/pull/119 Author: lslebodn Title: #119: Remove unused Attr type Action: opened PR body: """ I noticed that there is an unused parameter in `users_get_send`. But it went deeper and more code could be removed. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/119/head:pr119 git checkout pr119

1 8

[sssd PR#123][opened] MAN: sssctl debug level
by fidencio 14 Jan '17

14 Jan '17

URL: https://github.com/SSSD/sssd/pull/123 Author: mzidek-rh Title: #123: MAN: sssctl debug level Action: opened PR body: """ Use tools specific reference to debog level explanation in sssctl man page. Resolves: https://fedorahosted.org/sssd/ticket/3085 """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/123/head:pr123 git checkout pr123

1 6

[sssd PR#110][opened] Add more DEBUG messages to help admins diagnose Kerberos login failures
by fidencio 13 Jan '17

13 Jan '17

URL: https://github.com/SSSD/sssd/pull/110 Author: jhrozek Title: #110: Add more DEBUG messages to help admins diagnose Kerberos login failures Action: opened PR body: """ This PR contains two trivial (code-wise) patches that just add one DEBUG message each. It's quite common for admins to get stuck diagnosing issues where the krb5_child process exists with system error. Moreover, many system errors are caused by issues during Kerberos ticket validation where the second patch tries to help to give some tips. I hope the first patch should be OK to merge. With the second one, I was struggling a bit to find some useful debug message. If anyone can think about a better one, I'm all ears. Also, if the DEBUG message would be too misleading in the general case, I'm equally fine with dropping the second patch. At least the first one would help to avoid admins asking for help if all we would tell them is to go and look into the krb5_child.log anyway -- so IMO it makes sense to just put that info to a debug message. """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/110/head:pr110 git checkout pr110

1 15

Question about tevent request flow in ipa_add_ad_memberships_get_next()
by Justin Stephenson 13 Jan '17

13 Jan '17

Hello all, I was able to reproduce a customer issue with IPA - AD trust external memberships group processing caused by replication conflicts, in this case it is related to a permission that is tied to the IDM trust group through RBAC(sorry, I have not raised a ticket for it just yet). This issue is evident in the logs here: [add_ad_user_to_cached_groups] (0x4000): Group [cn=custompermission+nsuniqueid=92931c98-d84011e6-9a0896c1-71a1e36a,cn=permissions,cn=pbac,dc=jstephen,dc=local] not in the cache. <snip> [ipa_add_ad_memberships_get_next] (0x0040): Invalid group DN [cn=custompermission+nsuniqueid=92931c98-d84011e6-9a0896c1-71a1e36a,cn=permissions,cn=pbac,dc=jstephen,dc=local]. [ipa_add_ad_memberships_done] (0x0040): ipa_add_ad_memberships request failed. It is clear the problem occurs here val = ldb_dn_get_rdn_val(group_dn); if (val == NULL || val->data == NULL) { DEBUG(SSSDBG_OP_FAILURE, "Invalid group DN [%s].\n", state->groups[state->iter]); ret = EINVAL; goto fail; } I was looking at writing a patch which skips this group instead of failing the operation, though perhaps this is not the best method to solve this issue. I see that ipa_add_ad_memberships_get_next() sets a callback to ipa_add_ad_memberships_get_group_done() which then calls ipa_add_ad_memberships_get_next() again for the next group to be processed. I tried the following patch based on this, but it does not work and causes a major failure which results in SSSD restarting the backend entirely: diff --git a/src/providers/ipa/ipa_subdomains_ext_groups.c b/src/providers/ipa/ipa_subdomains_ext_groups.c index 90460bc..1e2e0c2 100644 --- a/src/providers/ipa/ipa_subdomains_ext_groups.c +++ b/src/providers/ipa/ipa_subdomains_ext_groups.c @@ -867,9 +867,9 @@ static void ipa_add_ad_memberships_get_next(struct tevent_req *req) val = ldb_dn_get_rdn_val(group_dn); if (val == NULL || val->data == NULL) { DEBUG(SSSDBG_OP_FAILURE, - "Invalid group DN [%s].\n", state->groups[state->iter]); - ret = EINVAL; - goto fail; + "Invalid group DN [%s]. Skipping\n", state->groups[state->iter]); + state->iter++; + ipa_add_ad_memberships_get_next(req); } fq_name = (const char *) val->data; I suspect I am missing something obvious with the tevent flow occurring here, I was hoping for some guidance on this. Kind regards, Justin Stephenson

1 0

[sssd PR#109][opened] SSSCTL: fix netgroup-show parsing
by fidencio 12 Jan '17

12 Jan '17

URL: https://github.com/SSSD/sssd/pull/109 Author: justin-stephenson Title: #109: SSSCTL: fix netgroup-show parsing Action: opened PR body: """ the ldb Name attribute is not fully-qualified for netgroups like it is for user and group objects, sssctl should skip sss_output_name() for netgroup entries. Resolves: https://fedorahosted.org/sssd/ticket/3267 -- Reproduced easily by adding a netgroup(in IDM or otherwise), getent netgroup <netgroupname>, sssctl netgroup-show <netgroupname> """ To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/109/head:pr109 git checkout pr109

2 22

Handling of offline requests in sssd-1-13 and older
by Jakub Hrozek 11 Jan '17

11 Jan '17

Hi, there was a customer complaining about fail over not reconnecting as fast with sssd-1-13 as it did with sssd-1-14. The issue they were seeing was that if sssd was offline, but the server came back up, it still took sssd the full offline timeout cycle to attempt to reconnect, even though we say that auth attempts are always done against the server. I traced it to the difference in handling the offline state in the providers themselves. With sssd-1-14, the only place that decides whether to contact the providers is the DP itself. If the fast flag is set and the provider is offline, we always return the offline error, if the fast flag is unset, we ask the provider. Now, the difference is that in sssd-1-13, we also have this code: https://github.com/jhrozek/sssd/commit/397f956365dd320194c792c372625cdfdaa3… that would shortcut the request w/o trying to connect if the back end was offline. I think this code is wrong and what sssd-1-14 does is correct. Therefore, I would like to just nuke the code that checks if the back end is offline from the providers and let them always reconnect -- but I'm not sure if this is safe to do in the LTM branch. In theory, laptop users could complain about too frequent reconnects, however, I haven't seen any complains with sssd-1-14 so far. Opinions?

1 0

Group renaming issue when "id_provider = ldap" is set.
by Fabiano Fidêncio 11 Jan '17

11 Jan '17

I've been working on rhbz#1401241 (https://bugzilla.redhat.com/show_bug.cgi?id=1401241) and I'd like to clarify some doubts that showed up. So, let's consider that there's a group called "foo" and user "user" is part of this group. Group "foo" gets renamed to "bar'. Now. let me describe what I've found out considering "id_provider = ldap" and "id_provider = ad" - id_provider = ldap: cache has "foo" entry After renaming "foo" to "bar" cache has entry "bar" added both entries have the same gid - id_provider = ad cache has "foo" entry After renaming "foo" to "bar" nothing is changed in the cache Any of these situation look exactly right for me (and here I'm probably wrong). My expectations are that we should, for both cases: - check for the gid in the cache - update the entry So in the ldap case we would avoid having two entries with the same gid and in the ad case we would be able to properly the updated name of the group that the user is part of. Does it make sense? Summing up the questions: - When a group has its name changed, shall we update the entry that contains its name (and then all memberOf that contains the old name?)? - In case not, following what "id_provider = ad" does would be a good fix for the issue? Looking forward to hearing your opinion! Best Regards, -- Fabiano Fidêncio

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel January 2017