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