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

Tue Nov 20 13:59:39 UTC 2012

On 11/19/2012 03:14 PM, Petr Viktorin wrote:
> On 11/19/2012 02:09 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 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
>>>
>>
>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem
>> to work
>> well. I just think we will need to also backport the previous patch at
>> least to
>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication
>> management tool. I created a ticket for this purpose:
>>
>> https://fedorahosted.org/freeipa/ticket/3262
>>
>> Attaching a patch for IPA 2.2 branch in case somebody is also testing
>> it. With
>> this patch, I was able to list, force-sync, re-initialize, connect,
>> disconnect
>> from 2.2 to 3.1 replica without any errors.
>>
>> Martin
>>
>
> I checked ipa-csreplica-install, and found some more problems.
>
> In the "connect" and "disconnect" subcommands we now assume both masters
> use port 389 for the PKI DS. While the number is relatively easily
> parametrized, the assumption that both sides use the same port seems to
> run pretty deep.
> I'm working on a patch to detect if the remote server has merged DBs and
> use the appropriate port.

Attaching patches to do this.
Patch 0100 adds an argument to IPAdmin to overrides guessing of the 
protocol to use.
Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the 
DSs involved and use those.

Note that this touches code shared with ipa-replica-manage, please 
re-test that as well.

-- 
Petr³

-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0100-Provide-protocol-argument-to-IPAdmin.patch
Type: text/x-patch
Size: 3756 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20121120/db4716cf/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-pviktori-0101-Make-ipa-csreplica-manage-work-with-both-merged-and-.patch
Type: text/x-patch
Size: 14002 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20121120/db4716cf/attachment-0001.bin>