[SSSD] LDAP connection tracking, sharing and fail-over retry framework

Eugene Indenbom eindenbom at gmail.com
Wed Jul 7 12:59:26 UTC 2010


On 07/07/2010 04:43 PM, Stephen Gallagher wrote:
>> Sounds good. I just want a confirmation that it is in line with tevent
>> coding style to pass pointer to higher level state (hbac_ctx) into
>> sub-operations (hbac_get_host_info_send() and others).
>>      
> It's fine to percolate it down where necessary, provided that the
> functions it's going into must ALWAYS be a descendent. (E.g. it's okay
> to pass it into helper requests, but passing it into sdap_generic_send()
> would be a mistake)
>
>    
I will do it this way.
>
> <...>
>>    From my point of view we should go even further and not to store
>> intermediate stage results to sysdb until all data is received from LDAP
>> server. Otherwise we could use inconsistent data in OFFLINE mode.
>>      
> Can you point me at a case where we're saving data before the LDAP
> server is complete? That sounds like a bug. I agree that we shouldn't be
> writing the ldb_transaction until we have everything.
>
>    
We do wait for end of each LDAP request, but in case of multi-stage 
request like LDAP users/groups enumeration and IPA HBAC we save each 
stage results separately. For example in HBAC we save hosts, than ask 
for rules, save rules, than ask for services and save services. It might 
make sense to get hosts, rules and services and than save them altogether.
>> Another reason to have sdap_id_op as separate tear is caching strategy:
>> it would ineffective if LDAP connection was dropped in the middle of
>> multi-stage operation, that could be the case if connection usage
>> tracking is done within sdap_generic_send. Using higher level tear
>> ensures that connection is available through complete operation, not
>> just within single stage.
>>      
> Yeah, I think I agree with you here.
>
>    




More information about the sssd-devel mailing list