On 08/12/2016 03:36 PM, Jakub Hrozek wrote:
> On Fri, Aug 12, 2016 at 02:51:21PM +0200, Petr Cech wrote:
>> On 08/12/2016 11:27 AM, Jakub Hrozek wrote:
>>> On Wed, Aug 10, 2016 at 08:54:25AM +0200, Petr Cech wrote:
>>>> Sorry, I experienced some issue with mailing list.
>>>> So I send it again.
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: Re: [SSSD] Re: [PATCH SET] AD_PROVIDER: ad_enabled_domains
>>>> Date: Tue, 9 Aug 2016 17:29:38 +0200
>>>> From: Petr Cech <pcech(a)redhat.com>
>>>> To: sssd-devel(a)lists.fedorahosted.org
>>>>
>>>> On 08/09/2016 11:07 AM, Jakub Hrozek wrote:
>>>>> On Mon, Jul 25, 2016 at 06:18:28PM +0200, Petr Cech wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> there is fixed patch set attached.
>>>>>>>
>>>>>>> Segmentation fault was caused by wrong pointer :-(, sorry.
>>>>>>>
>>>>>>> This new patch set has new debug message. I am open to
dissccus the
>>>>>>> debug_level and content of message. Any improving idea?
>>>>>>>
>>>>>>> I hit one issue during testing -- sometimes if I am connected
to
>>>>>>> subdomain
>>>>>>> and I enable only sibling subdomain (the master is added
>>>>>>> automaticaly) and
>>>>>>> forest root is not enabled -- I see only master and sibling
not.
>>>>>>> But if I
>>>>>>> added sleep for cycle (for using dbg) to function
>>>>>>> ad_subdomains_init()
>>>>>>> everythink is OK.
>>>>>>> Any idea?
>>>>> Can you test that case with valgrind? This sounds like some
>>>>> uninitilized
>>>>> variable condition.
>>>>
>>>>
>>>> I didn't run valgrind but I have new information.
>>>>
>>>> If you clear the cache and reset sssd, first attempt to obtain
>>>> information
>>>> about user from sibling domain fails. The second and the other
>>>> attempts runs
>>>> correctly.
>>>>
>>>> I see that the sibling domain is enabled. But if I look more
>>>> carefully there
>>>> is message in log (gamma.domain.bootes is sibling domain):
>>>>
>>>> [sssd[be[beta.domain.bootes]]] [dp_req_new] (0x0020): Unknown domain:
>>>> gamma.domain.bootes
>>>>
>>>> First attempt should works too but you should wait nearly exactly 6
>>>> seconds
>>>> after restart sssd.
>>>>
>>>> New patch set is attached.
>>>
>>> I can't start SSSD with these patches:
>>> (Fri Aug 12 11:25:38 2016) [sssd[be[win.trust.test]]]
>>> [dp_target_run_constructor] (0x0010): Target [subdomains]
>>> constructor failed [22]: Invalid argument
>>> (Fri Aug 12 11:25:38 2016) [sssd[be[win.trust.test]]]
>>> [dp_load_targets] (0x0020): Unable to load target [subdomains] [22]:
>>> Invalid argument.
>>> (Fri Aug 12 11:25:38 2016) [sssd[be[win.trust.test]]] [dp_init]
>>> (0x0020): Unable to initialize DP targets [1432158209]: Internal Error
>>> (Fri Aug 12 11:25:38 2016) [sssd[be[win.trust.test]]]
>>> [dp_terminate_active_requests] (0x0400): Terminating active data
>>> provider requests
>>>
>>> I have:
>>> $ git log --oneline origin/master..HEAD
>>> 3b2f910 TESTS: Adding tests for ad_enabled_domains option
>>> 7ac9517 AD_PROVIDER: ad_enabled_domains - other then master
>>> fdbbd30 AD_PROVIDER: ad_enabled_domains - only master
>>> ebaa14d AD_PROVIDER: Initializing of ad_enabled_domains
>>> 38989af AD_PROVIDER: Add ad_enabled_domains option
>>>
>>> $ git rev-list origin/master..HEAD
>>> 3b2f9106c2c5bea1681cf1f752fc5f3256a04300
>>> 7ac9517f78dc4dcde4c4c613ec450a3f3fc8f644
>>> fdbbd30adf9da7a3c2510029c2e8c3789a3083a0
>>> ebaa14dd1dd0e4f55a2bc4e647ce848e36970dd2
>>> 38989afa14bfc89712808867b80e667d34e068b3
>>
>> Hello Jakub,
>>
>> I wasn't able to reproduce your bug. Is it true that I use F23 for
>> testing
>> this patch for historical reasons. I should try it with F24 too.
>>
>> I sent whole patch set to CI,
>>
http://sssd-ci.duckdns.org/logs/job/51/45/summary.html
>> but I think it is not conclusive because out tests don't contain AD
>> server.
>>
>> I will look at it again. But now I would like finish tests for
>> netgroups.
>
> I don't think it has to do with Fedora version. Maybe my sssd.conf would
> help:
>
> [domain/win.trust.test]
> ad_domain = win.trust.test
> krb5_realm = WIN.TRUST.TEST
> realmd_tags = manages-system joined-with-adcli
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = True
> use_fully_qualified_names = True
> fallback_homedir = /home/%u@%d
> ad_enable_gc = false
> debug_level = 10
>
> access_provider = simple
>
> #ad_enabled_domains = win.trust.test, siblingdom.win.trust.test
> #debug_level = 7
>
> dyndns_update = false
Thanks,
I see now where's the problem. I didn't try to comment
ad_enabled_domains in config for long time. If this option missing it
will crash.
[dp_target_run_constructor] (0x0010): Target [subdomains] constructor
failed [22]: Invalid argument
I hope it will be easy to fix it.
Hello,
I fixed little bug (wrong return code for missing option)
in ad_get_enabled_domains().
New patch set is attached.
There is still one strange behaviour:
If you clear the cache and reset sssd, first attempt to obtain
information about user from sibling domain fails. The second and the
other attempts runs correctly.
I see that the sibling domain is enabled. But if I look more
carefully there is message in log (gamma.domain.bootes is sibling
domain):
[sssd[be[beta.domain.bootes]]] [dp_req_new] (0x0020): Unknown domain:
gamma.domain.bootes
First attempt should works too but you should wait nearly exactly 6
seconds after restart sssd.
I think it is connected to mechanism which obtain information about
domains. Is it right?
Regards
--
Petr^4 Čech