Bug 1387369

Summary: clean-ruv doesn't work with unmanaged ruv
Product: [Fedora] Fedora Reporter: Lucas Diedrich <lucas.diedrich>
Component: freeipaAssignee: IPA Maintainers <ipa-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: abokovoy, ipa-maint, jcholast, jhrozek, lucas.diedrich, mkosek, pvoborni, rcritten, ssorce, tbordaz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-31 09:37:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Lucas Diedrich 2016-10-20 17:35:23 UTC 
Description of problem: Using clean-ruv doesn't work when the ruv is "broken".

Version-Release number of selected component (if applicable): Freeipa 4.2.4.

How reproducible: When we've an 'unable to decode' ruv it doesn't remove it. The only solution for this is using an direct clean-ruv by ldapmodify (taken from: https://www.redhat.com/archives/freeipa-users/2015-May/msg00067.html). This happened to me twice.

Steps to Reproduce:
1. ipa-replica-manage list-ruv
Directory Manager password: 

unable to decode: {replica 3} 56dee4fc000300030000 56dee4fc000300030000
ipa2.domain:389: 8
ipa4.domain:389: 6
ipa3.internaldomain:389: 5
ipa.domain:389: 4

2.ipa-replica-manage clean-ruv 3
Directory Manager password: 

unable to decode: {replica 3} 56dee4fc000300030000 56dee4fc000300030000
Replica ID 3 not found

Actual results: Replica ID 3 not found


Expected results: Replica ID 3 removed

Additional info: I can remove using this ldap-modify:

# ldapmodify -D "cn=directory manager" -W -a
Enter LDAP Password: 
dn: cn=clean 3, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: dc=domain
replica-id: 3
cn: clean 3

adding new entry "cn=clean 3, cn=cleanallruv, cn=tasks, cn=config"

Success!
Comment 2 Petr Vobornik 2016-10-24 14:49:30 UTC 
In general, what is output of:

$ rpm -q freeipa-server 389-ds-base


Could you update to latest 389-ds-base? Clean the RUVs manually, using LDIF as suggested in the freeipa-users thread and check if it solves your situation?
Comment 3 Lucas Diedrich 2016-10-24 15:23:28 UTC 
The return of the command:

[root@ipa ~]# rpm -q freeipa-server 389-ds-base
freeipa-server-4.2.4-1.fc23.x86_64
389-ds-base-1.3.4.9-1.fc23.x86_64


Cleaning the RUVs manually using the ldiff resolves the situation.

This problem happened to me once when i was using Fedora 21 too. The upgrade to the Fedora 24 is planned for this week, i could use its version of 389-ds.

The problem is that i can't figure how to replicate the problem to get the "unable to decode" message.
Comment 4 Petr Vobornik 2016-10-31 09:37:22 UTC 
The cause of "unable to decode" is fixed in later version of 389ds. With FreeIPA 4.4 and topology management dangling RUVs should be much less common(hopefully eliminated).

As said above, there is a workaround - issuing clean ruv using LDIF.

Per triage on Oct 25, viven these reasons, it's not worth spending resources to fix this issue. 

Other possibility is to contribute patch: https://www.freeipa.org/page/Contribute/Code