On Wednesday 05 September 2007 14:14:56 Aaron Richton wrote:

http://www.openldap.org/lists/openldap-software/200602/msg00158.html

We use this with only slight modifications. Of course, the only time it has ever produced a meaningful notification has been for a few minutes following a fresh server install as changes made since the last slapcat replicate in. (And since that's an expected condition, it's of minimal interest to me on Nagios.)

I'll note that all of our syncrepl failures (which are zero as of late; run 2.3.38!) were much more insidious bugs that updated contextCSN because "they thought they worked."

On Wed, 5 Sep 2007, Bruno Lezoray EMSM wrote:

...

Hi all,

few months ago, i developed script to monitor slurpd replication, by checking replication logs. Now, we want to implement SyncRepl replication, and it looks more complex to know a status of the replication. Is someone already developed a tool to do that ?

My first idea is to compare the contextCSN of the suffix entry between the master and the slave. I don't know if there is some specific logs that indicate the replication is broken.

Here is mine, which I use with Hobbit, but which can also be used standalone (with name/IP of servers as arguments):

http://staff.telkomsa.net/~bgmilne/bb-openldap.pl

It also does performance monitoring (e.g. graphs of searches, binds, operations etc.) in conjunction with Hobbit. It needs no configuration (finds all databases with syncrepl, and the updateref for the database, from the contents of the monitor backend), but requires (at present) anonymous access to cn=monitor.

What it does pick up for me is when replication is interrupted on servers separated by a firewall (which I have started observing again, now that we do actually have some slaves on a different network).

Regards, Buchan

On Thursday 06 September 2007 14:41:38 Bruno Lezoray EMSM wrote:

Buchan Milne wrote:

...

On Wednesday 05 September 2007 14:14:56 Aaron Richton wrote:

...

http://www.openldap.org/lists/openldap-software/200602/msg00158.html

We use this with only slight modifications. Of course, the only time it has ever produced a meaningful notification has been for a few minutes following a fresh server install as changes made since the last slapcat replicate in. (And since that's an expected condition, it's of minimal interest to me on Nagios.)

I'll note that all of our syncrepl failures (which are zero as of late; run 2.3.38!) were much more insidious bugs that updated contextCSN because "they thought they worked."

On Wed, 5 Sep 2007, Bruno Lezoray EMSM wrote:

...

Hi all,

few months ago, i developed script to monitor slurpd replication, by checking replication logs. Now, we want to implement SyncRepl replication, and it looks more complex to know a status of the replication. Is someone already developed a tool to do that ?

My first idea is to compare the contextCSN of the suffix entry between the master and the slave. I don't know if there is some specific logs that indicate the replication is broken.

Here is mine, which I use with Hobbit, but which can also be used standalone (with name/IP of servers as arguments):

http://staff.telkomsa.net/~bgmilne/bb-openldap.pl

It also does performance monitoring (e.g. graphs of searches, binds, operations etc.) in conjunction with Hobbit. It needs no configuration (finds all databases with syncrepl, and the updateref for the database, from the contents of the monitor backend), but requires (at present) anonymous access to cn=monitor.

What it does pick up for me is when replication is interrupted on servers separated by a firewall (which I have started observing again, now that we do actually have some slaves on a different network).

Regards, Buchan

Hi Buchan,

i'm trying to test your script but, it didn't found entries for the query: # Get databases that have a master $ldap_message = $ldap{$slave}->search( base => $monitor, scope => 'sub', filter => '(&(namingContexts=*)(MonitorUpdateRef=*))', attrs => [ 'monitorupdateref', 'namingContexts' ] ); And i have the following replication configuration syncrepl rid=2 provider=ldap://10.1.1.69:389 type=refreshOnly #type=refreshAndPersist interval=00:00:05:00 searchbase="o=test" filter="(objectClass=*)" scope=sub #attrs="cn,sn,ou,telephoneNumber,title,l" schemachecking=on bindmethod=simple binddn="cn=root DN, o=test" credentials=********

What do you think ?

My first guess would be you don't have back-monitor configured. Add:

moduleload back-monitor.la database monitor access to * by * read

before your first database (or something similar) in slapd.conf and restart.

Or, try this ldapsearch, see what you get back:

$ ldapsearch -LLL -x -h <server> -b cn=monitor '(&(namingContexts=*) (MonitorUpdateRef=*))' monitorupdateref namingContexts

Is it dependent of the replication type (refreshOnly and refreshAndPersist) ?

No.

Regards, Buchan