Re: synchronisation monitoring, contextCSN and operational attributes

[Buchan Milne <bgmilne@staff.telkomsa.net>]

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