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

Petr Viktorin pviktori at redhat.com
Wed Nov 21 09:54:03 UTC 2012 

On 11/21/2012 10:48 AM, Martin Kosek wrote:
> On 11/21/2012 10:46 AM, Martin Kosek wrote:
>> On 11/20/2012 02:59 PM, Petr Viktorin wrote:
>>> 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.
>>>
>>
>> Works fine, I was able to create a network of few IPA 2.2 replicas and IPA 3.1
>> replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the
>> agreements. No regression discovered so far.
>>
>> I just see that in patch 101 you touch setup_replication and force TLS as a
>> default. But in this case, r_sslport parameter is never used and we can remove it.
>>
>> In 101, you also set LDAP+TLS as default connection protocol with
>> +        super(CSReplicationManager, self).__init__(
>> +            realm, hostname, dirman_passwd, port, starttls=True)
>>                                                     ^^^^^^^^^^^^^
>>
>> Wouldn't we want to make LDAP+TLS as a default also in a bunch of
>> ReplicationManager initializations in ipa-replica-manage? Otherwise, we use
>> ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would
>> be a good step to do. Adding Rob and Simo to CC to correct me if I miss
>> anything and we want to keep using ldaps/SSL by default.
> ... adding to CC now!
>

Yes, that would be good. I think it's out of scope for this patchset, 
though.
Do we have a bug for this already?
I think John or I can include it in the 
https://fedorahosted.org/freeipa/ticket/2660 or 
https://fedorahosted.org/freeipa/ticket/2652 efforts.

-- 
Petr³

More information about the Freeipa-devel mailing list