Problem
On UCS 5.2-6, Backup Directory Nodes may repeatedly log the following error for the separate cn=internal Syncrepl database:
do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
The regular UCS LDAP replication check can still report successful replication because cn=internal is replicated separately.
Investigation
Compare the contextCSN on the Primary and an affected Backup Directory Node:
univention-ldapsearch -LLL -b cn=internal -s base '(objectClass=*)' contextCSN
slapcat -b cn=internal | grep '^contextCSN:'
Also inspect the objects and their entryCSN values:
univention-ldapsearch -LLL -b cn=internal '(objectClass=*)' dn entryUUID entryCSN contextCSN
The affected state is characterized by a Backup holding a newer contextCSN than the Primary.
A representative affected Primary showed:
dn: cn=internal
contextCSN: 20240307145910.690288Z#000000#000#000000
dn: cn=recyclebin,cn=internal
entryCSN: 20260401123642.321317Z#000000#000#000000
while the Backups had:
contextCSN: 20260401123642.321317Z#000000#000#000000
Root Cause
The provider has a stale persisted contextCSN for cn=internal while the consumers already know a newer synchronization state.
This state was reproduced by performing a single LDAP write below cn=internal and terminating slapd uncleanly before the updated contextCSN was persisted. The LDAP object itself remained in MDB, while after the next start the Primary used the older persisted contextCSN.
On some systems, the creation of cn=recyclebin,cn=internal is a possible trigger because the UCS upgrade performs this as a single write. The exact preceding unclean slapd termination may not be verifiable retrospectively on every affected system.
Solution
The following workaround was verified on an affected production system. It performs two temporary writes to cn=internal, separated by more than one minute, so the updated contextCSN is persisted.
Run on the Primary:
ldapmodify -x -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret <<'EOF'
dn: cn=internal
changetype: modify
add: description
description: contextCSN-repair
EOF
sleep 65
ldapmodify -x -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret <<'EOF'
dn: cn=internal
changetype: modify
delete: description
description: contextCSN-repair
EOF
Verify on the Primary:
univention-ldapsearch -LLL -b cn=internal -s base '(objectClass=*)' contextCSN
slapcat -b cn=internal | grep '^contextCSN:'
Both commands should return the same contextCSN.
Then verify the same on each Backup Directory Node:
univention-ldapsearch -LLL -b cn=internal -s base '(objectClass=*)' contextCSN
slapcat -b cn=internal | grep '^contextCSN:'
The Backups should automatically synchronize to the new value. The recurring
LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
messages for rid=001 should stop without resetting or rejoining the Backup Directory Nodes.