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@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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
