[Freeipa-devel] Topology plugin quirks

[Ludwig Krispenz]

On 06/03/2015 01:32 PM, Oleg Fayans wrote:
> Hi Ludwig
>
> On 06/03/2015 12:23 PM, Ludwig Krispenz wrote:
>>
>> On 06/03/2015 11:51 AM, Oleg Fayans wrote:
>>> I confirm every point of this.
>> did you test with all the latest patches applied ? In your issues you 
>> refer to crashes, the crashes reported should be resolved, if you 
>> still have crashes, pleas provide a core dump or scenario to 
>> reproduce the crash.
>> With patch0009 ipa-replica-manage del worked for me
> Yep, patch 0009 is applied.
> The full list of patches applied on top of the master branch (at it's 
> state yesterday at 10 PM) is as follows:
> freeipa-lkrispen-0007-replica-install-fails-with-domain-level-1.patch
> freeipa-lkrispen-0008-plugin-uses-1-as-minimum-domain-level-to-become-acti.patch 
>
> freeipa-lkrispen-0009-crash-when-removing-a-replica.patch
> freeipa-mbasti-0262-Installers-fix-remove-temporal-ccache.patch
> freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch
> freeipa-pvoborni-0858-1-webui-IPA.command_dialog-a-new-dialog-base-class.patch 
>
> freeipa-pvoborni-0859-1-webui-use-command_dialog-as-a-base-class-for-passwor.patch 
>
> freeipa-pvoborni-0860-1-webui-make-usage-of-all-in-details-facet-optional.patch 
>
> freeipa-pvoborni-0861-2-webui-topology-plugin.patch
> freeipa-pvoborni-0862-webui-configurable-refresh-command.patch
>
> The scenario is pretty basic:
> 1. 3 fedora-21 vms with the latest directory server packages from 
> mreynolds repo:
> 389-ds-base-2015_06_02-1.fc21.x86_64
>
> 2. setup master on one of them, prepare gpg files for two replicas
> 3. setup replicas using these gpg files.
> 4. Try to remove one of the replicas using command `ipa 
> topologysegment-del`
this should remove a segment, not a replica and it should be rejected
> 5. Try to create a new user via web UI on any of the replicas
>
>>
>>>
>>> On 06/03/2015 11:37 AM, Martin Babinsky wrote:
>>>> Hi everyone,
>>>>
>>>> I have been playing with the topology related patches and I have 
>>>> encountered a few issues that I would like to address in this thread:
>>>>
>>>> 1.) When replica install for whatever reason crashes _after_ the 
>>>> setup of replication agreements etc., it leaves the topology plugin 
>>>> with dangling segment pointing to the dysfunctional node. An 
>>>> attempt to delete it leads to:
>>>>
>>>> """
>>>> ipa: ERROR: Server is unwilling to perform: Removal of Segment 
>>>> disconnects topology.Deletion not allowed.
>>>> """
>>> Furthermore, any attempts to delete a segment (even a properly setup 
>>> one) lead to the same very error.
>>>>
>>>> And you cannot reinstall the crashed replica because it complains 
>>>> about existing replication agreements. It would probably help to be 
>>>> able to force-remove the segments if one of the endpoints doesn't 
>>>> exist/respond.
>>>>
>>>> 2.) I was not able to figure out a way remove replica from the 
>>>> topology without explosions or tampering 
>>>> 'cn=masters,cn=ipa,cn=etc,$SUFFIX'. Obviously ipa-replica-manage 
>>>> del doesn't work anymore (I have tried just for fun, it leads to 
>>>> SIGSEGV of the host's dirsrv and leaves dangling segments to 
>>>> offending replica, leading to point 1).
>>>>
>>>> I managed to remove replica from the topology only by directly 
>>>> uninstalling FreeIPA on the node and then deleting its' host entry 
>>>> from 'cn=masters'. Only after this was the plugin able to 
>>>> automagically removed the segments pointing to/from removed node.
>>>>
>>>> The design page suggests that it should be enough to uninstall IPA 
>>>> server on the replica. The plugin would then pick-up the dangling 
>>>> segments and remove them automatically. However, this behavior 
>>>> seems to require additional modification of the uninstall procedure 
>>>> (e.g. the uninstalling replica should remove its' entry from 
>>>> cn=masters).
>>>>
>>>> 3.) It seems that the removal of topology suffixes containing 
>>>> functioning segments is not handled well. I once tried to do this 
>>>> and it led to segmentation fault on the dirsrv instance. What is 
>>>> the expected behavior in this scenario?
>>>>
>>>
>>
>