<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><font face="Times New Roman, Times,
        serif">Hello Nathaniel,<br>
        <br>
      </font>
      <blockquote><font face="Times New Roman, Times, serif">sanitize_input
          translates MOD/REPLACE into MOD/DEL+MOD/ADD. It looks good but
          difficult to think to all possible cases.<br>
          I think to the following corner case:<br>
          The initial entry has ipatokenHOTPcounter=5<br>
          ldapmodify..<br>
          changetype: modify<br>
          add: ipatokenHOTPcounter<br>
          ipatokenHOTPcounter: 6<br>
          -<br>
          replace: ipatokenHOTPcounter<br>
          ipatokenHOTPcounter: 7<br>
          <br>
          It translates<br>
          add: 6<br>
          del: 5<br>
          add: 7<br>
          <br>
          This operation will fail because ipatokenHOTPcounter is
          single-valued although IMHO it should succeed.<br>
          This is a so special operation that is may not really be a
          concern.<br>
          <br>
          It is important that attribute are single valued. The
          replication changelog will replicated MOD/DEL + MOD/ADD for a
          MOD/REPL.<br>
          That means that if the attributes are updated on several
          masters, the number of values can likely increase. Where for
          single value it should only keep the most recent value.<br>
          <br>
          thanks<br>
          theirry</font><br>
      </blockquote>
      On 09/19/2014 10:15 PM, Nathaniel McCallum wrote:<br>
    </div>
    <blockquote cite="mid:1411157743.18665.12.camel@redhat.com"
      type="cite">
      <pre wrap="">This new version fixes a small style issue pointed out to me by richm
(thanks!).

On Fri, 2014-09-19 at 13:39 -0400, Nathaniel McCallum wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">The attached version of the patch should solve all of these issues. It
should also be more performant and use less memory.

Nathaniel


On Wed, 2014-09-17 at 15:33 +0200, thierry bordaz wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On 09/15/2014 09:05 PM, Nathaniel McCallum wrote:

</pre>
          <blockquote type="cite">
            <pre wrap="">This plugin ensures that all counter/watermark operations are atomic
and never decrement. Also, deletion is not permitted.

<a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/4494">https://fedorahosted.org/freeipa/ticket/4494</a>


_______________________________________________
Freeipa-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a>
</pre>
          </blockquote>
          <pre wrap="">Hello Nathaniel,

        More thoughts.. I think being "betxnpreoperation" you are safe
        with parallel client ops and the check is atomic. I have few
        comments:
              * Shouldn't be implemented
                SLAPI_PLUGIN_CLOSE_FN/SLAPI_PLUGIN_START_FN callback,
                even if they are empty.
              * In load_counters, in case we have a target entry that
                has not 'objectclass'  'ipatokenHOTP|ipatokenTOTP' and
                the mod operation:
                dn: <entry>
                changetype: modify
                replace: ipatokenHOTPcounter
                ipatokenHOTPcounter: 200
                -
                add: objectclass
                objectclass: ipatokenHOTP
                
                
                I wonder if the operation will not fail although IMHO
                it should succeeds.
                Shouldn't let the schema checking reject the operation
                if the attribute is not granted by the entry
                objectclass
              * in load_counters, I am under the impression it may
                return  ipatokenHOTPcounter or ipatokenTOTPwatermark
                (ipatokenHOTPcounter is missing).
                But then how the caller knows that the returned value
                is a counter or a watermark ?
              * in ldapmod_is_attrs you may prefer PL_strcasecmp to
                strcasecmp
        
        About replicated updates, if updates of counters/watermark are
        done on several servers. Then a replicated operation may want
        to set counters/watermark with a smaller value that the
        existing one. In that case, it will return unwilling to
        perform. That could break replication.
        If the update comes from replication and the value is going
        backward, we could make the operation a nop operation (setting
        the attribute to its current value).
        
        
        thanks
        theirry
        
        
</pre>
        </blockquote>
        <pre wrap="">
_______________________________________________
Freeipa-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
  </body>
</html>