Bug 1387369 - clean-ruv doesn't work with unmanaged ruv
Summary: clean-ruv doesn't work with unmanaged ruv
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: IPA Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-20 17:35 UTC by Lucas Diedrich
Modified: 2016-10-31 09:37 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-31 09:37:22 UTC
Type: Bug


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.