Hi,
I was looking for a solution to monitor syncrepl between two server and find that I need to compare contextCSN on the two server. The problem is that entryCSN doesn't exist on my slave server :
On the master (don't know openldap ver): # ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base ContextCSN give me : # extended LDIF # # LDAPv3 # base <ou=people,dc=compagnie,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ContextCSN #
# People, compagnie.com dn: ou=people,dc=compagnie,dc=com contextCSN: 20080305145635Z#000000#00#000000
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
On the slave (openldap 2.4.8): # ldapsearch -x -h slave -b "ou=people,dc=compagnie,dc=com" -s base ContextCSN give me : # extended LDIF # # LDAPv3 # base <ou=people,dc=compagnie,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ContextCSN #
# search result search: 2 result: 0 Success
# numResponses: 1
At startup on the slave, I have this log :
bdb_modify: ou=People,dc=compagnie,dc=com bdb_dn2entry("ou=People,dc=compagnie,dc=com") bdb_modify_internal: 0x00000001: ou=People,dc=compagnie,dc=com <= acl_access_allowed: granted to database root bdb_modify_internal: delete contextCSN bdb_modify_internal: 16 modify/delete: contextCSN: no such value bdb_modify: modify failed (16) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=16 matched="" text="modify/delete: contextCSN: no such value" null_callback : error code 0x10 syncrepl_updateCookie: rid=013 be_modify failed (16) ldap_msgfree ldap_result ld 0x832ca48 msgid 2 wait4msg ld 0x832ca48 msgid 2 (timeout 0 usec) wait4msg continue ld 0x832ca48 msgid 2 all 0 ** ld 0x832ca48 Connections: * host: master port: 389 (default) refcnt: 2 status: Connected last used: Wed Mar 5 14:53:45 2008
I don't understand what append ...
Thanks for your help
Julien
Julien Garnier wrote:
Hi,
I was looking for a solution to monitor syncrepl between two server and find that I need to compare contextCSN on the two server. The problem is that entryCSN doesn't exist on my slave server :
On the master (don't know openldap ver): # ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base
Try: ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base -LLL '' +
WBR
Dmitriy Kirhlarov a écrit :
Julien Garnier wrote:
Hi,
I was looking for a solution to monitor syncrepl between two server and find that I need to compare contextCSN on the two server. The problem is that entryCSN doesn't exist on my slave server :
On the master (don't know openldap ver): # ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base
Try: ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base -LLL '' +
WBR
No, it's the same, nothings return
thanks
Julien
--On Wednesday, March 05, 2008 8:28 PM +0100 Julien Garnier julien.garnier@dr13.cnrs.fr wrote:
Dmitriy Kirhlarov a écrit :
Julien Garnier wrote:
Hi,
I was looking for a solution to monitor syncrepl between two server and find that I need to compare contextCSN on the two server. The problem is that entryCSN doesn't exist on my slave server :
On the master (don't know openldap ver): # ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base
Try: ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base -LLL '' +
WBR
No, it's the same, nothings return
Did you load the syncprov overlay on the replica?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Julien Garnier wrote:
Dmitriy Kirhlarov a écrit :
Julien Garnier wrote:
Hi,
I was looking for a solution to monitor syncrepl between two server and find that I need to compare contextCSN on the two server. The problem is that entryCSN doesn't exist on my slave server :
On the master (don't know openldap ver): # ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base
Try: ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base -LLL '' +
No, it's the same, nothings return
contextCSN stored in root object. ldapsearch -x -h master -b "dc=com" -s base -LLL '' +
WBR. Dmitriy
Dmitriy Kirhlarov a écrit :
Julien Garnier wrote:
Dmitriy Kirhlarov a écrit :
Julien Garnier wrote:
Hi,
I was looking for a solution to monitor syncrepl between two server and find that I need to compare contextCSN on the two server. The problem is that entryCSN doesn't exist on my slave server :
On the master (don't know openldap ver): # ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base
Try: ldapsearch -x -h master -b "ou=people,dc=compagnie,dc=com" -s base -LLL '' +
No, it's the same, nothings return
contextCSN stored in root object. ldapsearch -x -h master -b "dc=com" -s base -LLL '' +
WBR. Dmitriy
My root object is "ou=people,dc=compagine,dc=fr"
my slapd.conf :
################################################### allow bind_v2
include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/cnrs.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 1
modulepath /usr/lib/ldap moduleload back_bdb
sizelimit 50000
tool-threads 2
backend bdb checkpoint 512 30
database bdb
suffix "ou=People,dc=compagnie,dc=com" rootdn "cn=admin,ou=People,dc=compagnie,dc=com" rootpw "secret"
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500
index objectClass eq index ou,cn,mail,surname,givenname,departmentNumber eq,pres,sub index entryCSN,entryUUID,contextCSN eq,pres
lastmod on
#id du client (numero DR) syncrepl rid=013 provider=ldap://master:389 searchbase="ou=People,dc=compagnie,dc=com" type=refreshAndPersist interval=00:00:15:00 scop=sub filter=(cnrsDelegation=DR13*) schemachecking=on updatedn="cn=admin,ou=people,dc=compagnie,dc=com" bindmethod=simple binddn="cn=sync-dr13,ou=people,dc=compagnie,dc=com" credentials="secret"
access to attrs=userPassword,shadowLastChange by dn="cn=admin,ou=People,dc=compagnie,dc=com" write by anonymous auth by self write by * none
access to dn.base="" by * read
access to * by dn="cn=admin,ou=People,dc=compagnie,dc=com" write by * read #####################################################
I just reinstall all my slave server and resynchronize all the database and it's the same : It's OK when I search the master server but doesn't work for the slave server.
What I've done is : reinstall linux install openldap from aptitude (slapd 2.3.30 (Mar 9 2007 05:43:02)) copy paste my config file to /etc/ldap/slapd.conf starting server
and nothing else. search on base doesn't retrn any results :
Thanks for Your help
Julien
On Thursday 06 March 2008 16:44:21 Julien Garnier wrote:
I just reinstall all my slave server and resynchronize all the database and it's the same : It's OK when I search the master server but doesn't work for the slave server.
What I've done is : reinstall linux install openldap from aptitude (slapd 2.3.30 (Mar 9 2007 05:43:02)) copy paste my config file to /etc/ldap/slapd.conf starting server
and nothing else. search on base doesn't retrn any results :
Does cn=sync-dr13,ou=people,dc=compagnie,dc=com have unlimited (size/time) access to your provider? Have you tested manually (e.g. with 'ldapsearch -x -H ldap://master:389 -b ou=People,dc=compagnie,dc=com -D cn=sync-dr13,ou=people,dc=compagnie,dc=com -w secret "(cnrsDelegation=DR13*)"') that you can receive all the entries? Or, have you confirmed from the logs on the consumer that the provider search did not return a result=4?
If your consumer's binddn can't retrieve all the entries, the initial sync will keep failing, thus the contextCSN will not be added on the consumer.
Regards, Buchan
Buchan Milne a écrit :
On Thursday 06 March 2008 16:44:21 Julien Garnier wrote:
I just reinstall all my slave server and resynchronize all the database and it's the same : It's OK when I search the master server but doesn't work for the slave server.
What I've done is : reinstall linux install openldap from aptitude (slapd 2.3.30 (Mar 9 2007 05:43:02)) copy paste my config file to /etc/ldap/slapd.conf starting server
and nothing else. search on base doesn't retrn any results :
Does cn=sync-dr13,ou=people,dc=compagnie,dc=com have unlimited (size/time) access to your provider? Have you tested manually (e.g. with 'ldapsearch -x -H ldap://master:389 -b ou=People,dc=compagnie,dc=com -D cn=sync-dr13,ou=people,dc=compagnie,dc=com -w secret "(cnrsDelegation=DR13*)"') that you can receive all the entries? Or, have you confirmed from the logs on the consumer that the provider search did not return a result=4?
I think there is no problem with master server search is good with cn=sync and as anonymous: # ldapsearch -x -h master -b "ou=People,dc=compagnie,dc=com" -D "cn=sync-DR13,ou=People,dc=compagnie,dc=com" -s base + -LLL -W Enter LDAP Password:
dn: ou=People,dc=compagnie,dc=com structuralObjectClass: organizationalUnit entryUUID: 187a2858-af67-102b-9acf-e50839f4c3d0 creatorsName: cn=ldapmaster,ou=People,dc=compagnie,dc=com modifiersName: cn=ldapmaster,ou=People,dc=compagnie,dc=com createTimestamp: 20070615083520Z modifyTimestamp: 20070615083520Z entryCSN: 20070615083520Z#000001#00#000000 contextCSN: 20080307004124Z#000000#00#000000 entryDN: ou=People,dc=compagnie,dc=com subschemaSubentry: cn=Subschema hasSubordinates: TRUE
If your consumer's binddn can't retrieve all the entries, the initial sync will keep failing, thus the contextCSN will not be added on the consumer Regards, Buchan
Thanks Julien
On Friday 07 March 2008 10:28:53 Julien Garnier wrote:
Buchan Milne a écrit :
On Thursday 06 March 2008 16:44:21 Julien Garnier wrote:
I just reinstall all my slave server and resynchronize all the database and it's the same : It's OK when I search the master server but doesn't work for the slave server.
What I've done is : reinstall linux install openldap from aptitude (slapd 2.3.30 (Mar 9 2007 05:43:02)) copy paste my config file to /etc/ldap/slapd.conf starting server
and nothing else. search on base doesn't retrn any results :
Does cn=sync-dr13,ou=people,dc=compagnie,dc=com have unlimited (size/time) access to your provider? Have you tested manually (e.g. with 'ldapsearch -x -H ldap://master:389 -b ou=People,dc=compagnie,dc=com -D cn=sync-dr13,ou=people,dc=compagnie,dc=com -w secret "(cnrsDelegation=DR13*)"') that you can receive all the entries? Or, have you confirmed from the logs on the consumer that the provider search did not return a result=4?
I think there is no problem with master server search is good with cn=sync and as anonymous:
Since by default only rootdn has unlimited access, and since you did not include your provider's slapd.conf (or any evidence that you have ensured that the consumer's binddn has unlimited access), and since you did not include the result code in your output, and since you did not state how many entries you have (as the default sizelimit is 500) I would still suspect this.
But, if you are sure this is not the issue, you'll have to look for another cause (even though the consumer not being able to retrieve all the entries is the most likely cause of the contextCSN not being updated on an initial sync).
Regards, Buchan
Buchan Milne a écrit :
Since by default only rootdn has unlimited access, and since you did not include your provider's slapd.conf (or any evidence that you have ensured that the consumer's binddn has unlimited access), and since you did not include the result code in your output, and since you did not state how many entries you have (as the default sizelimit is 500) I would still suspect this.
As I said in my first message, I have no acces to the slapd.conf of the provider. I think I have unlimited read access, my dn (cn=sync-dr13) have no limited result entries : as anonymous, ldapsearch on provider return 50 entires as cn=sync-dr13, return me 109280 entries
I only synchronize (cnrsdelegation=dr13*). A search on the provider with this filter return 4845 Same search on the consumer give me 4845 results so I have all the entries
But, if you are sure this is not the issue, you'll have to look for another cause (even though the consumer not being able to retrieve all the entries is the most likely cause of the contextCSN not being updated on an initial sync).
I ask the provider server to give me the ACL for my dn ...
Regards, Bucha
Thanks Julien
Am Donnerstag, 6. März 2008 15:44:21 schrieb Julien Garnier:
Dmitriy Kirhlarov a écrit :
Julien Garnier wrote:
Dmitriy Kirhlarov a écrit :
Julien Garnier wrote:
Hi,
[...]
#id du client (numero DR) syncrepl rid=013 provider=ldap://master:389 searchbase="ou=People,dc=compagnie,dc=com" type=refreshAndPersist interval=00:00:15:00 scop=sub filter=(cnrsDelegation=DR13*) schemachecking=on updatedn="cn=admin,ou=people,dc=compagnie,dc=com" bindmethod=simple binddn="cn=sync-dr13,ou=people,dc=compagnie,dc=com" credentials="secret"
updatedn is not a valid configuration parameter and it seems that cn=sync-dr13 has no read access to the provider.
-Dieter
Hi,
After trying a lots of configurations, I find the solution !
In my syncrepl configuration I was filtering on (cnrsdelagation=DR13*)
Of course openldap was not able to get entries for "ou=people,dc=compagnise,dc=com" because it is an organizationalUnit object!
I just modify the filter in syncrepl config : (|(cnrsdelagation=DR13*) (objectclass=organizationalUnit)) and now it works fine !
Thanks for everybody !
openldap-software@openldap.org
-
Buchan Milne -
Dieter Klünter -
Dmitriy Kirhlarov -
Julien Garnier -
Quanah Gibson-Mount