Bug 46728 - Add syncprov module to slapd.conf to serve to syncrepl consumers
Add syncprov module to slapd.conf to serve to syncrepl consumers
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.3
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-22 13:10 CET by Valentin Heidelberger
Modified: 2021-05-14 16:34 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Valentin Heidelberger univentionstaff 2018-03-22 13:10:30 CET
It would be nice to have syncrepl enabled by default in slapd.conf. I'm currently in contact with a customer who wants to connect a service, that uses syncrepl to replicate user objects, to our LDAP.

Slapd throws the following error when that service tries to replicate:  slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1

I've put the following config into slapd.conf to activate syncprov:
'''
moduleload	syncprov.so

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
'''

It works perfectly afterwards

See also https://www.openldap.org/doc/admin24/replication.html 
Chapter 18.3 "Configuring the different replication types"
Comment 1 Arvid Requate univentionstaff 2018-03-22 19:21:54 CET
FYI: Adding this to the slapd.conf on the master should be simple and without side effects (LDAP ACLs apply). Adding it to all other domaincontrollers too would require us to assign to each server a so called "rid" (syncrepl-terminology), which should be a unique number in the range 0-999. At least that's required if those servers are supposed to communicate with each other via syncrepl at some point in the future. In Valentins' test the Master automatically defaulted to rid=000.
Comment 2 Ingo Steuwer univentionstaff 2021-05-14 15:41:55 CEST
This issue has been filed against UCS 4.3.

UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.