10 p.m.
Dear all,
I am running the openldap 2.4.11 with 4 way masters (SID=001 to 004) configured. (my
suffix is empty in slapd.conf)
The data can be synced initially. I add records in 1 server and all the other 3
servers will have the new record added. However, I found that after running for some
time, one server will have corrupted contextCSN in SID=001.
dn:
contextCSN:: sCttCIio0wAxNTQzMTMuMDQ1Mjk3WiMwMDAwMDAjMDAyIzAwMDAwMA==
contextCSN: 20081107061013.853051Z#000000#001#000000
contextCSN: 20081107073602.911356Z#000000#003#000000
contextCSN: 20081107061028.825773Z#000000#004#000000
The contextCSN for SID=002 in server 1 is corrupted. So, whenever there is an update
in SID=002 server, the SID=001 server will never get the update,
however, when there is update in SID=003 or SID=004 server, the records will get
updated in SID=001.
We have a background cron job in each server running at 1 minutes interval to retrieve
the records and set some user defined attributes if it meet some certain criteria.
What's the cause to this corruption ? Is there any way to recover the corrupted
contextCSN by command or script without rebuild the data ?
Thanks
_________________________________________________________________
用部落格分享照片、影音、趣味小工具和最愛清單，盡情秀出你自己 — Windows Live Spaces
http://spaces.live.com/
1:49 a.m.
New subject: none
Hello,
Bad Guy <badguy9588(a)hotmail.com> writes:
Dear all,
I am running the openldap 2.4.11 with 4 way masters (SID=001 to
004) configured. (my suffix is empty in slapd.conf)
The data can be synced initially. I add records in 1 server and
all the other 3 servers will have the new record added. However, I
found that after running for some time, one server will have corrupted
contextCSN in SID=001.
dn:
contextCSN::
sCttCIio0wAxNTQzMTMuMDQ1Mjk3WiMwMDAwMDAjMDAyIzAwMDAwMA==
contextCSN: 20081107061013.853051Z#000000#001#000000
contextCSN: 20081107073602.911356Z#000000#003#000000
contextCSN: 20081107061028.825773Z#000000#004#000000
The contextCSN for SID=002 in server 1 is corrupted. So, whenever
there is an update in SID=002 server, the SID=001 server will never
get the update,
however, when there is update in SID=003 or SID=004 server, the
records will get updated in SID=001.
We have a background cron job in each server running!
at 1 minutes interval to retrieve the records and set some user
defined attributes if it meet some certain criteria.
What's the cause to this corruption ? Is there any way to recover
the corrupted contextCSN by command or script without rebuild the data
In fact it is base64 encoded
dieter@magenta:~> mmencode -u
sCttCIio0wAxNTQzMTMuMDQ1Mjk3WiMwMDAwMDAjMDAyIzAwMDAwMA==
�+���154313.045297Z#000000#002#000000
-Dieter
--
Dieter Klünter | Systemberatung
sip: +49.180.1555.7770535
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
3:16 a.m.
Bad Guy wrote:
Dear all,
I am running the openldap 2.4.11 with 4 way masters (SID=001 to 004) configured.
(my suffix is empty in slapd.conf)
The data can be synced initially. I add records in 1 server and all the other 3
servers will have the new record added. However, I found that after running for some
time, one server will have corrupted contextCSN in SID=001.
dn:
contextCSN:: sCttCIio0wAxNTQzMTMuMDQ1Mjk3WiMwMDAwMDAjMDAyIzAwMDAwMA==
contextCSN: 20081107061013.853051Z#000000#001#000000
contextCSN: 20081107073602.911356Z#000000#003#000000
contextCSN: 20081107061028.825773Z#000000#004#000000
The contextCSN for SID=002 in server 1 is corrupted. So, whenever there is an update
in SID=002 server, the SID=001 server will never get the update,
however, when there is update in SID=003 or SID=004 server, the records will get
updated in SID=001.
We have a background cron job in each server running at 1 minutes interval to
retrieve the records and set some user defined attributes if it meet some certain
criteria.
What's the cause to this corruption ? Is there any way to recover the corrupted
contextCSN by command or script without rebuild the data ?
Looks similar to <http://www.openldap.org/its?findid=5661>;. Can you
post your configuration? Also, can you try re24 code from the CVS (or
wait until 2.4.13 is out)?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
12:15 a.m.
New subject: contextCSN corrupted
config as follow :
Server 1 :
syncrepl rid=001
provider=ldap://host1:389/
bindmethod=simple
binddn="cn=Manager"
credentials=secret
searchbase="o=ABC"
schemachecking=off
type=refreshAndPersist
attrs="*,+"
retry="1 +"
syncrepl rid=002
provider=ldap://host2:389/
bindmethod=simple
binddn="cn=Manager"
credentials=secret
searchbase="o=ABC"
schemachecking=off
type=refreshAndPersist
attrs="*,+"
retry="1 +"
syncrepl rid=003
provider=ldap://host3:389/
bindmethod=simple
binddn="cn=Manager"
credentials=secret
searchbase="o=ABC"
schemachecking=off
type=refreshAndPersist
attrs="*,+"
retry="1 +"
syncrepl rid=004
provider=ldap://host4:389/
bindmethod=simple
binddn="cn=Manager"
credentials=secret
searchbase="o=ABC"
schemachecking=off
type=refreshAndPersist
attrs="*,+"
retry="1 +"
mirrormode on
serverID 001
# Performance tuning directives
sizelimit 5000
threads 8
idletimeout 14400
cachesize 10000
checkpoint 256 15
for server 2, server 3, server 4, config are the same as server 1, except the serverID is
different (serverID 002, serverID 003, serverID 004 respectively).
My question is, for each server, the config for syncrepl should exclude itself ?
i.e. for server 1, no need to include these lines ?? similar for server 2, 3, 4 ???
syncrepl rid=001
provider=ldap://host1:389/
bindmethod=simple
binddn="cn=Manager"
credentials=secret
searchbase="o=ABC"
schemachecking=off
type=refreshAndPersist
attrs="*,+"
retry="1 +"
Thanks
Date: Tue, 11 Nov 2008 12:16:39 +0100
From: ando(a)sys-net.it
To: badguy9588(a)hotmail.com
CC: openldap-technical(a)openldap.org
Subject: Re:
Bad Guy wrote:
> Dear all,
>
> I am running the openldap 2.4.11 with 4 way masters (SID=001 to 004)
configured. (my suffix is empty in slapd.conf)
>
> The data can be synced initially. I add records in 1 server and all the other 3
servers will have the new record added. However, I found that after running for some
time, one server will have corrupted contextCSN in SID=001.
>
> dn:
> contextCSN:: sCttCIio0wAxNTQzMTMuMDQ1Mjk3WiMwMDAwMDAjMDAyIzAwMDAwMA==
> contextCSN: 20081107061013.853051Z#000000#001#000000
> contextCSN: 20081107073602.911356Z#000000#003#000000
> contextCSN: 20081107061028.825773Z#000000#004#000000
>
> The contextCSN for SID=002 in server 1 is corrupted. So, whenever there is an
update in SID=002 server, the SID=001 server will never get the update,
> however, when there is update in SID=003 or SID=004 server, the records will get
updated in SID=001.
>
> We have a background cron job in each server running at 1 minutes interval to
retrieve the records and set some user defined attributes if it meet some certain
criteria.
>
> What's the cause to this corruption ? Is there any way to recover the
corrupted contextCSN by command or script without rebuild the data ?
Looks similar to <http://www.openldap.org/its?findid=5661>;. Can you
post your configuration? Also, can you try re24 code from the CVS (or
wait until 2.4.13 is out)?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
_________________________________________________________________
下載 Windows Live Messenger 8.5 搶鮮版，多元溝通、盡情分享，和即時傳訊好友線上同樂！— 立即下載
http://get.live.com/zh-cht-tw/betas/messenger_betas
6:08 p.m.
Hi,
I can simulate the problem, since I have a cron job running at every 1 minute to execute
query to the LDAP records, e.g. if the password is nearly expired, I will update a
user-defined value. Since 4 servers will see that record will expire and set the record
simultaneously at the same time, what will happen to this case ? It seems that it will
corrupt the contextCSN.
The reason to have this cron job running so frequently is that I want to check the
pwdAccountLockedTime, if this attribute is present, I will update a user-defined value and
this will synchronize to other servers. My question is, when a user is locked in one
server (the pwdAccountLockedTime attribute exists), why the LDAP will not sync this
attribute to other servers ??? Is this spec. or program bug ? I need to manually update
a user-defined attrbiute, then, everything will be in synced...
Thanks
Date: Tue, 11 Nov 2008 12:16:39 +0100
From: ando(a)sys-net.it
To: badguy9588(a)hotmail.com
CC: openldap-technical(a)openldap.org
Subject: Re:
Bad Guy wrote:
> Dear all,
>
> I am running the openldap 2.4.11 with 4 way masters (SID=001 to 004)
configured. (my suffix is empty in slapd.conf)
>
> The data can be synced initially. I add records in 1 server and all the other 3
servers will have the new record added. However, I found that after running for some
time, one server will have corrupted contextCSN in SID=001.
>
> dn:
> contextCSN:: sCttCIio0wAxNTQzMTMuMDQ1Mjk3WiMwMDAwMDAjMDAyIzAwMDAwMA==
> contextCSN: 20081107061013.853051Z#000000#001#000000
> contextCSN: 20081107073602.911356Z#000000#003#000000
> contextCSN: 20081107061028.825773Z#000000#004#000000
>
> The contextCSN for SID=002 in server 1 is corrupted. So, whenever there is an
update in SID=002 server, the SID=001 server will never get the update,
> however, when there is update in SID=003 or SID=004 server, the records will get
updated in SID=001.
>
> We have a background cron job in each server running at 1 minutes interval to
retrieve the records and set some user defined attributes if it meet some certain
criteria.
>
> What's the cause to this corruption ? Is there any way to recover the
corrupted contextCSN by command or script without rebuild the data ?
Looks similar to <http://www.openldap.org/its?findid=5661>;. Can you
post your configuration? Also, can you try re24 code from the CVS (or
wait until 2.4.13 is out)?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
_________________________________________________________________
5 GB 超大容量 、創新便捷、安全防護垃圾郵件和病毒 — 立即升級 Windows Live Hotmail
http://mail.live.com
5322
days inactive
5324
days old
openldap-technical@openldap.org
4 comments
3 participants
participants (3)
-
Bad Guy -
Dieter Kluenter -
Pierangelo Masarati