[Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA

Martin Kosek mkosek at redhat.com
Fri Nov 16 13:25:22 UTC 2012


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 Dogtag
>>>> defaults made it to master independently (91e477b). Attaching rebased patch.
>>>>
>>>> Note that to continue development on f17, you will need to use the
>>>> dogtag-devel
>>>> repo:
>>>>    sudo yum-config-manager
>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo
>>>>
>>>>
>>>>
>>>>
>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote:
>>>> [...]
>>>>>
>>>>> For convenience, I've also pushed the changes to a personal repository.
>>>>> To fetch to branch "pviktori-dogtag-10" you can do:
>>>>>
>>>>>       git fetch -f git://github.com/encukou/freeipa.git
>>>>> dogtag-10:pviktori-dogtag-10
>>>>>
>>>>
>>>
>>> I started reviewing the patches, and found the first thing that looks
>>> suspicious. I had IPA with 2 databases, then upgraded it to single-database
>>> IPA, the upgrade was OK.
>>>
>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed because
>>> when I installed single-db IPA afterwards, I had 2 dirsrv instances running.
>>
>> You're right. This is an uninstaller error already present in 2.2:
>> https://fedorahosted.org/freeipa/ticket/3258
>>
>> I'll start looking into it tomorrow, if nothing more important shows up.
>>
>
> Thanks for the pointer. But this is definitely not a show stopper, running
> 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:
>      A
>    /   \
> 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.
>
> Martin

The fix for that for easier than expected. Attached patch restored the previous 
functionality for ipa-(cs)replica-manage. I tried that with all basic commands 
- 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.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-336-filter-suffix-in-replication-management-tools.patch
Type: text/x-patch
Size: 4878 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20121116/7c5a78e0/attachment.bin>


More information about the Freeipa-devel mailing list