[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
more elaborate constraints in 'replica' for slurpd ?
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.