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