2:51 p.m.
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.
6:27 a.m.
New subject: contextCSN
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(a)gmail.com>wrote:
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.
7:46 a.m.
New subject: contextCSN
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/
8:10 a.m.
New subject: contextCSN
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(a)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/
6:13 a.m.
New subject: contextCSN
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
2:39 p.m.
New subject: contextCSN
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:59 a.m.
New subject: contextCSN
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.
9:09 a.m.
New subject: contextCSN
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:27 a.m.
New subject: contextCSN
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.
10:06 a.m.
New subject: contextCSN
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(a)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.
10:11 a.m.
New subject: contextCSN
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 Arteta<arteta22000(a)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/
11 a.m.
New subject: contextCSN
On Mon, Feb 16, 2009 at 3:11 PM, Howard Chu <hyc(a)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 Arteta<arteta22000(a)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/
1:58 a.m.
New subject: contextCSN
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.
2:02 a.m.
New subject: contextCSN
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:18 a.m.
New subject: contextCSN
2009/2/16 jakjr <joao.alfredo(a)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.
5324
days inactive
5359
days old
openldap-technical@openldap.org
14 comments
3 participants
participants (3)
-
Guillaume Arteta -
Howard Chu -
jakjr