-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap- technical-bounces@OpenLDAP.org] On Behalf Of Gavin Henry Sent: Tuesday, July 27, 2010 5:23 AM To: Paul Harvey Cc: openldap-technical@openldap.org Subject: Re: How to check LDAP replication status?
On 22/07/10 13:55, Paul Harvey wrote:
On 07/22/2010 02:34 PM, Priyesh Potdar wrote:
Precisely what i was after, thanks.
Is there any way to manually create a hidden entry, in a similar
style
to the contextCSN, or would this require the an overlay to be
written?
That's what the contextCSN is for. Just ldapsearch for it and if they match, they are up to date:
http://blog.suretecsystems.com/archives/146-OpenLDAP-Quick-Tips- Checking-the-state-of-replication.html
I really need to start those "Quick Tips" up again!
If anyone wants to contribute some?
That’s a simple passive check, which will detect failure after it happens (ie: after you update something important and it fails). This is fine if you frequently make updates, but our tree rarely changes. To actively check that the replication is still on-going we setup a script called from cron and a simple ldapsearch plugin for nagios:
#!/bin/bash
SERVER=$1 CHECKNUM=$2 DATE=`date +%s`
ldapmodify -x -H "ldaps://$SERVER" -D "cn=nagcheck${CHECKNUM},dc=example,dc=com" -w 'SECRET' <<EODD dn: cn=nagcheck${CHECKNUM},dc=example,dc=com changetype: modify replace: description description: $DATE
EODD
And to check:
for NUM in 1 2 ; do RES=`ldapsearch -x -LLL -H "ldaps://$ldapserver" -b 'dc=example,dc=com' "(cn=nagcheck${NUM})" description 2>&1` TS=`echo ${RES} | grep description | sed -e 's/[^0-9]//g'` if [[ -z $TS ]] ; then FAIL="$FAIL Check ${NUM} ${RES}. " ; continue ; fi if [[ ! $TS -gt 0 ]] ; then FAIL="$FAIL Check ${NUM} ${RES} malformed answer. " ; continue ; fi if [[ $((${CURDATE}-${TS})) -gt $MAXTIME ]] || [[ $((${CURDATE}-${TS})) -lt $MAXTIME ]] ; then EXCEED="$EXCEED Check ${NUM} $((${CURDATE}-${TS}))s." ; fi done
<error reporting stuff here...mostly echoing vars and exit 2 for nagios>
It’s a bit more complex but should find failure before something important (employee termination?) doesn’t sync somewhere, and gives us more detail than a mismatched CSN. The checks could be tweaked a bit for better reporting...
-T