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

Wed Nov 21 13:43:46 UTC 2012

On Wed, 2012-11-21 at 10:46 +0100, 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.

In order of preference:
LDAP/GSSAPI
LDAP/TLS/
LDAPS

but using ldaps is not the end of the world, so don't tie yourself up
due to this.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York