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]