<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 04/25/2014 10:05 AM, Pavel Březina
      wrote:<br>
    </div>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">On
      04/25/2014 03:17 PM, Dmitri Pal wrote:
      <br>
      <blockquote type="cite">On 04/25/2014 08:18 AM, Pavel Březina
        wrote:
        <br>
        <blockquote type="cite">Hi,
          <br>
          attached is a CIM schema for SSSD provider. This schema was
          acked by
          <br>
          OpenLMI developers.
          <br>
          <br>
          The first version of OpenLMI provider will provider methods to
          <br>
          enable/disable SSSD components and basic information about
          domains.
          <br>
          <br>
          I hope I don't have to explain the MOF language to developers
          so I
          <br>
          will just say that association classes models relationships
          between
          <br>
          other entities. Feel free to ask me anything if needed.
          <br>
          <br>
          <br>
          <br>
          _______________________________________________
          <br>
          sssd-devel mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
          <br>
          <a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
          <br>
        </blockquote>
        <br>
        If I get it right the CIMOM is pretty config file centric. I
        mean that
        <br>
        it tries to create model around the config file and expose its
        concepts.
        <br>
        I do not think this is the right level of abstraction - it is
        very
        <br>
        developer centric.
        <br>
        What I had in mind is a more high level abstraction:
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      <blockquote type="cite">* List domains
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    OK<br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      <blockquote type="cite">* For each domain get info, or set
        info.The get will return the details
        <br>
        about the domain.
        <br>
      </blockquote>
      <br>
      This is done by properties. It is present in the schema.
      <br>
    </blockquote>
    <br>
    I saw that<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      The set will allow to set the type of the domain: AD,
      <br>
      <blockquote type="cite">IPA, LDAP, LDAP+Kerberos using defaults as
        much as possible.
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    File a ticket once you work lands<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      Set would
      <br>
      <blockquote type="cite">also allow turning debugging and
        enumeration on and off.
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    OK, good to know<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      <blockquote type="cite">* One of the biggest values would be to
        add secondary domains
        <br>
      </blockquote>
      <br>
      What do you mean by secondary domain? If subdomains, they are
      there.
      <br>
    </blockquote>
    <br>
    The other domain other than the one that was initially set by
    ipa-client-install or realmd.<br>
    There is currently no non manual way to do it AFAIK.<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      <blockquote type="cite">* Another important aspect is turning on
        and off the sudo, ssh,
        <br>
        automount and SELinux integration.
        <br>
      </blockquote>
      <br>
      Present.
      <br>
    </blockquote>
    <br>
    Good<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      <blockquote type="cite">Right now the model seems to be low level
        and sort of goes from ground
        <br>
        up. I would argue that model should expose high level concepts
        and
        <br>
        operations and then be extended to more fine grained operations
        and
        <br>
        object as we need them.
        <br>
      </blockquote>
      <br>
      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.
      <br>
    </blockquote>
    <br>
    I would disagree with that but not argue ;-)<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      <blockquote type="cite">Admin does not care about responders or
        providers.
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      <blockquote type="cite">Admin cares about the fact that machine is
        enrolled with a particular
        <br>
        domains.
        <br>
      </blockquote>
      <br>
      For domain enrolment there is a realmd provider.
      <br>
    </blockquote>
    <br>
    Only for the first one.<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
       Tweaking low level concepts would be out of scope of the
      <br>
      <blockquote type="cite">initial effort.
        <br>
        <br>
        Would have been nice to see the object diagram and discuss it in
        advance.
        <br>
      </blockquote>
      <br>
      UML diagram is attached. I need to figure a way how to model
      associations though.
      <br>
    </blockquote>
    <br>
    Thanks! Is there a design page on the wiki or at least going to be?<br>
    <br>
    <blockquote cite="mid:535A6B8F.8000105@redhat.com" type="cite">
      <br>
      <blockquote type="cite">
        <br>
        <br>
        --
        <br>
        Thank you,
        <br>
        Dmitri Pal
        <br>
        <br>
        Sr. Engineering Manager IdM portfolio
        <br>
        Red Hat, Inc.
        <br>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        sssd-devel mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
        <br>
        <a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
        <br>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.</pre>
  </body>
</html>