On 11/16/2012 06:46 PM, Petr Viktorin wrote:
On 11/16/2012 05:17 PM, Martin Kosek wrote:
On 11/16/2012 02:25 PM, Martin Kosek wrote:
On 11/16/2012 11:23 AM, Martin Kosek wrote:
On 11/15/2012 07:17 PM, Petr Viktorin wrote:
On 11/15/2012 05:09 PM, Martin Kosek wrote:
On 11/15/2012 03:19 PM, Petr Viktorin wrote:
Recently, the specfile changed (dce53e4) and the patch for changed
defaults made it to master independently (91e477b). Attaching
rebased patch.

Note that to continue development on f17, you will need to use the
   sudo yum-config-manager

On 11/13/2012 03:57 PM, Petr Viktorin wrote:

For convenience, I've also pushed the changes to a personal
To fetch to branch "pviktori-dogtag-10" you can do:

      git fetch -f git://github.com/encukou/freeipa.git

I started reviewing the patches, and found the first thing that looks
suspicious. I had IPA with 2 databases, then upgraded it to
IPA, the upgrade was OK.

But when I uninstalled the IPA, PKI-IPA dirsrv instance was not
when I installed single-db IPA afterwards, I had 2 dirsrv instances

You're right. This is an uninstaller error already present in 2.2:

I'll start looking into it tomorrow, if nothing more important shows

Thanks for the pointer. But this is definitely not a show stopper,
additional DS instance seems more or less benign and as you pointed
out, it is
rather an old bug.

There are bigger issues. Now I focused on ipa-replica-manage and
ipa-csreplica-manage tools. ipa-replica-manage gets confused with the
additional replication agreements in IPA dirsrv instance (although
targeted to
nsDS5ReplicaRoot: o=ipaca).

First scenario: 3 IPA servers with CA in this topology:

B - A - C

On A:
# ipa-replica-manage list `hostname`
vm-055.idm.lab.bos.redhat.com: replica
vm-070.idm.lab.bos.redhat.com: replica
vm-055.idm.lab.bos.redhat.com: replica
vm-070.idm.lab.bos.redhat.com: replica

it should not display agreements that are for IPA only, not IPA CA ones.

Now, when I try to connect B to C, ipa-replica-manage succeeded:
[B] # ipa-replica-manage connect C
Connected 'B' to 'C'

This changed the topology to:
   /   \
B   -  C

But ipa-csreplica-manage connect did not succeed then:
[B] # ipa-csreplica-manage connect C
Directory Manager password:

This replication agreement already exists.

Del command also failed for me:
[A] ipa-replica-manage del [C]

Still trying to investigate why. If I manage to get some workable fix
during my
investigations, I will attach it later.


The fix for that for easier than expected. Attached patch restored the
functionality for ipa-(cs)replica-manage. I tried that with all basic
- add, del, connect, disconnect and it worked fine so far.

But this was a case with all D10 masters, I will need to try if that
flies with
D9->D10 replicas or upgraded D9 masters.


I have issues creating a 3.1 replica for 3.0 master (D10) with split
databases. I run the script, but now I always end with error during CA


I couldn't reproduce this. Perhaps you installed the master or replica in a
different way? What are the commands you used?

I am not sure what the different way means. I installed the 3.0 master with DNS support, on Fedora 18, with pki-ca-10.0.0-0.52.b3.fc18.noarch. Then created a replica info file, and run the script.

On replica, I used standard

# ipa-replica-install INFO_FILE
# ipa-ca-install INFO_FILE

The second command crashed. But I got the same result with:
# ipa-replica-install INFO_FILE --setup-ca

I can investigate it more on Monday if you do not find anything suspicious. It may have been my fault.


Freeipa-devel mailing list

Reply via email to