you have to remove the server from the manged servers, ipa-replica-manage del would do it, but it fails in line:13 "not allowed on leaf entry" This is a bug I reported today. In my tests I did use a script to delete a master and its services (before).
Tomas has proposed a fix, which should allow ipa-replica-manage del succeed.

What is interesting in your log is line:7, it contains a corrpted ruv, and we have been trying to reproduce this, but did fail so far. Could you provide me a full log of actvities you have don in this test scenario ?


On 05/06/2015 04:47 PM, Oleg Fayans wrote:
Hi Ludwig,

I have a question. What is the proper way of removing ipa replica from
the server that is replication-topology-aware? Standard way
`ipa-replica-manage del` does not work anymore, since the topology is
controlled by the plugin, but I was unable to remove it using
topology-aware tools as well. Here is the transcript of my session:

Thanks in advance!

On 05/04/2015 04:46 PM, Martin Kosek wrote:
Thanks for answers.

BTW, for future, I think Oleg that it would be useful to ask this questions on
freeipa-devel directly as it may be helpful to other developers and we would
have it archived for other uses.

On 05/04/2015 04:20 PM, Ludwig Krispenz wrote:
On 04/30/2015 03:22 PM, Oleg Fayans wrote:
Hi Ludwig,

While getting myself familiar with Replication Topology Plugin design
page I've found a number of places that need some clarifications.

Check at startup.
When the directory server starts, the plugin init and start functions
are executed, they will read the domain level
attribute and act accordingly
Could you describe how exactly should the plugin work depending on the
domain level revealed.
there are only two scenarios:
1] domain_level < plugin_level:
the plugin does almost nothing, reading its config and waiting for a dom level
2] doamin_level >= plugin_level:
the plugin controls topology for managed servers, rejecting direct mods of
replication agreements, transforming adding/deleting/modification of segments
into corresponding actions on replication agreements
Check for modify operation
If an admin or tool changes the domain level the plugin detects this
change and performs initialization tasks if the
domain level is greater than the plugin version
The same here: what exactly happens after the domain level has changed.
if the domain level raises, so that teh plugin becomes active, this will happen
on all servers since domain level is replicated.
the plugin will read all the exisu├čing info inthe shared tree, read all
replication configuration and match them creating missing data in both areas:
cn=config and shared tree
3. Regarding the startup delay. How can I make sure the plugin has started?
As far as I understood the Topology plugin needs to be started only
after all other plugins are started to prevent it from making a tree
changes before it is able to be replicated. The question is: how do I
check whether all other plugins are already started?
the plugin should be started when the server starts, it will expose this in the
root dse and you can search for it, I just updated teh design page with an 
4. Shared configuration layout
It is written there, that the replication topology information can be
configured to be stored in the custom place of the tree. How do we do that?
The configuration is in the plugin conf in cn=config. At the moment it is
populated when a DS instance is created.

Most probably I''ll have some more questions once I have the branch

Thank you!

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to