Hello,
Sorry for my English google:) I'm put into production 2 openldap masters, and I asked the same question João Alfredo. * So, if the resultt of this search is the same on all master's this mean that all servers are consistents, right ?*
Ok, the ldapsearch (ldapsearch-x-h Master1 ... and ldapsearch-x-h master2 ...) displays the same values of contextCSN for server ID, but what it proves that they are synchronized?
The question is, why master node, the ldapsearch ContextCSN displays of 2 servers (001 & 002)
Can be put in place a monitoring system to test the replication by performing 2 ldapsearchs, if even then synchronized values.
Merci
------ Arteta.
I dont thing so.
I have found some situations where the contextCSN is the same, but the tree are not synced.
I use a simple script to search all entryCSN from all entries and check then against eachother.
eg:
#!/bin/sh
date=`date +%Y%m%d-%T`
TMPFILE_1='/tmp/master1' TMPFILE_2='/tmp/master2'
ldapsearch -LLL -b "<BASE CONTEXT>" -x -h <IP1> entryCSN>"$TMPFILE_1.full" ldapsearch -LLL -b "<BASE CONTEXT>" -x -h <IP2> entryCSN>"$TMPFILE_2.full"
sed -i '1,3 d' "$TMPFILE_1.full" sed -i '1,3 d' "$TMPFILE_2.full"
more "$TMPFILE_1.full" | grep entryCSN > "$TMPFILE_1.tmp" more "$TMPFILE_2.full" | grep entryCSN > "$TMPFILE_2.tmp"
sort "$TMPFILE_1.tmp" > "$TMPFILE_1.csn" sort "$TMPFILE_2.tmp" > "$TMPFILE_2.csn"
diff "$TMPFILE_1.csn" "$TMPFILE_2.csn" > "$TMPFILE_2.diff"
DIFFC1=`cat "$TMPFILE_2.diff" | wc -l`
if [ $DIFFC1 -eq 0 ]; then echo "OK"; else echo "ERR"; cat $TMPFILE_2.diff fi
Regards,
On Wed, Jan 21, 2009 at 8:51 PM, Guillaume Arteta arteta22000@gmail.comwrote:
Hello,
Sorry for my English google:) I'm put into production 2 openldap masters, and I asked the same question João Alfredo.
So, if the resultt of this search is the same on all master's this mean that all servers are consistents, right ?*
Ok, the ldapsearch (ldapsearch-x-h Master1 ... and ldapsearch-x-h master2 ...) displays the same values of contextCSN for server ID, but what it proves that they are synchronized?
The question is, why master node, the ldapsearch ContextCSN displays of 2 servers (001 & 002)
Can be put in place a monitoring system to test the replication by performing 2 ldapsearchs, if even then synchronized values.
Merci
Arteta.
jakjr wrote:
I dont thing so.
I have found some situations where the contextCSN is the same, but the tree are not synced.
Then you have found a bug that should be reported to the ITS. Two servers with same contextCSN are supposed to have matching content.
ITS 5843, the delete bug. http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5843;selectid=5843
On Thu, Jan 22, 2009 at 1:46 PM, Howard Chu hyc@symas.com wrote:
jakjr wrote:
I dont thing so.
I have found some situations where the contextCSN is the same, but the tree are not synced.
Then you have found a bug that should be reported to the ITS. Two servers with same contextCSN are supposed to have matching content.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hello,
Here is an example of a problem, I use a script to test the contextCSN regularly:
LDAP1 = `cat / etc / ldap / config-dc | suffix grep | cut-d "-f 2 | xargs-i ldapsearch-LLL-H ldap: / / 10.7.0.12-D "cn = admin, ()" XXXXXXX-w-x-s base-b () contextCSN 2> / dev / null | grep-v "# 000 #" `
Same principle with ldap2 if contextCSN is the same, return "ok".
And often, I have some problems:
dn: dc = XXXXXX, dc = fr contextCSN: 20090211133509.490550Z # 000000 # 000000 # 001 contextCSN: 20090120132016.148736Z # 000000 # 000000 # 002
dn: dc = XXXXXX, dc = com contextCSN: 20090212102723.658506Z # 000000 # 000000 # 001 contextCSN: 20090120145041.933994Z # 000000 # 000000 # 002
###################
dn: dc = XXXXXX, dc = fr contextCSN: 20090211133509.490550Z # 000000 # 000000 # 001 contextCSN: 20090120132016.148736Z # 000000 # 000000 # 002
dn: dc = XXXX, dc = com contextCSN: 20090212102657.736926Z # 000000 # 000000 # 001 contextCSN: 20090120145041.933994Z # 000000 # 000000 # 002
####################
Yet, when I test the script with João Alfredo, it returns me an "ok", the entryCSN are identical. *A restart of splapd used to resynchronize the contextcsn.*
*In contrast, for dc = XXXXXX, dc = fr. *
The contextcsn is ok, but I have errors with the entryCSN :|
cat / tmp/masterldap1.full
dn: ou = people, dc = XXXXX, dc = fr entryCSN: 20080529153849.000000Z # 000000 # 000000 # 000
dn: ou = Users, dc = XXXXX, dc = fr entryCSN: 20081126190244.000000Z # 000000 # 000000 # 000
####################
cat / tmp/masterldap2.full
dn: ou = people, dc = XXXXXX, dc = fr entryCSN: 20080529153849Z # 000000 # 000000 # 00
dn: ou = Users, dc = XXXXX, dc = fr entryCSN: 20081126190244Z # 000000 # 000000 # 00
Are not a bugg?.
####################
database bdb suffix "dc=XXXXXX,dc=fr" checkpoint 512 30 rootdn "cn=admin,dc=XXXXXX,dc=fr" rootpw XXXXXXX directory "/data/openldap/ldap"
index entryCSN,entryUUID,objectClass,description eq lastmod on
access to dn.base="" by * read
access to attrs=userPassword by anonymous auth by self write by * none
limits dn.regex="cn=admin,dc=XXXXXX,dc=fr" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
overlay syncprov syncprov-checkpoint 100 5 syncprov-sessionlog 1000
syncrepl rid=001 provider=ldap://10.7.0.12 type=refreshAndPersist retry="60 +" searchbase="dc=XXXXX,dc=fr" schemachecking=off bindmethod=simple binddn="cn=admin,dc=XXXXXX,dc=fr" credentials=XXXXX
syncrepl rid=002 provider=ldap://10.7.0.11 type=refreshAndPersist retry="60 +" searchbase="dc=XXXXX,dc=fr" schemachecking=off bindmethod=simple binddn="cn=admin,dc=XXXXX,dc=fr" credentials=XXXXXX
mirrormode on
####################
------ Arteta
Guillaume Arteta wrote:
Yet, when I test the script with João Alfredo, it returns me an "ok", the entryCSN are identical. *A restart of splapd used to resynchronize the contextcsn.*
_In contrast, for dc = XXXXXX, dc = fr. _
The contextcsn is ok, but I have errors with the entryCSN :|
cat / tmp/masterldap1.full
dn: ou = people, dc = XXXXX, dc = fr entryCSN: 20080529153849.000000Z # 000000 # 000000 # 000
dn: ou = Users, dc = XXXXX, dc = fr entryCSN: 20081126190244.000000Z # 000000 # 000000 # 000
####################
cat / tmp/masterldap2.full
dn: ou = people, dc = XXXXXX, dc = fr entryCSN: 20080529153849Z # 000000 # 000000 # 00
dn: ou = Users, dc = XXXXX, dc = fr entryCSN: 20081126190244Z # 000000 # 000000 # 00
Are not a bugg?.
No. It appears that your entries on masterldap2 were created with OpenLDAP 2.3 and haven't been changed since they were created. The values you see there are semantically equivalent to the values on masterldap1; i.e. as far as we care they are identical.
No. It appears that your entries on masterldap2 were created with OpenLDAP 2.3 and haven't been changed since they were created. The values you see there are semantically equivalent to the values on masterldap1; i.e. as far as we care they are identical.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Merci,
I just remove all entries entryUUID / contextCSN / entryCSN with ldif, I will even if the error returns.
By against, I always have the problem that contextCSN Not Update Yet entryCSN are ok. My problem may be these values?
syncprov-checkpoint 100 5 syncprov-sessionlog 1000
I use sessionlog in 1000, because I read it here: => http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5843
Otherwise the contextcsn is updated every 5 minutes?
-------- Guillaume.
Guillaume Arteta wrote:
No. It appears that your entries on masterldap2 were created with OpenLDAP 2.3 and haven't been changed since they were created. The values you see there are semantically equivalent to the values on masterldap1; i.e. as far as we care they are identical. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/Merci,
I just remove all entries entryUUID / contextCSN / entryCSN with ldif, I will even if the error returns.
By against, I always have the problem that contextCSN Not Update Yet entryCSN are ok. My problem may be these values?
syncprov-checkpoint 100 5 syncprov-sessionlog 1000
I use sessionlog in 1000, because I read it here: => http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5843
That bug is fixed in 2.4.14, you should upgrade.
That bug is fixed in 2.4.14, you should upgrade.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Ok.
Small question :)
Should we put syncprov-sessionlog in 1000 only with the mode refreshOnly? or also with refreshAndPersist (the one I use) ?
Merci. ----------- Guillaume.
sessionlog is a log of changes in-memory. But refreshAndPersist should replicate changes on fly.
So, to me, don't make any sense to keep this two options together.
Regards, Jakjr
On Mon, Feb 16, 2009 at 2:27 PM, Guillaume Arteta arteta22000@gmail.com wrote:
That bug is fixed in 2.4.14, you should upgrade.
-- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Ok.
Small question :)
Should we put syncprov-sessionlog in 1000 only with the mode refreshOnly? or also with refreshAndPersist (the one I use) ?
Merci.
Guillaume.
jakjr wrote:
sessionlog is a log of changes in-memory. But refreshAndPersist should replicate changes on fly.
So, to me, don't make any sense to keep this two options together.
Networks aren't perfect. If the consumer loses its connection and reconnects, the sessionlog will still help at that point.
Regards, Jakjr
On Mon, Feb 16, 2009 at 2:27 PM, Guillaume Artetaarteta22000@gmail.com wrote:
That bug is fixed in 2.4.14, you should upgrade.
-- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Ok.
Small question :)
Should we put syncprov-sessionlog in 1000 only with the mode refreshOnly? or also with refreshAndPersist (the one I use) ?
Merci.
Guillaume.
On Mon, Feb 16, 2009 at 3:11 PM, Howard Chu hyc@symas.com wrote:
jakjr wrote:
sessionlog is a log of changes in-memory. But refreshAndPersist should replicate changes on fly.
So, to me, don't make any sense to keep this two options together.
Networks aren't perfect. If the consumer loses its connection and reconnects, the sessionlog will still help at that point.
OK, that is good reason. So, after a network re-connection, the consumer should make a full re-synchronization. Using Sessionlog prevents this, right ?
Thanks.
Regards, Jakjr
On Mon, Feb 16, 2009 at 2:27 PM, Guillaume Artetaarteta22000@gmail.com wrote:
That bug is fixed in 2.4.14, you should upgrade.
-- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Ok.
Small question :)
Should we put syncprov-sessionlog in 1000 only with the mode refreshOnly? or also with refreshAndPersist (the one I use) ?
Merci.
Guillaume.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
2009/2/16 jakjr joao.alfredo@gmail.com
sessionlog is a log of changes in-memory. But refreshAndPersist should replicate changes on fly.
So, to me, don't make any sense to keep this two options together.
Regards, Jakjr
Hello,
Yesterday, I went into 2.4.14. But I still have a problem contextcsn who is out of date. The 2 servers are synchronized via ntpdate but removing 2 values in a dc whith master1, l'entryCSN is correct:
master1:
dn: uid=XXXX,ou=utilisateurs,dc=glon,dc=com entryCSN: 20090218081359.232700Z#000000#001#000000
master2:
dn: uid=XXXXX,ou=utilisateurs,dc=glon,dc=com entryCSN: 20090218081359.232700Z#000000#001#000000
############
master1:
dn: cn=XXXX,ou=utilisateurs,dc=glon,dc=com entryCSN: 20090218083153.439947Z#000000#001#000000
dn: cn=XXXX,ou=utilisateurs,dc=glon,dc=com givenName: Test sn: TEST gidNumber: 1000 objectClass: inetOrgPerson objectClass: posixAccount objectClass: top homeDirectory: /home/users/test structuralObjectClass: inetOrgPerson creatorsName: cn=admin,dc=glon,dc=com cn: XXXXXXXXX userPassword:: e1NIQX1xVXFQNWN5eG02WWNUQWh6MDVIcGg1Z3Z1OU09 entryUUID: 05c2503e-9091-102d-805e-45c22a025713 createTimestamp: 20090216161716Z uid: test uidNumber: 1008 departmentNumber: 75 entryCSN: 20090218083153.439947Z#000000#001#000000 modifiersName: cn=admin,dc=glon,dc=com modifyTimestamp: 20090218083153Z
-----------------------------------------
master2:
dn: cn=XXXX,ou=utilisateurs,dc=glon,dc=com entryCSN: 20090218083153.439947Z#000000#001#000000
dn: cn=XXXX,ou=utilisateurs,dc=glon,dc=com givenName: Test sn: TEST gidNumber: 1000 objectClass: inetOrgPerson objectClass: posixAccount objectClass: top homeDirectory: /home/users/test structuralObjectClass: inetOrgPerson creatorsName: cn=admin,dc=glon,dc=com cn: XXXXXXXXXX userPassword:: e1NIQX1xVXFQNWN5eG02WWNUQWh6MDVIcGg1Z3Z1OU09 entryUUID: 05c2503e-9091-102d-805e-45c22a025713 createTimestamp: 20090216161716Z uid: test uidNumber: 1008 departmentNumber: 75 entryCSN: 20090218083153.439947Z#000000#001#000000 modifiersName: cn=admin,dc=glon,dc=com modifyTimestamp: 20090218083153Z
#############
but contextCSN: -----------------
Master1:
dn: dc=glon,dc=com contextCSN: 20090218083153.439947Z#000000#001#000000 contextCSN: 20090217135202.777737Z#000000#002#000000
Master2:
dn: dc=glon,dc=com contextCSN: 20090218081351.574766Z#000000#001#000000 contextCSN: 20090217135202.777737Z#000000#002#000000
[-------------]
With a change of master2:
Master1:
dn: dc=glon,dc=com contextCSN: 20090218081351.574766Z#000000#001#000000 contextCSN: 20090218085423.012016Z#000000#002#000000
Master2:
dn: dc=glon,dc=com contextCSN: 20090218083153.439947Z#000000#001#000000 contextCSN: 20090217135202.777737Z#000000#002#000000
by against, I can not understand the hours used.
master1:~# date Wed Feb 18 09:39:00 CET 2009
master2:~# date Wed Feb 18 09:39:02 CET 2009 I must have a delay of 2 seconds, yet the same ntp server.
Why contextcsn and entryCSN have values out of sync with the clock? 20090218081351 => 2009/02/18 à 08h13 51 s.
------- Guillaume.
Hello,
I have just days to 2.4.15 and it works well.
Just a little problem. The contextcsn a 1 hour late. I am in France.
##################
Every 5.0s: ./testldap Wed Feb 25 10:56:51 2009
dn: dc=XXXXX,dc=fr contextCSN: 20090225095401.266551Z#000000#001#000000 contextCSN: 20090220173544.620042Z#000000#002#000000
dn: dc=XXXXX,dc=fr contextCSN: 20090225095401.266551Z#000000#001#000000 contextCSN: 20090220173544.620042Z#000000#002#000000
##################
Is there a solution?
Merci ------------ Guillaume.
Guillaume Arteta wrote:
Hello,
I have just days to 2.4.15 and it works well.
Just a little problem. The contextcsn a 1 hour late. I am in France.
##################
Every 5.0s: ./testldap Wed Feb 25 10:56:51 2009
dn: dc=XXXXX,dc=fr contextCSN: 20090225095401.266551Z#000000#001#000000 contextCSN: 20090220173544.620042Z#000000#002#000000
dn: dc=XXXXX,dc=fr contextCSN: 20090225095401.266551Z#000000#001#000000 contextCSN: 20090220173544.620042Z#000000#002#000000
##################
Is there a solution?
Yes, move to England.
The timestamps are stored in UTC, not your local time zone. That is clearly denoted by the "Z" in the timezone position of the GeneralizedTime value.
openldap-technical@openldap.org
-
Guillaume Arteta -
Howard Chu -
jakjr