I do LDAP search operation with filter (&(objectClass=idnsZone)(idnsSecInlineSigning=TRUE)) and SyncRepl control requesting refresh&persist.
In refresh phase, the SyncRepl plugin correctly generates message searchResEntry for all objects matching my filter.
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.
In that case openldap-servers-2.4.39-2.fc20.x86_64 generates LDAPMessage searchResEntry containing syncState control with state: delete (3).
state: delete (3)
389-ds-base-220.127.116.11-1.fc20.x86_64 generates nothing. I believe it is a bug.
This is not critical for now, I can use workaround in my client.
tcpdump from 389-ds-base-18.104.22.168-1.fc20.x86_64
tcpdump from openldap-servers-2.4.39-2.fc20.x86_64
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
$ git merge ticket47805
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)
d5c6461..fc8def6 master -> master
Metadata Update from @lkrispen:
- Issue assigned to lkrispen
- Issue set to the milestone: 1.3.3 - 6/14 (June)
to comment on this ticket.