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

[Petr Viktorin]

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.


-- 
Petr³