On 04/25/2014 06:23 PM, Dmitri Pal wrote:
On 04/25/2014 10:33 AM, Pavel Březina wrote:
On 04/25/2014 04:19 PM, Dmitri Pal wrote:
On 04/25/2014 10:05 AM, Pavel Březina wrote:
On 04/25/2014 03:17 PM, Dmitri Pal wrote:
On 04/25/2014 08:18 AM, Pavel Březina wrote:
Hi,
attached is a CIM schema for SSSD provider. This schema was acked by
OpenLMI developers.
The first version of OpenLMI provider will provider methods to
enable/disable SSSD components and basic information about domains.
I hope I don't have to explain the MOF language to developers so I
will just say that association classes models relationships between
other entities. Feel free to ask me anything if needed.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
If I get it right the CIMOM is pretty config file centric. I mean that
it tries to create model around the config file and expose its
concepts.
I do not think this is the right level of abstraction - it is very
developer centric.
What I had in mind is a more high level abstraction:
From what I have been told, WBEM works a lot differently, than a
developer experienced in OOP would expect. I have struggled with it
first, but this is the correct level of abstraction.
WBEM unfortunately is not a technology to be used without a lot of
knowledge. It took me a while to understand it and learn its concepts,
they differ from what we are used to.
* List domains
Listing domains is done by LMI_SSSDDomain.instances() call. Or to get
for example only domains present in configuration (not subdomains),
you will use proper association.
OK
* For each domain get info, or set info.The get will return the
details
about the domain.
This is done by properties. It is present in the schema.
I saw that
The set will allow to set the type of the domain: AD,
IPA, LDAP, LDAP+Kerberos using defaults as much as possible.
Thesis goal was to implement only enabling/disabling domains and
responders so this is not present in the schema. I will do it if I
have some spare time or for the next version.
File a ticket once you work lands
Set would
also allow turning debugging and enumeration on and off.
This is present in the schema, although not by property set, because
it requires an SSSD restart and it is important to highlight it in
this case IMHO. That's why it is present as a method, instead of
setting a property.
OK, good to know
* One of the biggest values would be to add secondary domains
What do you mean by secondary domain? If subdomains, they are there.
The other domain other than the one that was initially set by
ipa-client-install or realmd.
There is currently no non manual way to do it AFAIK.
* Another important aspect is turning on and off the sudo, ssh,
automount and SELinux integration.
Present.
Good
Right now the model seems to be low level and sort of goes from ground
up. I would argue that model should expose high level concepts and
operations and then be extended to more fine grained operations and
object as we need them.
CIM schema should not model of high level concepts. It is a
representations of managed elements. Not a high level abstraction
above them. I've tried to go this way first, it was immediately nacked
by OpenLMI devs and they pushed me to learn WBEM concepts more
thoroughly.
I would disagree with that but not argue ;-)
The high level concept is then created by so called LMI scripts, that
allows you to perform non-trivial CIM queries from one command from
command line.
For example:
$ lmi sssd-domains list
$ lmi sssd-domains enable example.com
Sounds right, if possible this is exactly what I am looking for.
Hi,
I created a design page that describes the SSSD interface for this.
https://fedorahosted.org/sssd/wiki/DesignDocs/OpenLMIProvider#LMIscriptsdesign
Comments are welcomed.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
