About implementing syncrepl (rfc-4533) consumer

[t2y]

I am new to OpenLDAP. Recently, I started developing a module connected with the OpenLDAP server using go-ldap. Go-ldap really helps me. Thanks a lot.

I'm interested in syncrepl for LDAP Sync Replication. It is my understanding that syncrepl has 2 components, provider and consumer. I think the provider is an OpenLDAP server (maybe slapd). To use syncrepl in Go, I have to implement a consumer module. Does go-ldap have a plan to provide some functions related to syncrepl? I could not find resources about it.

Reference

• Return search results into channel #135
• https://www.rfc-editor.org/rfc/rfc4533.html
• https://www.openldap.org/doc/admin25/replication.html

[vetinari]

This requires #319 to be merged first.

[t2y]

@vetinari #440 (provides #319 feature) was merged. To implement syncrepl consumer, would you happen to have a plan or design? I am new to LDAP protocol, so any advice is welcome.

[t2y]

I'm investigating. To provide syncrepl feature, I have to implement Controls as below.

1.3.6.1.4.1.4203.1.9.1.1	LDAP Content Synchronization Request Control	RFC 4533
1.3.6.1.4.1.4203.1.9.1.2	LDAP Content Synchronization State Control	RFC 4533
1.3.6.1.4.1.4203.1.9.1.3	LDAP Content Synchronization Done Control	RFC 4533
1.3.6.1.4.1.4203.1.9.1.4	LDAP Content Synchronization Info Intermediate Response	RFC 4533

https://ldap.com/ldap-oid-reference-guide/

To test a syncrepl consumer, the slapd server needs the below overlay configuration.

overlay syncprov

[t2y]

#80 implemented Persistent Search, but this feature is different from syncrepl provided by OpenLDAP server (slapd).

2.16.840.1.113730.3.4.3	Persistent Search Request Control	          draft-ietf-ldapext-psearch
2.16.840.1.113730.3.4.7	Entry Change Notification Response Control	  draft-ietf-ldapext-psearch

[t2y]

I understood the rough design. To provide the syncrepl feature, I have to implement Control structs to handle the above OID packets. Control structs encode/decode the packet from OpenLDAP server.

[t2y]

I understood what the control is for.

• Sync Request Control is used for client requests
• Sync State Control is used for server responses
  • request with mode=RefreshAndPersist, then get a response with ApplicationSearchResultEntry (4)
• Sync Done Control is used for server responses
  • request with mode=RefreshOnly, then get a response with ApplicationSearchResultDone (5)
• Sync Info Control is used for server responses
  • request with mode=RefreshAndPersist, then get a response with ApplicationIntermediateResponse (25)

I'm considering declaring another Response struct instead of reusing searchResponse because the generic search function differs from the persistent search provided by syncrepl (rfc-4533).

[t2y]

I implemented it. Thanks for consulting with me.