389 doesn't seem to handle replica removal very well. The removed
replica remains in the RUV element on all other servers. The
http://port389.org/wiki/Howto:CLEANRUV task exists for this purpose, but
you have to run it on all masters simultaneously, or the removed replica
will show up again, replicated from another master that still has the
RUV element in it. Furthermore, it may not be possible to CLEANRUV if
the master is down for some reason.
In the short term, we need to identify exactly what happens when a
replica is deleted - what gets replicated, how the RUV is handled on the
supplier and consumer, what changelog db interactions there are, what
the effects on replication are, and how to recover from this situation.
In the long term, we need to make replication much more resilient and
robust despite replica removal.
One solution is to somehow "mark" the RUV element e.g. use a port number
of 0 or some other "magic" value, or use a special max CSN. The goal
here is to do something that won't break older replicas - users must be
able to have a mixed old and new replication topology - solutions that
begin with "upgrade all servers simultaneously" are non-starters.
Longer term, we should investigate if it is possible to "replicate" the
CLEANRUV operation. Or allow explicit operations on the RUV tombstone
entry that could be replicated. We could change the RUV or RUV element
format to add a version field, and add a field that explicitly marks an
RUV element as deleted. We already have code in the replication
supplier to get the "capabilities" of the consumer, we would just need
to extend this, to know if the consumer understands "versioned" RUVs.
1. Not sure is there anyone having the same experience. We export the ldap data from Sun One directory to ldif file and import through the DS389 console. There is no error report and all records imported.
But later we found out the creatorsName and createTimeStamp have not been imported. Do you guys know why?
2. Can't modify those 2 attributes easily. But there is some special keywords for these 2 attributes. "NO-USER-MODIFICATION, USAGE directoryOperation"
Can I just remove those keywords and do the ldapmodify to those 2 attributes manually? I have tried but there will be some strange error reports.
Faculty of Engineering and IT
University of Technology, Sydney
PH: 9514 2374
UTS CRICOS Provider Code: 00099F
DISCLAIMER: This email message and any accompanying attachments may contain confidential information.
If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or
attachments. If you have received this message in error, please notify the sender immediately and delete
this message. Any views expressed in this message are those of the individual sender, except where the
sender expressly, and with authority, states them to be the views of the University of Technology Sydney.
Before opening any attachments, please check them for viruses and defects.
Think. Green. Do.
Please consider the environment before printing this email.
Bug description: To allow replicating unhashed password, an internal
entry contains the key value pair when the entry is newly added or
the password is updated. In that case, deleting the userpassword
attribute leaves the unhashed password in the internal entry.
If you attempt to add a new userpassword, the remaining unhashed
password makes the attempt fail due to LDAP_TYPE_OR_VALUE_EXISTS.
Fix description: This patch cleans up the unhashed password if a
userpassword is deleted and the unhashed password is found in the
internal entry. If it does not exist, the deletion does nothing.
(If the entry is read from the database, the unhashed password
does not exist in the internal entry since it is not stored in