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/...
>>>>
>>>> - libdbus-glib:
>>>>
http://fedorapeople.org/cgit/pbrezina/public_git/sssd_gdbus.git/tree/src/...
>>>>
>>>> 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