Re: [Freeipa-users] Fwd: Scorched earth

2013-08-29 Thread Bret Wortman
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

2013-08-29 Thread Simo Sorce
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

2013-08-29 Thread Bret Wortman
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

2013-08-29 Thread Simo Sorce
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

2013-08-29 Thread Bret Wortman
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

2013-08-29 Thread Bret Wortman
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

2013-08-29 Thread Rob Crittenden

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

2013-08-29 Thread Bret Wortman
On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden rcrit...@redhat.comwrote:

 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.


 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.wortman@**damascusgrp.combret.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 

Re: [Freeipa-users] Fwd: Scorched earth

2013-08-29 Thread Rob Crittenden

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


Re: [Freeipa-users] Fwd: Scorched earth

2013-08-28 Thread Dmitri Pal
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

2013-08-28 Thread Jatin Nansi

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

2013-08-28 Thread Bret Wortman
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