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.
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..)
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.