[Date Prev][Date Next] [Chronological] [Thread] [Top]

more elaborate constraints in 'replica' for slurpd ?


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.