[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