https://bugzilla.redhat.com/show_bug.cgi?id=669205https://bugzilla.redhat.com/attachment.cgi?id=473957&action=diffhttps://bugzilla.redhat.com/attachment.cgi?id=473957&action=edit
Description:
Introduced backup plugin hooks: SLAPI_PLUGIN_BE_PRE_BACKUP_FN
and SLAPI_PLUGIN_BE_POST_BACKUP_FN to call back cl5WriteRUV and
cl5DeleteRUV, respectively. cl5WriteRUV adds RUVs to changelog
and cl5DeleteRUV reads and deletes RUVs in changelog. The call-
back functions are avaiable only when the process is initialized
as a server, which must have started with a backend normal mode
flag (DBLAYER_NORMAL_MODE) not with other utility modes such as
DBLAYER_ARCHIVE_MODE. With this restriction, db2bak is not
allowed to use to back up the database including changelog db
when the server is up. If launched, the utility fails with this
error message:
[...] - db2archive: pre-backup-plugin failed (1).
[...] - ERROR: Standalone db2bak is not supported \
when a multimaster replication enabled server is coexisting.
Please use db2bak.pl, instead.
As mentioned in the message, db2bak.pl is supposed to be used.
See also:
http://directory.fedoraproject.org/wiki/Move_changelog#Backing_up_Changelog
https://bugzilla.redhat.com/show_bug.cgi?id=624442https://bugzilla.redhat.com/attachment.cgi?id=473440&action=diffhttps://bugzilla.redhat.com/attachment.cgi?id=473440&action=edit
Description: Each replica has an RUV tombstone entry in the
backend db, which keeps nsds50ruv attribute values as follows:
nsds50ruv: {replicageneration}<replica_generation_csn>
nsds50ruv: {replica<rid> ldap://<host>:<port>}<last_modified>
...
When the replica is deleted, the RUV tombstone entry remains
in the db. Then if the replica is added back with the different
replica id<rid-2>, the original nsds50ruv value {replica<rid>
ldap://<host>:<port>} was not updated. This caused the problem
if the counter replica server happened to get the same replica
id<rid> that this server original had.
This patch compares the replica id<rid> in the RUV tombstone
entry with the new id<rid-2>. If they don't match, recreate
the RUV tombstone entry.
https://bugzilla.redhat.com/show_bug.cgi?id=667488https://bugzilla.redhat.com/attachment.cgi?id=472302&action=diffhttps://bugzilla.redhat.com/attachment.cgi?id=472302&action=edit
Description: Special thanks to Orion Poplawski(orion(a)cora.nwra.com)
for his in-depth analysis on the bug. As he figured out, a helper
function add_op_attrs called from the reindex API ldbm_back_ldbm2index
removes the numsubordinates attribute-value pair from entries to
be reindexed, which makes reindexing numsubordinates fail.
The helper function add_op_attrs adds operational attributes parentid,
entryid and entrydn to entries as well as removes numsubordinates
from them before the entries are reindexed/imported. The add and
remove are necessary for the import, but not for the reindex since
these to-be-added operational attributes are already in entries
in the primary database id2entry. And numsubordinates is necessary
when the attribute is reindexed.
This patch updates ldbm_back_ldbm2index (ldif2ldbm.c) not to call
add_op_attrs.