[SSSD] SSSD CIM schema for OpenLMi

Pavel Březina pbrezina at redhat.com
Fri Apr 25 14:33:13 UTC 2014


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 at 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

>
>>
>>> Admin does not care about responders or providers.
>>
>> Admins should now what they are doing. Therefore they should care. But
>> its just about bi-terminology. I had to use responders instead of
>> services, because there is already LMI_SSSDService class (by
>> convention) representing the daemon.
>>
>>> Admin cares about the fact that machine is enrolled with a particular
>>> domains.
>>
>> For domain enrolment there is a realmd provider.
>
> Only for the first one.
>
>>
>>  Tweaking low level concepts would be out of scope of the
>>> initial effort.
>>>
>>> Would have been nice to see the object diagram and discuss it in
>>> advance.
>>
>> UML diagram is attached. I need to figure a way how to model
>> associations though.
>
> Thanks! Is there a design page on the wiki or at least going to be?
>
>>
>>>
>>>
>>> --
>>> Thank you,
>>> Dmitri Pal
>>>
>>> Sr. Engineering Manager IdM portfolio
>>> Red Hat, Inc.





More information about the sssd-devel mailing list