389-ds-base

#49914 'send_entry: Encoding Error' problem in Replication Agreement. Related to missing nsUniqueID?
Closed: wontfix Opened by dkt.

Closed: wontfix
Reopen Issue

Issue Description

I can setup replication on a brand new 389ds to another 389ds instance.
Using the same steps, I cannot configure replication from an server with existing data to another instance.
I notice it reported Encoding Error in the supplier.

On further check on the supplier, there are entries without nsUniqueID. I am not sure if it is related.
Is nsUniqueID necessary for replication? If some of the entries are missing nsUniqueID, how to fix those entries?

[21/Aug/2018:04:17:35.552167033 +0800] - INFO - NSMMReplicationPlugin - repl5_tot_run - Beginning total update of replica "agmt="cn=Replication Agreement cms1 to lab03pm" (lab03pm:389)".
[21/Aug/2018:04:17:35.554313869 +0800] - DEBUG - NSMMReplicationPlugin - agmt="cn=Replication Agreement cms1 to lab03pm" (lab03pm:389): send_entry: Encoding Error
[21/Aug/2018:04:17:35.555645160 +0800] - ERR - NSMMReplicationPlugin - repl5_tot_run - Unable to send the suffix entry "dc=local,dc=nonet" to the consumer.
[21/Aug/2018:04:17:35.561357699 +0800] - DEBUG - NSMMReplicationPlugin - conn_cancel_linger - agmt="cn=Replication Agreement cms1 to lab03pm" (lab03pm:389) - No linger to cancel on the connection
[21/Aug/2018:04:17:35.562229459 +0800] - DEBUG - NSMMReplicationPlugin - close_connection_internal - agmt="cn=Replication Agreement cms1 to lab03pm" (lab03pm:389) - Disconnected from the consumer
[21/Aug/2018:04:17:35.563440699 +0800] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to lab03pm" (lab03pm:389): State: start -> ready_to_acquire_replica
[21/Aug/2018:04:17:35.565591080 +0800] - DEBUG - NSMMReplicationPlugin - repl5_inc_run - agmt="cn=Replication Agreement cms1 to lab03pm" (lab03pm:389): State: ready_to_acquire_replica -> wait_for_changes
[21/Aug/2018:04:17:36.396967846 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561.

At the consumer, the related log:

[21/Aug/2018:04:17:21.515247034 +0800] - DEBUG - _csngen_adjust_local_time - gen state before 5b7b1a270001:1534794279:0:0
[21/Aug/2018:04:17:21.516384556 +0800] - DEBUG - _csngen_adjust_local_time - gen state after 5b7b21d10000:1534796241:0:0
[21/Aug/2018:04:17:21.533796122 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 560.
[21/Aug/2018:04:17:21.535465566 +0800] - DEBUG - NSMMReplicationPlugin - _replica_configure_ruv - No ruv tombstone found for replica dc=local,dc=nonet. Created a new one
[21/Aug/2018:04:17:21.537257719 +0800] - DEBUG - NSMMReplicationPlugin - agmtlist_config_init - Found 0 replication agreements in DIT
[21/Aug/2018:04:17:21.552186711 +0800] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests
[21/Aug/2018:04:17:23.644150922 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561.
[21/Aug/2018:04:17:53.648256374 +0800] - DEBUG - replication - multimaster_mmr_postop - error 0 for oparation 561.

Package Version and Platform

389-ds-base-1.3.7.5-25.el7_5.x86_64 on RHEL 7.5

Have you added/forgotten TLS on the replication agreement? That could cause the encoding error.

Metadata Update from @firstyear:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

Not related to TLS. I used 389 port only for replication.
For the nsUniqueID, I had update the directory server to include it in all the entries.

Metadata Update from @dkt:
- Issue close_status updated to: fixed

I had update the directory server to include nsUniqueID in all the entries and the encoding error problem does not appear.

Sorry, Idon't understand what you did, or how you fixed it. Could you provide more information, so that we can understand this? It would be great for preventing future issues.

Thanks!

Some entries are missing nsUniqueID, I think I had used ldif2db to add the entries directly into DB (without ldapmodify).

So to add back the nsUniqueID:
I export the data as LDIF.
Then I recreate the slapd-instance with no data.
Then I import back the LDIF by ldapmodify.
The nsUniqueID is added for all entries.

@dkt, replication needs nsUniqueID to apply updates. Actually an update does not apply to a entry regarding its DN but its nsUniqueID. If a target entry has no nsUniqueID, a replication agreement can not encode/send the update to the consumer.

I am not sure how you got to the point where some entries had no nsUniqueid. possibly stripping this attribute from a ldif file.

@dkt, if using ldif2db to initialize a replica then make sure the LDIF file has been created from 'db2ldif -r'

nsuniqueID have to be generated by the server (when you ADD an entry), you should not copy/paste those values from entries to another.

Some entries are missing nsUniqueID, I think I had used ldif2db to add the entries directly into DB (without ldapmodify).

confirmed, by checking my command history
because I had use '-g none' when I used ldif2db

@dkt, if using ldif2db to initialize a replica then make sure the LDIF file has been created from 'db2ldif -r'
nsuniqueID have to be generated by the server (when you ADD an entry), you should not copy/paste those values from entries to another.

ok, thanks.

Well, @tbordaz even if the entry doesn't have an nsUniqueID ldif2db should create one....

I think a serious issue we have is that nsUniqueID is an internal component of the server, but it's exposed in a way that makes it seem different. It's quite easy to make mistakes like this I think ... I think it's hard now to fix that, but communication abotu it might help somehow. Maybe in schema description, and with @mmuehlfeldrh help in docs about nsUniqueID? Maybe comments at the header of the db2ldif output? These also could help.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2973

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)
Metadata
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.