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

Jakub Hrozek jhrozek at redhat.com
Mon Feb 17 14:41:42 UTC 2014


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.

In general, I think it would be neccessary to limit this helper library
just to the very basic tasks (retrieving attributes) and suggest to use
the full DBus for anything more complex. Otherwise we risk supporting
two competing full interfaces which is something I'd like to avoid.

> 
> >>Jakub, can you send the D-Bus responder to the list? It would be
> >>nice to include it in master as an experimental feature and create
> >>tickets for further work so we can work on it simultaneously.
> >
> >I can send some of the patches that are already stable, but quite some
> >code in my branch still needs work before it can be accepted upstream.
> >The backend part is completely done as well as the general plumbing
> >around the responder. But the dbus code itself is still going through
> >some changes.
> >
> >Do you need to depend on the code, though? I would suggest to only
> >depend on the interface the code exports which won't change anymore.
> 
> Domains (sort-of implemented), services (not included in original
> design) are just a start. Those four methods from the CIM model are
> only for the first stage, as a proof of concept. I will want more
> control over each service, domain and monitor later, thus I will
> need to extend the current interface with more methods and objects.
> 
> So my point is to get the code more or less stable as soon as
> possible so I can contribute without the risk of rebasing too often.

Right, some parts of the work can already be upstreamed as-is, but the
dbus internals would still be undergoing some changes. But this
shouldn't matter as long as you depend on the interface and not the
implementation, which is the right thing to do anyway.

I would suggest to start by proposing the API on the wiki.

Also, did you already start thinking about how to implement starting the
new service in the sssd itself? It would be nice to file tickets for
these subtasks so that we know how much of the work is done and how much
is missing.



More information about the sssd-devel mailing list