Hi,
I'm relatively new to OpenLDAP and am trying to set up a slave server. I figured the easiest way would be to use the anonymous user to perform the synchronization given that my master allows for full anonymous reads: access to * by self write by users read by anonymous read
I have tried to specify the following in my slave slapd.conf: syncrepl rid=8 provider=ldap://snoopy.domain.com:389 type=refreshAndPersist retry="60 +" searchbase="dc=domain,dc=com" schemachecking=off bindmethod=simple
However, my slave seems to be unable to connect properly to the master. It seems to be trying to write something, and am not quite sure what. My master has the following log: Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 fd=72 ACCEPT from IP=10.1.1.8:39558 (IP=0.0.0.0:389) Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=0 BIND dn="" method=128 Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=0 RESULT tag=97 err=0 text= Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=1 SRCH base="dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=1 SRCH attr=* + Nov 9 16:37:52 snoopy slapd[1481]: send_search_entry: conn 6270 ber write failed. Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 fd=72 closed (connection lost on write) My slave logs display the following: Nov 9 16:45:36 spike slapd[32415]: do_syncrep2: rid 008got search entry without control Nov 9 16:45:36 spike slapd[32415]: do_syncrepl: rid 008 retrying
I thought it might have something to do with the type (in that refreshAndPersist may require some form of write privileges), so I switched to type refreshOnly, however, it made no difference. My log outputs remain the same.
Can anyone steer me in the correct direction?
Thanks,
Eric
_________________________________________________________________ Windows Live: Keep your friends up to date with what you do online. http://go.microsoft.com/?linkid=9691815
On 10/11/2009 17:40, Eric B. wrote:
Hi,
I'm relatively new to OpenLDAP and am trying to set up a slave server. I figured the easiest way would be to use the anonymous user to perform the synchronization given that my master allows for full anonymous reads: access to * by self write by users read by anonymous read
I have tried to specify the following in my slave slapd.conf: syncrepl rid=8 provider=ldap://snoopy.domain.com:389 type=refreshAndPersist retry="60 +" searchbase="dc=domain,dc=com" schemachecking=off bindmethod=simple
However, my slave seems to be unable to connect properly to the master. It seems to be trying to write something, and am not quite sure what. My master has the following log: Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 fd=72 ACCEPT from IP=10.1.1.8:39558 (IP=0.0.0.0:389) Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=0 BIND dn="" method=128 Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=0 RESULT tag=97 err=0 text= Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=1 SRCH base="dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=1 SRCH attr=* + Nov 9 16:37:52 snoopy slapd[1481]: send_search_entry: conn 6270 ber write failed. Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 fd=72 closed (connection lost on write) My slave logs display the following: Nov 9 16:45:36 spike slapd[32415]: do_syncrep2: rid 008got search entry without control Nov 9 16:45:36 spike slapd[32415]: do_syncrepl: rid 008 retrying
I thought it might have something to do with the type (in that refreshAndPersist may require some form of write privileges), so I switched to type refreshOnly, however, it made no difference. My log outputs remain the same.
Can anyone steer me in the correct direction?
Hi Eric,
The message on your slave "got search entry without control" would indicate that your master doesn't have the syncprov overlay (which implements the control used by syncrepl).
Try adding "overlay syncprov" in your database declaration on the master.
Hope this helps, Jonathan
On Tuesday, 10 November 2009 17:40:21 Eric B. wrote:
Hi,
I'm relatively new to OpenLDAP and am trying to set up a slave server. I figured the easiest way would be to use the anonymous user to perform the synchronization given that my master allows for full anonymous reads:
We hope you're aware of the risks in the usual trade-off.
access to * by self write by users read by anonymous read
But, can an anonymous search retrieve all the entries (see 'timelimit' and 'sizelimit' options).
Secondly, did you configure your master for syncrepl ? Specifically, has the database holding dc=domain,dc=com got the syncrepl overlay loaded (and you should also index the attributes used for replication state, see the documentation ...).
I have tried to specify the following in my slave slapd.conf: syncrepl rid=8 provider=ldap://snoopy.domain.com:389 type=refreshAndPersist retry="60 +" searchbase="dc=domain,dc=com" schemachecking=off bindmethod=simple
However, my slave seems to be unable to connect properly to the master.
It connects just fine, and initiates a search, however the search doesn't complete.
It seems to be trying to write something, and am not quite sure what. My master has the following log: Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 fd=72 ACCEPT from IP=10.1.1.8:39558 (IP=0.0.0.0:389) Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=0 BIND dn="" method=128 Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=0 RESULT tag=97 err=0 text= Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=1 SRCH base="dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)" Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 op=1 SRCH attr=* + Nov 9 16:37:52 snoopy slapd[1481]: send_search_entry: conn 6270 ber write failed. Nov 9 16:37:52 snoopy slapd[1481]: conn=6270 fd=72 closed (connection lost on write) My slave logs display the following: Nov 9 16:45:36 spike slapd[32415]: do_syncrep2: rid 008got search entry without control
Either it didn't get all the entries (and thus not the control which would follow) when doing the initial sync - fix the limits, or it got all the entries but no control - ensure the overlay is active on the producer.
Regards, Buchan
openldap-software@openldap.org
-
Buchan Milne -
Eric B. -
Jonathan Clarke