On Mon, Mar 25, 2013 at 02:48:44PM +0100, Pavel Březina wrote:
On 03/22/2013 10:59 PM, Lukas Slebodnik wrote:
>On (21/03/13 16:10), Pavel Březina wrote:
>>On 03/21/2013 03:43 PM, Lukas Slebodnik wrote:
>>>On (22/02/13 13:46), Pavel Brezina wrote:
>>>>----- Original Message -----
>>>>>From: "Pavel Březina" <pbrezina(a)redhat.com>
>>>>>To: sssd-devel(a)lists.fedorahosted.org
>>>>>Sent: Thursday, February 21, 2013 11:43:26 AM
>>>>>Subject: [SSSD] [PATCH] refactor nested group processing
>>>>>
>>>>>https://fedorahosted.org/sssd/ticket/1784
>>>>
>>>>I should have probably add that this is the final version. I will attach
unit test once I get familiar with cmocka, but it does not really prevent reviewing the
patch.
>>>
>>>I would like to test your patches, but the second patch no longer applies
>>>on the current master. Could you resend rebased patches?
>>
>>Thanks. Rebased patches are attached. I did not test it again though,
>>but it compiles fine and the diff looks all right. It may be
>>interesting to determine what patch broke it.
>>
>
>I had problems with you patches.
>The simplest cycle schema:
> ________
> | CG1 |------------>sssduser1
> |______|<---|
> | |
> | |
> | ________
> |---->| CG2 |--->sssduser2
> |______|
>
>sssd client configured with ipa-client-install and two additional options
>entry_cache_timeout = 5
>memcache_timeout = 1
>
>How to reproduce.
>1. remove cache(also logs, but it is not important)
>2. service sssd start
>3. run commands
>
>sh-4.2$ getent group cyclegroup1
>cyclegroup1:*:30007:sssduser1,sssduser2
>sh-4.2$ getent group cyclegroup2
>cyclegroup2:*:30008:sssduser2
> #after second (memcache_timeout)
>sh-4.2$ getent group cyclegroup2
>cyclegroup2:*:30008:sssduser2,sssduser1
>
>-----------------------------
>
>Also sometimes with the same groups scheme one user appeared two times,
>but I could not exactly reproduce steps.
The problem is even in master. Seems to be another ghost users issue.
I agree, the EEXIST error is coming from memberof plugin:
https://fedorahosted.org/sssd/ticket/1846
>
>If you could not reproduce problem, I could send you off the list
>logs, cache, any configurations, rpms or even provide access to IPA server.
>
>And last notice, commit 4709ff46db0dbe073aef061b796d2fd7adeaf18f
>with title "LDAP: If deref search fails, try again without deref"
>cause little problem with applying patches.
>
>LS
I amended my patches to keep the functionality introduced in this
commit. I.e. if deref fails with ENOTSUP, we will try again without
dereference.