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? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 9:24 AM, Bret Wortman <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? > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Thu, Aug 29, 2013 at 9:21 AM, Simo Sorce <s...@redhat.com> wrote: > >> 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> wrote: >> > 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 I've done >> > thus far on >> > > ipamaster2 is run ipa-replica-install --setup-dns >> > --no-forwarders >> > > replica-info-ipamaster2.foo.net.gpg. >> > > >> > > >> > > What additional steps do I need to take to ensure that the >> > process of >> > > shutting down ipamaster, wiping it out, building it up fresh >> > and then >> > > replicating ipamaster2 back to ipamaster and making >> > ipamaster again >> > > the center of the universe and my certificate authority work >> > > 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 (I don't >> > want you >> > > all thinking I'm looking for someone to do all my thinking >> > for me): >> > > >> > > >> > > 1. Take snapshot of ipamaster (just in case) >> > > 2. [ipamaster2]# >> > > >> > ipa-ca-install /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg >> (I >> > > should've done this during the ipa-ca-install, but since the >> > 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 wipe of >> > the system >> > > and reinstallation of F18 and freeipa-server. While that's >> > going on: >> > > >> > > >> > > 4. [ipamaster2]# ipa-replica-prepare ipamaster.foo.net >> > 1.2.3.4 >> > >> > >> > You need to use ipa-replica-manage to remove the original >> > ipamaster >> > before you can prepare to add a new one. >> > >> > After it is fully removed and replica file generated you need >> > to restart >> > at yleast 389ds on ipamaster2 this is due to the fact that DS >> > does nto >> > purge valid tickets, and it holds a ticket valid for the old >> > ipamaster, >> > however when you reinstall the new the name will match so >> > replication >> > between ipamaster2 -> ipamaster may fail because ipamsater2 >> > has a wrong >> > ticket (using old key you just nuked before the reinstall). >> > > >> > >> > >> > >> > 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 that's >> > where it is. But point taken. >> > >> > > >> > ipamaster2:/var/lib/ipa/replica-info-ipamaster.foo.net.gpg . >> > > 6. [ipamaster]# ipa-replica-install --setup-dns >> > --no-forwarders >> > > --setup-ca replica-info-ipamaster.foo.net.gpg >> > > >> > > >> > > Usually, there's some reason I need to go back to ipamaster2 >> > and >> > > either delete a dns entry or ipa host-del the system. >> > >> > >> > Uh ? Sound like this is going to screw up things, why should >> > 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 practice. >> 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 >> > version. >> > > 9. Establish replication agreements with now-functioning >> > ipamaster. >> > > >> > > >> > > Does that sound right? >> > > >> > > >> > >> > See above. >> > >> > Simo. >> > >> > >> > -- >> > Simo Sorce * Red Hat, Inc * New York >> > >> > >> > >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> >
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users