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/
Hello,
Bad Guy badguy9588@hotmail.com writes:
Dear all,
I am running the openldap 2.4.11 with 4 way masters (SID=001 to
- 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
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@sys-net.it -----------------------------------
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@sys-net.it To: badguy9588@hotmail.com CC: openldap-technical@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@sys-net.it
_________________________________________________________________ 下載 Windows Live Messenger 8.5 搶鮮版,多元溝通、盡情分享,和即時傳訊好友線上同樂!— 立即下載 http://get.live.com/zh-cht-tw/betas/messenger_betas
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@sys-net.it To: badguy9588@hotmail.com CC: openldap-technical@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@sys-net.it
_________________________________________________________________ 5 GB 超大容量 、創新便捷、安全防護垃圾郵件和病毒 — 立即升級 Windows Live Hotmail http://mail.live.com
openldap-technical@openldap.org