more elaborate constraints in 'replica' for slurpd ?

[Ralf Hack <ralf.hack@pipex.net>]

Hi,

	I have a query regarding the 'attr' parameter of the 
'replica' statement. Currently, the attribute mentioned in the attr 
can be selected or deselected. For me it would be useful to specify 
that the attribute must not increase in value (given that it is an 
integer).

	The background: my aim is to provide secure access to two 
physically separate locations, virtually independent but have a 
single administration interface. The user can choose the location to 
login to. My plan is to use multimaster replication to keep the 
locations in sync. But the same scenario can happen with failover 
systems that use slurpd in one shot mode to sync when recovering.

	We have modified OPIE (one time passwords) to use the ldap 
server as backend instead of a flat file. OPIE uses a sequence number 
(the currently active password so to speak). Normally, the user would 
login successfully and thus reducing the sequence number by one each 
time. Since the two ldap servers will eventually get out of step and 
syncronise again to recover, the wrong sequence number (larger, used 
already) may survive. Looking at the code, the slowest slurpd (mod 
the value last) decides which sequence number survives which may not 
be the smallest (I think).

	I am planning to patch slurpd to perform this check for a 
specific attributes. Has there been any work (patches) done to do so 
? Is there anything seriously wrong with such an effort? As far as 
the implementation details are concerned, I am still drawing up 
possible options. Perhaps some form of sync stamping (syncrepl?) 
existing in slapd, written to the replog file can be used to decided 
which change needs to survive ?


	Thanks for your input.

R.