Re: generated attributes and syncrepl
Emmanuel Dreyfus <[email protected]> Sun, 31 May 2026 15:28:31 +0000
| Newsgroups | gmane.network.openldap.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, May 30, 2026 at 03:42:33PM +0000, Emmanuel Dreyfus wrote:
> I ran with -d sync and I now wonder if the problem happens on the replica.
Running tcpdump, I can check the two changes flowing from master to
replica. The entires sent are identical, the only thing that changes
is the csn at the end of the packet.
0x03c0: b597 4904 3472 6964 3d32 3137 2c63 736e ..I.4rid=217,csn
0x03d0: 3d32 3032 3630 3533 3131 3434 3230 382e =20260531144208.
- 0x03e0: 3736 3631 3935 5a23 3030 3030 3030 2330 766195Z#000000#0
+ 0x03e0: 3738 3735 3730 5a23 3030 3030 3030 2330 787570Z#000000#0
0x03f0: 3030 2330 3030 3030 30 00#000000
Hence the client behavior is fine, and master's behavior is the suspect
again.
plain syncrepl and delta-syncrepl produce the same result, but delta-syncrepl
lets me inspect the accesslog: the second modification is not recorded.
I now wonder if it is really legit to create a new modify operation in a
search callback using this method:
Operation op2 = *op;
op2.o_dn = op->o_bd->be_rootdn;
op2.o_ndn = op->o_bd->be_rootndn;
op2.o_tag = LDAP_REQ_MODIFY;
op2.o_time = slap_get_time();
(...)
It is used in several overlays, but perhaps only for not replicated data?
--
Emmanuel Dreyfus
[email protected]