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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
