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

[Petr Viktorin]

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
>>>>>> 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 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
> installation:
>
[...]

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


-- 
Petr³