[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ITS #7161, ppolicy pwdFailureTime resolution should be better than 1 second
Hi,
On Sun, 25 May 2014, Michael StrÃder wrote:
'pwdFailureTime' gets replicated?
ist does if you configure ppolicy_forward_updates (olcPPolicyForwardUpdates):
Yupp, chaining.
This is asking for trouble anyway as you already noticed yourself.
yes this was for chaining. And I was bitten by some really digusting issues.
Nevertheless I do see the metadata from slapo-ppolicy getting replicated between masters in my current setup. I just checked and have forward_updates turned off.
Following is from ppolicy.c and we should go intot the else block where dont_replicate is only set for SLAP_SINGLE_SHADOW:
1148 /* If this server is a shadow and forward_updates is true,
1149 * use the frontend to perform this modify. That will trigger
1150 * the update referral, which can then be forwarded by the
1151 * chain overlay. Obviously the updateref and chain overlay
1152 * must be configured appropriately for this to be useful.
1153 */
1154 if ( SLAP_SHADOW( op->o_bd ) && pi->forward_updates ) {
1155 op2.o_bd = frontendDB;
1156
1157 /* Must use Relax control since these are no-user-mod */
1158 op2.o_relax = SLAP_CONTROL_CRITICAL;
1159 op2.o_ctrls = ca;
1160 ca[0] = &c;
1161 ca[1] = NULL;
1162 BER_BVZERO( &c.ldctl_value );
1163 c.ldctl_iscritical = 1;
1164 c.ldctl_oid = LDAP_CONTROL_RELAX;
1165 } else {
1166 /* If not forwarding, don't update opattrs and don't replicate */
1167 if ( SLAP_SINGLE_SHADOW( op->o_bd )) {
1168 op2.orm_no_opattrs = 1;
1169 op2.o_dont_replicate = 1;
1170 }
1171 op2.o_bd->bd_info = (BackendInfo *)on->on_info;
1172 }
This seems to translate into ppolicy changes being replicated between masters which is something I rely on in the current design. I am still not 100% sure on the rationale of the SLAP_SINGLE_SHADOW() check in the else path but it obviously does what I need.
Mileage may of course vary because of scaling issues and replicating timestamps with microsend resolution does not make sense in this use case.
I leveraged above code in my patch for getting authTimestamp replicated between masters in ITS#7721.
I had done the patch with chaining in mind but now also use it with plain multimaster replication without any chaining.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/