[SSSD] Discussion: OpenLMI provider + D-Bus responder

Stef Walter stefw at redhat.com
Mon Feb 24 11:19:20 UTC 2014


On 17.02.2014 18:40, Sumit Bose wrote:
> On Mon, Feb 17, 2014 at 03:41:42PM +0100, Jakub Hrozek wrote:
>> On Fri, Feb 14, 2014 at 11:00:08AM +0100, Pavel Březina wrote:
>>> On 02/13/2014 06:38 PM, Jakub Hrozek wrote:
>>>> On Thu, Feb 13, 2014 at 02:14:01PM +0100, Pavel Březina wrote:
>>>>> Hi folks,
>>>>> for the first iteration of SSSD provider for OpenLMI I have created
>>>>> a very simple model, that handles the most fundamental parts of
>>>>> SSSD: domains and services (responders) - listing, activation and
>>>>> deactivation.
>>>>>
>>>>> MOF class for this model is attached. It still lacks some annotation
>>>>> and description but I think it is pretty much straightforward and
>>>>> doesn't need any more explanation for developers.
>>>>>
>>>>> The model contains four kinds of methods:
>>>>> - get all supported (configured) services (domains)
>>>>> - get active services (domains)
>>>>> - enable service (domain)
>>>>> - disable service (domain)
>>>>
>>>> On the side of the DBus API, are you envisioning an enable() method for
>>>> the domains and also exposing the services? I'm fine with that in
>>>> general, I would just like to double check this with our friendly DBus
>>>> experts.
>>>
>>> Yes, that's exactly what I'm envisioning.
>>>
>>>>> I've chosen this approach so we don't have to amend the model with
>>>>> each new responder. So instead of EnableNSSService(), users will use
>>>>> EnableService('nss').
>>>>>
>>>>> Restart of SSSD deamon shall be handled by standard service
>>>>> provider, so we don't have to deal with it - we just let users know
>>>>> that some changes requires restarting. However, I'm inclined to
>>>>> create a method under SSSD object (LMI_SSSD::Restart) to make the
>>>>> interface more complete in later stage.
>>>>>
>>>>> Now I'm looking for a way how the LMI provider will communicate with
>>>>> SSSD. I've been playing with Jakub's D-Bus responder for a while and
>>>>> it seems like a good way to go. We can expose everything we need
>>>>> over D-Bus with proper access control and it all stays under SSSD
>>>>> control, having LMI provider only as a simple client.
>>>>>
>>>>> I would like to create a client wrapper over provided D-Bus
>>>>> interface (say libsss_dbus), that will provide simple synchronous
>>>>> interface to query D-Bus, encapsulating most of the D-Bus
>>>>> complexity. I have prepared a proof of concept for this library,
>>>>> using both libdbus and recommended libdbus-glib. It encapsulates
>>>>> ListDomains and property Get D-Bus method. You can see both versions
>>>>> here:
>>>>>
>>>>> - libdbus:
>>>>> http://fedorapeople.org/cgit/pbrezina/public_git/sssd_gdbus.git/tree/src/main.c?h=dbus
>>>>>
>>>>> - libdbus-glib:
>>>>> http://fedorapeople.org/cgit/pbrezina/public_git/sssd_gdbus.git/tree/src/main.c?h=gdbus
>>>>>
>>>>> Probably the biggest advantage of libdbus-glib is the simplicity of
>>>>> work with variants and dictionaries. However, I think it is quite an
>>>>> overkill for our needs. I'm more inclined to use libdbus and write
>>>>> an automatized parser for those data types, it won't be hard.
>>>>>
>>>>> What do you say? Should I go this way?
>>>>
>>>> I think yes, actually we spoke with Sumit earlier today about exactly
>>>> the same thing, except we initially talked about extending the existing
>>>> libnss_sss_idmap library that provides the sid-to-name-mappings and
>>>> perhaps talking to the NSS responder for some of the data.
>>>>
>>>> But I'm not sure I like wrapping the whole DBus interface in a library,
>>>> that seems like a big effort to me (an API around an API..)
>>>
>>> Well, that's how the world works all the time - you create a
>>> powerful low-level API and then hide its complexity in less powerful
>>> high-level API. I certainly don't want to wrap the whole future
>>> interface, just the most important things (from my point of you it
>>> will be things that I'll use in LMI provider, to leave it as simple
>>> as possible).
>>
>> Could you please sync with Sumit on this API? I don't think I would be
>> able to contribute in the nearest future, but since Sumit also wanted
>> this functionality, it would be helpful if you and him collaborated
>> rather than worked on the same thing.
> 
> What I'm looking for is a call which takes user name, domain name and a
> list of attributes names as input and returns a list of key-value pair.
> I think this is still quite simple and should cover almost every
> use-case for the cache user objects.
> 
> I like libdbus better because it adds less requirement to the project
> using it and I think projects which are already using glib might
> consider using D-Bus directly with the glib interfaces.

I agree here. Modern GLib projects will use gdbus-codegen to generate a
suitable thin wrapper.

IMO, the big deficiency of libdbus is converting messages/iterators to C
types. And a theoretical libsss_dbus client library should limit itself
to fixing that part.

I would suggest this library be incubated inside of the first consumer
(ie: right now the LMI provider) until a second consumer shows up, at
which point it'd need refactoring anyway.

Cheers,

Stef




More information about the sssd-devel mailing list