[SSSD] Design Discussion: D-Bus responder

Pavel Březina pbrezina at redhat.com
Thu Apr 24 08:38:33 UTC 2014


On 04/18/2014 05:37 PM, Pavel Březina wrote:
> On 04/18/2014 05:09 PM, Jakub Hrozek wrote:
>> On Fri, Apr 18, 2014 at 04:32:40PM +0200, Pavel Březina wrote:
>>> On 02/24/2014 12:32 PM, Pavel Březina wrote:
>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder
>>>
>>> Hi,
>>> I made some changes to the design, that I find helpful in my thesis.
>>> Namely:
>>>
>>
>> === Representing users on the bus ===
>>      * '''object path''': /org/freedesktop/sssd/infopipe/Users/$user
>>
>> $user should probably be $UID, likewise for $group, the identifier
>> should be $GID.
>
> $user still may refer to id, I just wanted to put the object paths into
> design. But I renamed it for better clarification.
>
>>> Added: Representing SSSD configuration
>>
>> * '''property''' Uint32 debug_level
>>      * The name of this service.
>>
>> This ^^^^ sounds like a typo.
>
> Fixed.
>
>> * '''property''' String default_domain_suffix
>>      * The default domain suffix
>>
>> I don't think the default_domain_suffix is strictly needed, hardly
>> anyone is using it (and I think we should discourage using it). But I'm
>> not too much against publishing this property on the bus, eventually, we
>> should publish them all (or most) anyway.
>
> OK. I think we can drop that for now.
>
>>> Added: Representing SSSD processes on the bus
>>
>> === Representing SSSD processes on the bus ===
>>      This API should provide methods for basic operations with SSSD
>> processes.
>>           ^^^
>>        I think you should explicitly say "Interface" here to make it
>>        clear what DBus concept you're talking about.
>
> Done.
>
>> I think 'Component' is a good generalization of both responder and
>> provider.
>>
>> Why is there no return code, for Enable and Disable though? Is there
>> nothing that can fail? I agree that enabling already enabled service
>> (same for disabled) should be a noop, but can there be some internal
>> error?
>
> Error should be expressed via D-Bus error system, not with an output
> parameter. Thus no return value is needed.
>
>> What is the exact semantics of Enable and Disable? (see my other
>> question about the enabled property below).
>
> Modify either "services" or "domains" lists.
>
>>> Added: Representing service objects on the bus
>>
>> I'm not sure about the 'enabled' boolean. How would you express a
>> disabled service in sssd.conf? By having a section but not including the
>> service in the 'services' list?
>
> Yes. For domains respectively.
>
> Note that we're planning on moving away
>> from that model to one where any service and domain that would have a
>> section would automatically be 'enabled'.
>
> That we will need to change the code when this is done.
>
>> When I started reading the document, I thought of 'enabling' a service
>> as both creating the section and including the service name in the
>> 'services' list. Then, when we obsolete the 'services' list, enabling a
>> service would be the same as just creating the section.
>
> At the moment you don't need to have the section created to enable the
> service, so it should just temper with the services list.
>
> Just creating a section will not suffice, because you would need to
> delete the section to disable it will all set options. But that's
> another discussion. I need it to work with current SSSD. We will deal
> with new concept when it is current.
>
>> How do you plan on dealing with options that are specific to a single
>> service
>> (ie PAM-specific options) ? Would there simply be another
>> responder-specific
>> property? I would be OK with that, I'm just trying to assess the plan.
>
> Yes, responder specific properties sounds doable to me.
>
>>> Added new properties: Representing domain objects on the bus
>>
>> I think we should add id_provider, auth_provider, access_provider etc to
>> the list of default properties.
>
> Yes. I'm thinking of array of key=value pairs so you don't have to amend
> the properties for every new provider. What do you think?
>
>> Please use 'Array' instead of 'List', we should stick to the DBus
>> nomenclature.
>
> Done.

Hi,
I made some more changes, please review.

https://fedorahosted.org/sssd/wiki/DesignDocs/DBusResponder

The way I see SSSD terminology:
responder is a process providing particular service
backend is a process managing one or more domains

We were combining abilities (debug level, enabled/disabled) of sssd 
processes (responders, backends) with logical units (services, domains). 
I think this wasn't very clear approach. There was at least one big 
problem, that I struggled with:

Only root SSSD domain have these properties, they don't apply to 
subdomains. We could either split subdomains to separate object type or 
inherit this property from parent domain. But I found it very confusing 
when you start changing this properties.

I defined a separate objects under infopipe/Components tree that 
implements infopipe.Components interface. This way it is completely 
separated from services and domains, which can focuses purely on their 
properties and methods.




More information about the sssd-devel mailing list