Bret Wortman wrote:
A bit of googling has led me to understand that we must have created the
original server with --selfsign, and that locked us into something bad
which is now causing us problems. I'm not sure how this happened, since
we actually created our original instance on a different server, created
ipamaster as a replica of that one, then ran ipa-ca-install on ipamaster
to make it the new CA. How did it end up in this state?
Anyway, is there ANY way around this? Can I simply ignore this, break
the replication agreement as Simo suggested, rebuild ipamaster,
replicate ipamaster2 to the new ipamaster, and then somehow make
ipamaster be a CA using Dogtag? Will that screw up all the clients?
I think we should pause and take a look at your installation.
I'd check all your current masters, whether they are currently working
or not. Look at the value of ra_plugin in /etc/ipa/default.conf. That
controls what IPA thinks the CA is.
Then check to see if you have dogtag running on any of these systems.
This will include a 2nd 389-ds instance, /etc/dirsrv/slapd-PKI-IPA and,
depending on your distro, a PKI service like
firstname.lastname@example.org. You can optionally see if
There is currently no way post-install to add a dogtag instance.
On Thu, Aug 29, 2013 at 9:24 AM, Bret Wortman
<bret.wort...@damascusgrp.com <mailto:bret.wort...@damascusgrp.com>> wrote:
Agreed, but not always possible. I had a replica crash hard and it
wasn't possible to remove it.
In other news:
[ipamaster2]# ipa-ca-install replica-info-ipamaster2.spx.net.gpg
A selfsign CA can not be added
Is there a way around this? How can I ensure that I can transfer the
CA back to ipamaster after it's been erased & reinstalled?
On Thu, Aug 29, 2013 at 9:21 AM, Simo Sorce <s...@redhat.com
On Thu, 2013-08-29 at 09:14 -0400, Bret Wortman wrote:
> On Thu, Aug 29, 2013 at 9:09 AM, Simo Sorce <s...@redhat.com
> On Thu, 2013-08-29 at 08:07 -0400, Bret Wortman wrote:
> > Okay, I have a replica built and running. My original,
> "sick" server
> > is ipamaster and the new one is ipamaster2. All
> thus far on
> > ipamaster2 is run ipa-replica-install --setup-dns
> > replica-info-ipamaster2.foo.net.gpg.
> > What additional steps do I need to take to ensure
> process of
> > shutting down ipamaster, wiping it out, building it
> and then
> > replicating ipamaster2 back to ipamaster and making
> ipamaster again
> > the center of the universe and my certificate
> > correctly, cleanly, and with minimal fuss? Given
the mess I
> got our
> > servers already, I figured I should ask before I start
> messing about
> > today.
> > I think the process should look something like this
> want you
> > all thinking I'm looking for someone to do all my
> for me):
> > 1. Take snapshot of ipamaster (just in case)
> > 2. [ipamaster2]#
> > should've done this during the ipa-ca-install, but
> ca step
> > is so rare, I didn't have it in my wiki notes).
> > 3. [ipamaster]# reboot
> > This reboot will trigger a Cobbler & Puppet-based
> the system
> > and reinstallation of F18 and freeipa-server. While
> going on:
> > 4. [ipamaster2]# ipa-replica-prepare
> You need to use ipa-replica-manage to remove the original
> before you can prepare to add a new one.
> After it is fully removed and replica file generated
> to restart
> at yleast 389ds on ipamaster2 this is due to the fact
> does nto
> purge valid tickets, and it holds a ticket valid for
> however when you reinstall the new the name will match so
> between ipamaster2 -> ipamaster may fail because
> has a wrong
> ticket (using old key you just nuked before the
> Got it. Glad I asked! I'll add these steps to my procedure.
> > When ipamaster is back up:
> > 5. [ipamaster]# cd /var/lib/ipa && scp
> You can copy in /root
> I usually do it in /var/lib/ipa I guess because that's where the
> server puts the file, so it makes it easy for me to remember
> where it is. But point taken.
> > 6. [ipamaster]# ipa-replica-install --setup-dns
> > --setup-ca replica-info-ipamaster.foo.net.gpg
> > Usually, there's some reason I need to go back to
> > either delete a dns entry or ipa host-del the system.
> Uh ? Sound like this is going to screw up things, why
> you delete
> DNS entries ?
> ipa host-del of a master is *certainly* going to break
> replication and
> basically everything. Is this what you did in your
old setup ?
> Only if ipa-replica-install said I needed to.
ok this means you previously uninstalled a replica directly on the
machine but tdid not remove it from the domain, this is bad
you should use ipa-replica-manage before you retire a machine if
possible, otherwise you leave dangling replication agreements, DNS
names, ID ranges (this means you loose ID space), and keys.
> > After the replica install is done:
> > 7. Shut down and delete the ipamaster2 VM.
> Do not forget to ipa-replica-manage remove it first.
> Awesome. This is why I asked.
> > 8. Upgrade existing "replicas" to F18 and latest IPA
> > 9. Establish replication agreements with
> > Does that sound right?
> See above.
> Simo Sorce * Red Hat, Inc * New York
Simo Sorce * Red Hat, Inc * New York
Freeipa-users mailing list
Freeipa-users mailing list