Version: 389-ds-base-1.3.2.16-1.fc20.x86_64
I do LDAP search operation with filter (&(objectClass=idnsZone)(idnsSecInlineSigning=TRUE)) and SyncRepl control requesting refresh&persist.
(&(objectClass=idnsZone)(idnsSecInlineSigning=TRUE))
In refresh phase, the SyncRepl plugin correctly generates message searchResEntry for all objects matching my filter.
searchResEntry
The problem arises in persist phase if I change attribute value used in the filter so one of objects in watched sub-tree doesn't match the filter anymore. E.g. I change idnsSecInlineSigning to value FALSE.
persist
idnsSecInlineSigning
FALSE
In that case openldap-servers-2.4.39-2.fc20.x86_64 generates LDAPMessage searchResEntry containing syncState control with state: delete (3).
openldap-servers-2.4.39-2.fc20.x86_64
syncState
state: delete (3)
389-ds-base-1.3.2.16-1.fc20.x86_64 generates nothing. I believe it is a bug.
389-ds-base-1.3.2.16-1.fc20.x86_64
This is not critical for now, I can use workaround in my client.
tcpdump from 389-ds-base-1.3.2.16-1.fc20.x86_64 syncrepl-attribute-change-389-ds-base-1.3.2.16-1.fc20.x86_64.pcap
tcpdump from openldap-servers-2.4.39-2.fc20.x86_64 syncrepl-attribute-change-openldap-servers-2.4.39-2.fc20.x86_64.pcap
looks like its time for a new round of syncrepl fixes
The current implementation of sync repl checks the entry after the mod is applied, after the change is applied it doesn't match the filter and is ignored. It would be correct to check the filter also before the mod is applied to detect cases where an entry moves out of scope. The logic is already applied fro modrdn operations, a fix shouldn#t be difficult
attachment 0001-Ticket-47805-syncrepl-doesn-t-send-notification-when.patch
$ git merge ticket47805 Updating d5c6461..fc8def6 Fast-forward ldap/servers/plugins/sync/sync_persist.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) $ git push origin master Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1016 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git d5c6461..fc8def6 master -> master
Metadata Update from @lkrispen: - Issue assigned to lkrispen - Issue set to the milestone: 1.3.3 - 6/14 (June)
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/1136
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.