On 9.10.2012 21:31, Rob Crittenden wrote:
Martin Kosek wrote:
On 10/08/2012 05:12 PM, Jan Cholasta wrote:
On 20.9.2012 19:38, Rob Crittenden wrote:
Jan Cholasta wrote:
Dne 31.8.2012 19:43, Rob Crittenden napsal(a):
The naming in CS replication agreements is different from IPA
agreements, we have to live with what the create. The master side
be on the local side, replica1, not the remote. This required
a few master variables.
Pass in the force flag to del_link.
Do a better job of finding the agreements on each side.
This should be ipa-csreplica-manage more in line with
Rob, can you please rebase the patch on top of current master? There
were some dogtag 10 related changes to ipa-csreplica-manage since you
posted the patch.
I re-tested after the merge and found some problems with my initial
approach. The problem stems from the naming convention that dogtag uses
when creating the initial agreements. It is hard to predict how things
were set up later so rather than trying to reconstruct the DN we search
for it and pass it when deleting agreements.
So far I have found this:
* Deleting a "bridge" link that connects two "islands" of replicas
it should not (I was told that this is expected, as no complex graph
are engaged to detect this kind of errors).
Exactly, I hit this error when I was a similar Rob's patch for
ipa-replica-manage (ticket 2797). I used topology "A - B - C - D - E"
and I was
able to delete C. We may want to log an enhancement ticket for this.
Right, and ipa-csreplica-manage doesn't even have the basic last_link
checking code that ipa-replica-manage has, nor the ruv code. We decided
to push that to a future release.
This patch should fix up the basics.
This fixes everything except I'm still unable to delete a master from a
master that is not directly connected to it. If this is OK, then ACK.
Freeipa-devel mailing list