[sssd PR#475][opened] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
4:02 p.m.
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
Action: opened
PR body:
"""
NOTE: This fix doesn't address the segfault, only the condition that led
to it. I would prefer to track the segfault and the search base issues
separately
NOTE2: I didn't have much time to test this PR yet. I'm mostly submitting
it to get feedback
Please see the full commit message below. I'm really confused about this
issue mostly because it seems we've had this bug for quite some time but did
not see it. I would be glad if somebody helps me understand if iterating
over all domains and adding all domains that are not yet present in the
ad_id_ctx->ad_options->sdap_id_ctx->sdom list is correct or not
The commit message follows:
Resolves: https://pagure.io/SSSD/sssd/issue/3594
Previously, sdap_domain_subdom_add() was called when a new ad_id_ctx was
being instantiated in the AD subdomains provider. The
sdap_domain_subdom_add() call iterates over all known subdomains and adds a
sdap_domain instance for every domain that is not present in an existing
sdap_domain list.
This is problematic for the AD subdomains provider e.g in this scenario
found by downstream ticket #3594:
- there is a domain child1.sssdad.com the sssd is joined to
- the subdomain provider auto-discovers ssdad_tree.com and
sssdad.com, in this order (which is important). The list of
sss_domain_info objects is updated in this order, too
- for each domain, ad_subdom_ad_ctx_new() is called. This function
creates a new ad_id_ctx and calls sdap_domain_subdom_add() to
add an sdap_domain object into the sdap_id_ctx. The
sdap_domain_subdom_add() call adds both domains to the list
-- for the sssdad_tree subdomain is is ok, because subsequent
calls only use the first sdap_domain object which is
ssdad_tree.com (remember, order is important)
-- for the sssdad.com domain, ssdad_tree.com is added first,
which then causes all searches in the sssdad.com to have a
search base from ssdad_tree.com
Because the sdap_domain instance in sdap_id_ctx should not be a list, but a
single domain, this patch adds a utility function that creates an
sdap_domain instance for a single subdomain instance.
"""
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/475/head:pr475
git checkout pr475
2:48 p.m.
New subject: [sssd PR#475][comment] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
jhrozek commented:
"""
I'm just adding Changes Requested here myself because as I said on Thursday's
meeting, I'd like to make it harder to introduce a bug like this in the future.
@lslebodn if it's not too much work for you, could you please prepare me another
machine that reproduces the bug? Or just tell me where to insert a test breakpoint into
which downstream test and I'll set up the environment myself.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-356091703
10:13 a.m.
New subject: [sssd PR#475][+Changes requested] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
Label: +Changes requested
3:39 p.m.
New subject: [sssd PR#475][comment] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
jhrozek commented:
"""
I spent some today trying to understand this issue better so that I can explain it better
in the PR. I think the patch is correct as it was submitted the first time but I'm
also afraid that the relation between the different structures in SSSD code has reached a
critical point where it's really hard to understand how the structures were
designed..
So first, about the bug. It only happens where the cache is already primed with subdomain
objects. Then, the AD subdomains code will call `ad_subdom_reinit` which reads the
subdomains from sysdb. Then `ads_store_sdap_subdom()` calls `sdap_domain_subdom_add()`
which creates a `sdap_domain` struct for each subdomain. Here I think both the linked list
of `sdap_domain` objects and the `sdap_domain_subdom_add` call are correct.
Then, for each of the `sdap_domain`, we call `ad_subdom_ad_ctx_new()` which creates
`ad_id_ctx` for every subdomain. This internally used to call `sdap_domain_subdom_add()`
which I think was wrong, because inside, `sdap_domain_subdom_add()` iterates over all
domains and appends a `sdap_domain` structure per domain to the `sdap_opts` structure.
I added some DEBUG messages into the code, which show what happens:
```
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [ad_subdom_ad_ctx_new] (0x0040):
INFO: Creating ad_ctx for sssdad.com
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [sdap_domain_subdom_add]
(0x0040): INFO: Parent: child1.sssdad.com
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [sss_domain_get_state] (0x1000):
Domain sssdad_tree.com is Active
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [sdap_domain_subdom_add]
(0x0040): INFO: Iterating over domain sssdad_tree.com
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [sdap_domain_subdom_add]
(0x0400): subdomain sssdad_tree.com is a new one, will create a new sdap domain object
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [sss_domain_get_state] (0x1000):
Domain sssdad.com is Active
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [sdap_domain_subdom_add]
(0x0040): INFO: Iterating over domain sssdad.com
(Tue Jan 16 16:25:19 2018) [sssd[be[child1.sssdad.com]]] [sdap_domain_subdom_add]
(0x0400): subdomain sssdad.com is a new one, will create a new sdap domain object
```
So here, for domain `sssdad.com`, the linked list of `sdap_domain` structures is
`sssdad_tree.com->sssdad.com`. And later, the code that tries to look up the trusted
domains just uses the first one, which in this case is `sssdad_tree.com` for the
`sssdad.com` domain:
```
853 subreq = sdap_search_bases_send(state, state->ev, state->opts,
854 sdap_id_op_handle(state->sdap_op),
855 state->opts->sdom->search_bases,
```
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-358115852
3:55 p.m.
New subject: [sssd PR#475][comment] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
jhrozek commented:
"""
Umm OK, right what I wrote the previous wall of text, I realized the patch might have been
wrong. But at the same time. I was initially going to say that a single `sdap_opts` can
only ever contain a single `sdap_domain` for "self", but looking at e.g.
`sdap_ad_check_domain_local_groups()` or ` ad_get_dom_ldap_conn()` it looks like all
domains should be represented by `sdap_domain` so that we can reach `ad_id_ctx` of another
domain..correct? @sumit-bose do you maybe remember?
If that's the case, then the right way to solve this would be to call
`sdap_domain_get()` instead of dereferencing the `opts->sdom`..
We should really get this documented one way or another.. (and we have a ticket
but..time..)
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-358120530
3:22 p.m.
New subject: [sssd PR#475][synchronized] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
Action: synchronized
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/475/head:pr475
git checkout pr475
3:23 p.m.
New subject: [sssd PR#475][comment] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
jhrozek commented:
"""
New patch that is much simpler and looks up the right sdap_domain was pushed.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-358450106
3:23 p.m.
New subject: [sssd PR#475][-Changes requested] LDAP: Only add a sdap_domain instance for the current domain when instantiating a new ad_id_ctx
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: LDAP: Only add a sdap_domain instance for the current domain when
instantiating a new ad_id_ctx
Label: -Changes requested
3:27 p.m.
New subject: [sssd PR#475][edited] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: AD: Use the right sdap_domain for the forest root
Action: edited
Changed field: title
Original value:
"""
LDAP: Only add a sdap_domain instance for the current domain when instantiating a new
ad_id_ctx
"""
3:53 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
sumit-bose commented:
"""
Thank you very much for the new version. The patch makes sense and it is much clearer now
where the issue is. I've added two inline comments about the code in general.
I'd didn't run tests yet but will try to reproduce the issue later today.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-358595128
5:13 a.m.
New subject: [sssd PR#475][synchronized] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: AD: Use the right sdap_domain for the forest root
Action: synchronized
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/475/head:pr475
git checkout pr475
5:15 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
jhrozek commented:
"""
On Thu, Jan 18, 2018 at 01:53:18AM -0800, sumit-bose wrote:
Thank you very much for the new version. The patch makes sense and it
is much clearer now where the issue is. I've added two inline comments about the code
in general.
I'm still a bit sad that it took me too long to remember what the
relationship between the structures is or should be. The patch itelf is
trivial, but figuring out the correct way of fixing the bug took longer
than it should..
I'd didn't run tests yet but will try to reproduce the issue later today.
Note that this was not trivial to reproduce. The downstream tests seem
to provoke the right order of the domains and at the moment, I still
have access to the environment provided by @lslebodn which reproduced
the issue. Please ping either of us to get access..
A new patch that should address both of your comments was pushed.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-358616587
5:24 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
lslebodn commented:
"""
On (18/01/18 03:15), Jakub Hrozek wrote:
> I'd didn't run tests yet but will try to reproduce the
issue later today.
Note that this was not trivial to reproduce. The downstream tests seem
to provoke the right order of the domains and at the moment, I still
have access to the environment provided by @lslebodn which reproduced
the issue. Please ping either of us to get access..
A new patch that should address both of your comments was pushed.
Don't worry.
I will run tests for final version of the patch.
LS
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-358618453
1:49 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
sumit-bose commented:
"""
The code looks good and does not cause any issues for me.
Unfortunately I was not able to reproduce the issue, mainly because I currently do not
have a chance to add a third AD domain to my test environment. @lslebodn, would you mind
to run the tests?
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-358891271
1:29 p.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
jhrozek commented:
"""
Hi @lslebodn I would like to merge this code also to downstream during this week, I wonder
if you already had some time to run tests with the latest patch?
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-359537401
7:52 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
lslebodn commented:
"""
Sure I'll run regression tests.
Sorry for late reply. BTW I had an assumption that current version of PR is not final
https://github.com/SSSD/sssd/pull/475#issuecomment-358618453.
It's my fault.
:wq
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-359796798
10:08 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
jhrozek commented:
"""
thank you, it would be nice to add the link to the test to the downstream bugzilla as
well.
And unless you have something super-urgent, I'd like to ask for this to be done quite
soon, because we need to patch downstream ASAP.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-360184202
9:41 a.m.
New subject: [sssd PR#475][+Changes requested] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
Label: +Changes requested
11:07 a.m.
New subject: [sssd PR#475][-Changes requested] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
Label: -Changes requested
11:27 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
lslebodn commented:
"""
I ran ad test suite and it cause crashes with direct AD domain. Nobody was able to
authenticate.
```
sh# gdb /usr/libexec/sssd/sssd_be coredump
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-110.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/libexec/sssd/sssd_be...Reading symbols from
/usr/lib/debug/usr/libexec/sssd/sssd_be.debug...done.
done.
[New LWP 16171]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/libexec/sssd/sssd_be --domain ADTEST --uid 0 --gid 0
--logger=files'.
Program terminated with signal 11, Segmentation fault.
#0 sysdb_attrs_get_el_ext (attrs=attrs@entry=0x0, name=name@entry=0x7f51214c457a
"trustPartner", alloc=alloc@entry=false, el=el@entry=0x7ffc9ce95ad0) at
src/db/sysdb.c:289
289 for (i = 0; i < attrs->num; i++) {
(gdb) p attrs
$1 = (struct sysdb_attrs *) 0x0
(gdb)
```
```
(gdb) bt full
#0 sysdb_attrs_get_el_ext (attrs=attrs@entry=0x0, name=name@entry=0x7f51214c457a
"trustPartner", alloc=alloc@entry=false, el=el@entry=0x7ffc9ce95ad0) at
src/db/sysdb.c:289
e = 0x0
i = 0
#1 0x00007f5131770c42 in sysdb_attrs_get_string (attrs=attrs@entry=0x0,
name=name@entry=0x7f51214c457a "trustPartner",
string=string@entry=0x7ffc9ce95af0) at src/db/sysdb.c:332
el = 0x55ce69e12750
ret = <optimized out>
#2 0x00007f51214b58ea in ads_get_root_domain (attrs=attrs@entry=0x0, be_ctx=<optimized
out>) at src/providers/ad/ad_subdomains.c:67
dom = <optimized out>
name = 0x55ce69e12530 " \002zi\316U"
ret = <optimized out>
#3 0x00007f51214b5b6f in ads_get_root_sdap_domain (attrs=0x0, opts=0x55ce69dfcc70,
be_ctx=<optimized out>) at src/providers/ad/ad_subdomains.c:100
root_sdom = <optimized out>
root_dom = <optimized out>
#4 ad_get_slave_domain_send (root_id_ctx=0x55ce69dfe300, root_id_ctx=0x55ce69dfe300,
root_attrs=0x0, sd_ctx=<optimized out>, ev=0x55ce69db5c50, mem_ctx=<optimized
out>)
at src/providers/ad/ad_subdomains.c:847
state = 0x55ce69e32ea0
ret = <optimized out>
req = 0x55ce69e32d10
#5 ad_subdomains_refresh_root_done (subreq=0x0) at
src/providers/ad/ad_subdomains.c:1480
state = <optimized out>
req = 0x55ce69e12530
root_id_ctx = 0x55ce69dfe300
root_attrs = 0x0
dp_error = 0
ret = <optimized out>
__FUNCTION__ = "ad_subdomains_refresh_root_done"
#6 0x00007f512da18a6a in tevent_common_loop_immediate (ev=ev@entry=0x55ce69db5c50) at
../tevent_immediate.c:135
im = 0x55ce69e32df0
handler = 0x7f512da192b0 <tevent_req_trigger>
private_data = 0x55ce69e32d10
#7 0x00007f512da1dc9d in epoll_event_loop_once (ev=0x55ce69db5c50, location=<optimized
out>) at ../tevent_epoll.c:911
epoll_ev = 0x55ce69db5ed0
tval = {tv_sec = 0, tv_usec = 0}
panic_triggered = false
#8 0x00007f512da1c2a7 in std_event_loop_once (ev=0x55ce69db5c50, location=0x7f51317c9887
"src/util/server.c:721") at ../tevent_standard.c:114
glue_ptr = <optimized out>
glue = 0x55ce69db5d80
ret = <optimized out>
#9 0x00007f512da1807d in _tevent_loop_once (ev=ev@entry=0x55ce69db5c50,
location=location@entry=0x7f51317c9887 "src/util/server.c:721") at
../tevent.c:726
ret = <optimized out>
nesting_stack_ptr = 0x0
#10 0x00007f512da182ab in tevent_common_loop_wait (ev=0x55ce69db5c50,
location=0x7f51317c9887 "src/util/server.c:721") at ../tevent.c:849
ret = <optimized out>
#11 0x00007f512da1c247 in std_event_loop_wait (ev=0x55ce69db5c50, location=0x7f51317c9887
"src/util/server.c:721") at ../tevent_standard.c:145
glue_ptr = <optimized out>
glue = 0x55ce69db5d80
ret = <optimized out>
#12 0x00007f51317a6843 in server_loop (main_ctx=0x55ce69db70e0) at src/util/server.c:721
```
Sorry for late testing.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-363499596
11:27 a.m.
New subject: [sssd PR#475][+Changes requested] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
Label: +Changes requested
2:38 p.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
jhrozek commented:
"""
Is there any way you could send me more details how to reproduce the error? It is enough
to send me a link to a downstream test if that's how you reproduced the crash..
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-363557442
3:44 p.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
jhrozek commented:
"""
Nevermind, I can reproduce that locally. Thank you for catching the bug.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-363574781
10:07 a.m.
New subject: [sssd PR#475][synchronized] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: AD: Use the right sdap_domain for the forest root
Action: synchronized
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/475/head:pr475
git checkout pr475
10:07 a.m.
New subject: [sssd PR#475][-Changes requested] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
Label: -Changes requested
10:08 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
jhrozek commented:
"""
Thanks for reporting the issue. I must have tested only with a client joined to a child
domain, because the crash was happening simply because the root domain attributes are
expected to be NULL and in that case we can just just `be_ctx->dom` as the domain.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-363819017
8:55 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
lslebodn commented:
"""
And I can see the same issue as in the beginning. I do not remember whether the crash is
the same.
I'm checking one more time and I'll provide you an access to problematic env.
```
(gdb) bt
#0 sdap_search_bases_ex_next_base (req=req@entry=0x55bb8d569310) at
src/providers/ldap/sdap_ops.c:145
#1 0x00007f15d6856812 in sdap_search_bases_ex_done (subreq=0x0) at
src/providers/ldap/sdap_ops.c:220
#2 0x00007f15d6825879 in generic_ext_search_handler (subreq=0x0, opts=<optimized
out>) at src/providers/ldap/sdap_async.c:1689
#3 0x00007f15d6827c14 in sdap_get_generic_op_finished (op=<optimized out>,
reply=<optimized out>, error=<optimized out>, pvt=<optimized out>) at
src/providers/ldap/sdap_async.c:1579
#4 0x00007f15d68268cd in sdap_process_message (ev=<optimized out>, sh=<optimized
out>, msg=0x55bb8d55c690) at src/providers/ldap/sdap_async.c:353
#5 sdap_process_result (ev=<optimized out>, pvt=<optimized out>) at
src/providers/ldap/sdap_async.c:197
#6 0x00007f15e40c5c97 in tevent_common_loop_timer_delay (ev=ev@entry=0x55bb8d4bdcc0) at
../tevent_timed.c:369
#7 0x00007f15e40c6ca9 in epoll_event_loop_once (ev=0x55bb8d4bdcc0, location=<optimized
out>) at ../tevent_epoll.c:915
#8 0x00007f15e40c52a7 in std_event_loop_once (ev=0x55bb8d4bdcc0, location=0x7f15e7e72887
"src/util/server.c:721") at ../tevent_standard.c:114
#9 0x00007f15e40c107d in _tevent_loop_once (ev=ev@entry=0x55bb8d4bdcc0,
location=location@entry=0x7f15e7e72887 "src/util/server.c:721") at
../tevent.c:726
#10 0x00007f15e40c12ab in tevent_common_loop_wait (ev=0x55bb8d4bdcc0,
location=0x7f15e7e72887 "src/util/server.c:721") at ../tevent.c:849
#11 0x00007f15e40c5247 in std_event_loop_wait (ev=0x55bb8d4bdcc0, location=0x7f15e7e72887
"src/util/server.c:721") at ../tevent_standard.c:145
#12 0x00007f15e7e4f853 in server_loop (main_ctx=0x55bb8d4bf150) at src/util/server.c:721
#13 0x000055bb8ba665d9 in main (argc=8, argv=<optimized out>) at
src/providers/data_provider_be.c:639
(gdb) l 145
140 if (state->cur_base == NULL) {
141 return EOK;
142 }
143
144 /* Combine lookup and search base filters. */
145 filter = sdap_combine_filters(state, state->filter,
146 state->cur_base->filter);
147 if (filter == NULL) {
148 return ENOMEM;
149 }
(gdb) p state[0]
$4 = {ev = 0x55bb8d4bdcc0, opts = 0x55bb8d526470, sh = 0x55bb8d542080, filter =
0x7f15d7ace2e0 "%s\n", attrs = 0x7ffd62628970, map = 0x0, map_num_attrs = 0,
timeout = 6,
allow_paging = false, return_first_reply = false, base_iter = 1, cur_base =
0xbebebebebebebebe, bases = 0x55bb8d52bab0, reply_count = 0, reply = 0x0}
```
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-364946282
9:04 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
jhrozek commented:
"""
yes, please, send me some environment details
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-364949215
9:05 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
lslebodn commented:
"""
I ran tests twice in clean environment and it is fixed.
I had to mix something up yesterday.
ACK
Thank you very much for fixing this regression and sorry for long interval between
reviews.
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-365293899
9:05 a.m.
New subject: [sssd PR#475][+Accepted] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
Label: +Accepted
9:06 a.m.
New subject: [sssd PR#475][closed] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Author: jhrozek
Title: #475: AD: Use the right sdap_domain for the forest root
Action: closed
To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/475/head:pr475
git checkout pr475
9:06 a.m.
New subject: [sssd PR#475][comment] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
lslebodn commented:
"""
master:
* 9ac071272ce0152eb293d3181a5c12b395655521
"""
See the full comment at https://github.com/SSSD/sssd/pull/475#issuecomment-365294269
9:06 a.m.
New subject: [sssd PR#475][+Pushed] AD: Use the right sdap_domain for the forest root
URL: https://github.com/SSSD/sssd/pull/475
Title: #475: AD: Use the right sdap_domain for the forest root
Label: +Pushed
2262
days inactive
2324
days old
sssd-devel@lists.fedorahosted.org
32 comments
3 participants
participants (3)
-
jhrozek -
lslebodn
-
sumit-bose