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

Sumit Bose sbose at redhat.com
Mon Feb 17 17:40:44 UTC 2014


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.

bye,
Sumit
> 
> 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.
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list