0c194eb Ticket #47362 - ipa upgrade selinuxusermap data not replicating

Authored and Committed by rmeggins 10 years ago
    Ticket #47362 - ipa upgrade selinuxusermap data not replicating
    
    https://fedorahosted.org/389/ticket/47362
    Reviewed by: nhosoi (Thanks!)
    Branch: 389-ds-base-1.2.11
    Fix Description: When nsslapd-port is set to 0, this causes the
    replica purl to be "ldap://hostname:0".  At startup, the MMR code looks to
    see if this replica purl is in the RUV, by doing a string comparison of this
    purl with the ruv replica purl.  If it is not there, the MMR code wipes out
    this ruv element.  Later the code in replica_check_for_data_reload() uses
    this RUV to see if it needs to reinit the changelog.  Since the RUV doesn't
    match the changelog RUV any more, the changelog is erased, which erases
    any changes that were made in the meantime.  The missing RUV element causes
    the supplier to attempt to send over changes which may already exist on the
    consumer.  If one of these is an ADD, the urp code will correctly flag this
    as an attempt to add an entry that already exists, and will turn this into
    a replConflict entry.  A subsequent attempt to replicate the same ADD will
    cause an error in the urp code which will cause it to return err=53.
    Replication will then become stuck on this update - it will keep trying to
    send it over and over again, and will not be able to proceed.
    The only workaround is a replica reinit of the replica, to get the database
    RUV and changelog in a consistent state.
    I've also added some additional RUV debugging when using the REPL log level.
    Platforms tested: RHEL6 x86_64
    Flag Day: no
    Doc impact: no