Re: [Freeipa-users] Fwd: Scorched earth
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.gpghttp://bl-1.com/click/load/UmNcb1c3BTVQNlMzBTU-b0231(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.nethttp://bl-1.com/click/load/XWxZalAwUWFQNgdnBzY-b02311.2.3.4 When ipamaster is back up: 5. [ipamaster]# cd /var/lib/ipa scp ipamaster2:/var/lib/ipa/replica-info-ipamaster.foo.net.gpghttp://bl-1.com/click/load/UmMKOVw8AjICZAdnVGo-b0231. 6. [ipamaster]# ipa-replica-install --setup-dns --no-forwarders --setup-ca replica-info-ipamaster.foo.net.gpghttp://bl-1.com/click/load/Bjdcb1AwUGAEYgZmCTY-b0231 Usually, there's some reason I need to go back to ipamaster2 and either delete a dns entry or ipa host-del the system. After the replica install is done: 7. Shut down and delete the ipamaster2 VM. 8. Upgrade existing replicas to F18 and latest IPA version. 9. Establish replication agreements with now-functioning ipamaster. Does that sound right? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Aug 28, 2013 at 10:01 PM, Bret Wortman bret.wort...@damascusgrp.com wrote: I was actually considering something like a few hours ago. It's a VM, so making another isn't that hard. Replication is the source of all my problems, though, so I'm concerned about whether it will work. Certainly worth the attempt! I'll report back later tomorrow. On Wed, Aug 28, 2013 at 8:56 PM, Jatin Nansi jna...@redhat.com wrote: On 08/29/2013 12:16 AM, Bret Wortman wrote: Ugh. Well that certainly hurts, but I just don't see an alternative. I hope Puppet can at least make the re-enrollment a bit easier. I'm still hand-copying some of the configuration and user group details and crafting the load scripts so if anyone has a bright idea in the next few hours, I'd love to hear it! Is there a reason why you must scorch earth? You could try a rolling update approach first - install a fresh IPA system, make it a replica of the existing IPA setup. Then reinstall existing IPA systems and use the updated system to set them up. Jatin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
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). When ipamaster is back up: 5. [ipamaster]# cd /var/lib/ipa scp You can copy in /root 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 ? After the replica install is done: 7. Shut down and delete the ipamaster2 VM. Do not forget to ipa-replica-manage remove it first. 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
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. 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
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
Re: [Freeipa-users] Fwd: Scorched earth
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.
Re: [Freeipa-users] Fwd: Scorched earth
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.comwrote: 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
Re: [Freeipa-users] Fwd: Scorched earth
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 pki-tomcatd@pki-tomcat.service. You can optionally see if /etc/pki/pki-tomcat exists. There is currently no way post-install to add a dogtag instance. rob _ _ *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret 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? _ _ *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 9:21 AM, Simo Sorce s...@redhat.com mailto: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 mailto: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 http://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
Re: [Freeipa-users] Fwd: Scorched earth
Bret Wortman wrote: On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: 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. on ipamaster: ra_plugin=dogtag and either that same value or the ra_plugin doesn't exist on the replicas. On ipamaster2, the one I just installed, there is no ra_plugin in the file. 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 pki-tomcatd@pki-tomcat.__service. You can optionally see if /etc/pki/pki-tomcat exists. ipamaster definitely has a /etc/dirsrv/slapd-PKI-IPA directory, with files updated fairly recently (within the past 30 minutes - lse.ldif and lse.ldif.bak, others updated yesterday). I also have a pki-tomcatd@.service file and a pki-tomcatd.target. no /etc/pki/pki-tomcat. ipamaster2 only has /etc/dirsrv/slapd-FOO-NET. It does have pki-tomcatd.target and pki-tomcatd@.service. No /etc/pki/pki-tomcat. Ok. When you created the replica file for ipamaster2, did you create it on ipamaster? Only a replica that is a CA can create a replica with a CA. If you generated the replica file on another master, I *think* what you can safely do is this: - prepare a replica on ipamaster for ipamaster2 and copy the file there - on ipamaster2 run ipa-ca-install against the updated replica file rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Fwd: Scorched earth
Ugh. Well that certainly hurts, but I just don't see an alternative. I hope Puppet can at least make the re-enrollment a bit easier. I'm still hand-copying some of the configuration and user group details and crafting the load scripts so if anyone has a bright idea in the next few hours, I'd love to hear it! * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Aug 28, 2013 at 9:56 AM, Rob Crittenden rcrit...@redhat.com wrote: Bret Wortman wrote: Today, I'm going to wipe my master, install f18 from scratch, then install the freeipa-server RPMs again and manually load all our hosts, dns entries, and users from scratch (I'm building scripts to do this for me using the command line tools). We'll then do the same for each replica so that our system will basically be starting clean again. Are there any files that I really ought to back up and restore as part of this effort, like certificates, that might make it easier for clients to deal with us after the master comes back on line? Or am I safe to just nuke the box and start clean? You'll end up with a new CA so you'll need to re-enroll any client machines. Browsers will see the most grief as there will be a different CA with the same subject. Depending on how you are migrating your users they will all likely need to reset their passwords, or go through the migration step. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
On 08/28/2013 10:16 AM, Bret Wortman wrote: Ugh. Well that certainly hurts, but I just don't see an alternative. I hope Puppet can at least make the re-enrollment a bit easier. I'm still hand-copying some of the configuration and user group details and crafting the load scripts so if anyone has a bright idea in the next few hours, I'd love to hear it! _ _ *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Aug 28, 2013 at 9:56 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Bret Wortman wrote: Today, I'm going to wipe my master, install f18 from scratch, then install the freeipa-server RPMs again and manually load all our hosts, dns entries, and users from scratch (I'm building scripts to do this for me using the command line tools). We'll then do the same for each replica so that our system will basically be starting clean again. Are there any files that I really ought to back up and restore as part of this effort, like certificates, that might make it easier for clients to deal with us after the master comes back on line? Or am I safe to just nuke the box and start clean? You'll end up with a new CA so you'll need to re-enroll any client machines. Browsers will see the most grief as there will be a different CA with the same subject. Depending on how you are migrating your users they will all likely need to reset their passwords, or go through the migration step. And migration step means you carry forward user data as if you migrated from an LDAP server. In this case you can complete migration using either a migration web page or just using SSSD. If the migration is enabled and you migrated LDAP password attributes from the older IPA then SSSD and/or migration page would be able to capture user password and create kerberos hashes completing the migration. This at least would not require people to change the passwords. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
On 08/29/2013 12:16 AM, Bret Wortman wrote: Ugh. Well that certainly hurts, but I just don't see an alternative. I hope Puppet can at least make the re-enrollment a bit easier. I'm still hand-copying some of the configuration and user group details and crafting the load scripts so if anyone has a bright idea in the next few hours, I'd love to hear it! Is there a reason why you must scorch earth? You could try a rolling update approach first - install a fresh IPA system, make it a replica of the existing IPA setup. Then reinstall existing IPA systems and use the updated system to set them up. Jatin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fwd: Scorched earth
I was actually considering something like a few hours ago. It's a VM, so making another isn't that hard. Replication is the source of all my problems, though, so I'm concerned about whether it will work. Certainly worth the attempt! I'll report back later tomorrow. On Wed, Aug 28, 2013 at 8:56 PM, Jatin Nansi jna...@redhat.com wrote: On 08/29/2013 12:16 AM, Bret Wortman wrote: Ugh. Well that certainly hurts, but I just don't see an alternative. I hope Puppet can at least make the re-enrollment a bit easier. I'm still hand-copying some of the configuration and user group details and crafting the load scripts so if anyone has a bright idea in the next few hours, I'd love to hear it! Is there a reason why you must scorch earth? You could try a rolling update approach first - install a fresh IPA system, make it a replica of the existing IPA setup. Then reinstall existing IPA systems and use the updated system to set them up. Jatin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
