[SSSD] Design Discussion: D-Bus responder
Jakub Hrozek
jhrozek at redhat.com
Fri Apr 18 15:09:04 UTC 2014
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.
> Added: Representing SSSD configuration
* '''property''' Uint32 debug_level
* The name of this service.
This ^^^^ sounds like a typo.
* '''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.
> 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.
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?
What is the exact semantics of Enable and Disable? (see my other
question about the enabled property below).
> 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? 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'.
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.
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.
> 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.
Please use 'Array' instead of 'List', we should stick to the DBus
nomenclature.
Thanks for the changes!
More information about the sssd-devel
mailing list