On Wednesday 27 May 2009 13:12:03 Howard Chu wrote:
Guillaume Rousse wrote:
Howard Chu a écrit :
Guillaume Rousse wrote:
Hello list.
I'm using delta-syncrepl in search-and-persist mode between my slaves and my master server. And I'm using a nagios plugin to check sync status, based on value of contextCSN attribute. But I'm often sync alerts for unknown reasons.
First issue, is this an expected result to have an higher contextCSN on the slave side ? From what I've understood from contextCSN, this attribute is updated each time a write operation is performed on the server. As the slave server is not supposed not to perform any write operation, this should never happens. However, it does:
Ordinarily, a slave cannot initiate any write operations. However, you appear to be using ppolicy. The ppolicy overlay writes Bind status updates to the local server, regardless of master or slave status. Thus, it can cause the slave's contextCSN to be newer than the master's.
OK, I guess it means higher CSN reports on slave side can be discarded.
I suggest adding your answer to section 18.1.1.2. (Syncrepl Details) of the Admin guide, with a few modifications.
Ordinarily, a consumer cannot initiate any write operations. However, some specific overlays may bring exceptions to this rule. For instance, the ppolicy overlay writes Bind status updates to the local server, regardless of its master or slave status. Thus, it can cause the consumer's contextCSN to be newer than the provider's.
Also, you didn't answer to my second question: syncrepl is also supposed to sync operational attributes. Does ppolicy also constitute an exception here ?
For the moment, yes - it writes directly to the underlying database, bypassing syncprov. The question of how policy state should behave in a replicated environment is complicated, and the ppolicy spec is silent in this area.
There are some complications with ppolicy in a replicated environment that cannot be elegantly solved (IMHO) without policy state on replicas being propagated to the other servers.
Specifically, in an environment with multiple slaves, I found it necessary to search all servers for locked out accounts, and if an account was locked out on a replica but not on the master, I would have to first lock out (by adding pwdAccountLockedTime) the account on the master, then unlock it / reset it.
However, this would still leave password failures (pwdAccountFailureTime) attributes stored on all the servers for this account, and (AFAICR) could not be removed via any means, meaning that these accounts could then be locked out by one additional failed attempt. (Since our contractors are no longer on- site, I haven't needed the script I used for this much, so the details may not be 100% correct).
IMHO, password policy state must be propagated to all servers (e.g., chained to the master).
Regards, Buchan