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.