If an attribute is required by the schema any attempt to delete all values will fail without replication or on a single master.
But if the attribute has two values it is possible to simultaneously delete one value on one master and the other value on the other master - the individual operation is allowed as one value remains. After the two masters have replayed their changes to each other bot values have disappeared.
299 slapi_pblock_get(pb, SLAPI_MODIFY_MODS, &lmods);
300 slapi_mods_init_passin(&smods, mods);
301 slapi_mods_add_string (&smods, LDAP_MOD_ADD, ATTR_NSDS5_REPLCONFLICT, "Schema violation");
302 lmods = slapi_mods_get_ldapmods_passout(&smods);
303 slapi_pblock_set(pb, SLAPI_MODIFY_MODS, lmods);
Does this leak lmods? lmods is not freed, and it is overwritten.
good catch, it should have been:
There is a problem with this solution. In fractional replication it might be accepted that on the consumer side entries can violate the schema because required attributes are not replicated.
This is itself problematic for fractional replication between masters, so I am not sure how to procede.
I verified that with the change in comment#8 there is no memory leak. lmods is taken from the pblock, slapimods_add_string it is reallocated an then set back to the pblock. The test was also run with valgrind and didn't show a leak.
After some discussion we cam to the conclusion that fractional replication should not be used to allow schema violations, so it is ok to check the schema for replicated mods.
Is it ok now to commit ?
$git merge ticket601
ldap/servers/slapd/back-ldbm/ldbm_modify.c | 47 +++++++++++++++++++++++++++++++++++++++--------
ldap/servers/slapd/schema.c | 13 +++++++++++--
ldap/servers/slapd/slapi-plugin.h | 10 ++++++++++
3 files changed, 60 insertions(+), 10 deletions(-)
$ git push origin master
Counting objects: 17, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 2.21 KiB, done.
Total 9 (delta 7), reused 0 (delta 0)
36f506d..d9f25b7 master -> master
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1044154
Metadata Update from @lkrispen:
- Issue assigned to lkrispen
- Issue set to the milestone: 1.3.2 - 09/13 (September)
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:
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)
to comment on this ticket.