[Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin

Nathaniel McCallum npmccallum at redhat.com
Fri Sep 19 17:39:29 UTC 2014


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:
> On 09/15/2014 09:05 PM, Nathaniel McCallum wrote:
> 
> > This plugin ensures that all counter/watermark operations are atomic
> > and never decrement. Also, deletion is not permitted.
> > 
> > https://fedorahosted.org/freeipa/ticket/4494
> > 
> > 
> > _______________________________________________
> > Freeipa-devel mailing list
> > Freeipa-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-devel
> 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
>         
>         

-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-npmccallum-0064.1-Create-ipa-otp-decrement-389DS-plugin.patch
Type: text/x-patch
Size: 17891 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140919/72300459/attachment.bin>


More information about the Freeipa-devel mailing list