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: Fwd: Scorched earth
On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden rcrit...@redhat.comwrote: 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. Yes. So I'm not sure what went askew. 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] Using subdomains (or dots) in hostnames
On 08/19/2013 09:05 AM, Thomas Raehalme wrote: Hi! We are in the process of deploying FreeIPA in our virtual environment. So far things are working smoothly and I am really impressed by the solution! One question has risen as we have added our first clients to the system. Because the total number of clients is 50 and going up, we have divided our servers to subdomains depending on the purpose of the server, ie. test servers in one subdomain, internal services on another and so on. There is, however, no need for each subdomain to have its own IPA server. Let's say we're using domain example.com. Adding clients a.example.com and b.example.com was smooth. Adding client a.sub1.example.com also had no problems until I tried to get sudoers from the IPA server (using SSSD and LDAP as suggested). The client fails to find any users matching the server name. Because the only difference compared to a fully functional server is the dot in the host name, that's probably the reason why no sudoers are found for the server in the subdomain? For IPA master I am using CentOS 6.4 and ipa-server-3.0.0-26.el6_4.4.x86_64. The clients are also CentOS 6.4 with ipa-client-3.0.0-26.el6_4.4.x86_64. Any help is appreciated! Please let me know if providing any piece of information helps. Best regards, Thomas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Was there any help provided for this request? -- 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: Fwd: Scorched earth
Bret Wortman wrote: On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.comwrote: Bret Wortman wrote: On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto: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. Yes. So I'm not sure what went askew. Ok. I think we need to see what's in the prepared file. It is just a gpg-encrypted tarball. Can you do something like: gpg -d replica-info-pacer.greyoak.com.gpg |tar xf - This will create a realm_info subdirectory. The file cacert.p12 should be in there. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Announcing FreeIPA 3.3.1
The FreeIPA team is proud to announce FreeIPA v3.3.1! This is a bugfix release. It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 builds will be ready soon. == Highlights in 3.3.1 == === Bug fixes === * ipa-server-certinstall now works correctly both with a CA subsystem and in CA-less installations * The --subject option in ipa-server-install is now handled correctly * During installation, directory server tuning is performed correctly on sysV and systemd systems * During installation, the CA service is stopped during configuration file changes to prevent race conditions === Test improvements === * Integration tests for CA-less installation, Kerberos flags, and related Web UI parts were added to the test suite * Test suite now passes after ipa-adtrust-install == Upgrading == === FreeIPA servers with CA installed prior to version 3.1 === Manual upgrade procedure is required for FreeIPA servers installed with version prior to 3.1. Please see http://www.freeipa.org/page/Howto/Dogtag9ToDogtag10Migration for details. === Other FreeIPA servers and clients === An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.3.0 == === Alexander Bokovoy (1): === * Remove systemd upgrader as it is not used anymore === Ana Krivokapic (4): === * Handle --subject option in ipa-server-install * Fix broken replica installation * Add integration tests for Kerberos Flags * Fix tests which fail after ipa-adtrust-install === Jakub Hrozek (1): === * EXTDOM: Do not overwrite domain_name for INP_SID === Jan Cholasta (12): === * Make PKCS#12 handling in ipa-server-certinstall closer to what other tools do. * Port ipa-server-certinstall to the admintool framework. * Remove unused NSSDatabase and CertDB method find_root_cert_from_pkcs12. * Ignore empty mod error when updating DS SSL config in ipa-server-certinstall. * Replace only the cert instead of the whole NSS DB in ipa-server-certinstall. * Untrack old and track new cert with certmonger in ipa-server-certinstall. * Add --pin option to ipa-server-certinstall. * Ask for PKCS#12 password interactively in ipa-server-certinstall. * Fix nsSaslMapping object class before configuring SASL mappings. * Add --dirman-password option to ipa-server-certinstall. * Fix ipa-server-certinstall usage string. * Fix service-disable in CA-less install. === Martin Kosek (3): === * Prevent *.pyo and *.pyc multilib problems * Remove rpmlint warnings in spec file * Fix selected minor issues in the spec file and license === Nathaniel McCallum (1): === * Bypass ipa-replica-conncheck ssh tests when ssh is not installed === Petr Viktorin (4): === * Allow freeipa-tests to work with older paramiko versions * Add missing license header to ipa-test-config * Add CA-less install tests * Add man pages for testing tools === Petr Vobornik (7): === * Removal of deprecated selenium tests * Add base-id, range-size and range-type options to trust-add dialog * Hide 'New Certificate' action on CA-less install * Web UI integration tests: CA-less * Web UI Integration tests: Kerberos Flags * Web UI integration tests: ID range types * Update idrange search facet after trust creation === Rob Crittenden (1): === * Re-order NULL check in ipa_lockout. === Simo Sorce (3): === * pwd-plugin: Fix ignored return error * kdb-mspac: Fix out of bounds memset * kdb-princ: Fix memory leak === Sumit Bose (1): === * CLDAP: make sure an empty reply is returned on any error === Tomas Babej
Re: [Freeipa-users] Fwd: Fwd: Scorched earth
What passpharase would this be encrypted with? If it's something I set a year ago and never needed to know again, then we may be screwed. If it's saved somewhere, where should I look? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 11:58 AM, Rob Crittenden rcrit...@redhat.comwrote: Bret Wortman wrote: On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com**wrote: Bret Wortman wrote: On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto: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. Yes. So I'm not sure what went askew. Ok. I think we need to see what's in the prepared file. It is just a gpg-encrypted tarball. Can you do something like: gpg -d replica-info-pacer.greyoak.**com.gpg |tar xf - This will create a realm_info subdirectory. The file cacert.p12 should be in there. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using subdomains (or dots) in hostnames
In our deployment we use subdomains but set NIS domain to main domain: example.com has subdomains na.example.com wa.example.com ... all machines work fine with that but in /etc/sysconfig/network we have NISDOMAIN='example.com' This way sudo rules get evaluated see getent netgroup hostgroup On Thu, Aug 29, 2013 at 5:55 PM, Dmitri Pal d...@redhat.com wrote: On 08/19/2013 09:05 AM, Thomas Raehalme wrote: Hi! We are in the process of deploying FreeIPA in our virtual environment. So far things are working smoothly and I am really impressed by the solution! One question has risen as we have added our first clients to the system. Because the total number of clients is 50 and going up, we have divided our servers to subdomains depending on the purpose of the server, ie. test servers in one subdomain, internal services on another and so on. There is, however, no need for each subdomain to have its own IPA server. Let's say we're using domain example.com. Adding clients a.example.com and b.example.com was smooth. Adding client a.sub1.example.com also had no problems until I tried to get sudoers from the IPA server (using SSSD and LDAP as suggested). The client fails to find any users matching the server name. Because the only difference compared to a fully functional server is the dot in the host name, that's probably the reason why no sudoers are found for the server in the subdomain? For IPA master I am using CentOS 6.4 and ipa-server-3.0.0-26.el6_4.4.x86_64. The clients are also CentOS 6.4 with ipa-client-3.0.0-26.el6_4.4.x86_64. Any help is appreciated! Please let me know if providing any piece of information helps. Best regards, Thomas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Was there any help provided for this request? -- 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Using subdomains (or dots) in hostnames
On Mon, Aug 19, 2013 at 04:05:40PM +0300, Thomas Raehalme wrote: Hi! We are in the process of deploying FreeIPA in our virtual environment. So far things are working smoothly and I am really impressed by the solution! One question has risen as we have added our first clients to the system. Because the total number of clients is 50 and going up, we have divided our servers to subdomains depending on the purpose of the server, ie. test servers in one subdomain, internal services on another and so on. There is, however, no need for each subdomain to have its own IPA server. Let's say we're using domain example.com. Adding clients a.example.com and b.example.com was smooth. Adding client a.sub1.example.com also had no problems until I tried to get sudoers from the IPA server (using SSSD and LDAP as suggested). The client fails to find any users matching the server name. Because the only difference compared to a fully functional server is the dot in the host name, that's probably the reason why no sudoers are found for the server in the subdomain? For IPA master I am using CentOS 6.4 and ipa-server-3.0.0-26.el6_4.4.x86_64. The clients are also CentOS 6.4 with ipa-client-3.0.0-26.el6_4.4.x86_64. Any help is appreciated! Please let me know if providing any piece of information helps. Best regards, Thomas Sorry Thomas, the subject line fooled me and I didn't see this might be a SSSD issue. What do you use in nsswitch.conf for sudoers? ldap or sss? If sss, can you also paste your sssd.conf? Can you paste the output of sudo along with the -D parameter to get some debugging? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] setting up a client on Debian squeeze
Michał Dwużnik wrote: Hi folks, did anyone succeed in connecting such an old thing recently to freeipa server? Is there a document (or an archive post) about connecting a 'non ipa aware' client step by step? I got as far as woing Kerberos with no issues, hit a wall with ldap part.. You might try this: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/linux-manual.html rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] setting up a client on Debian squeeze
As for now I have set up a 'known good' client on RH based distro, to get the feeling how the config files look like when configured correctly. Thanks for the nice reference M. On Thu, Aug 29, 2013 at 7:56 PM, Rob Crittenden rcrit...@redhat.com wrote: Michał Dwużnik wrote: Hi folks, did anyone succeed in connecting such an old thing recently to freeipa server? Is there a document (or an archive post) about connecting a 'non ipa aware' client step by step? I got as far as woing Kerberos with no issues, hit a wall with ldap part.. You might try this: http://docs.fedoraproject.org/** en-US/Fedora/17/html/FreeIPA_**Guide/linux-manual.htmlhttp://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/linux-manual.html rob -- Michal Dwuznik ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] setting up a client on Debian squeeze
Ok, going step by step I did the following on squeeze:
set up ntp, time synced with ipa server
test setup is done on
ipa.localdomain (server)
client.localdomain
(client on Scientific Linux 6.4, looks ok after ipa-client-install, ssh
works for test users tester and tester2)
client2.localdomain is the Debian Squeeze client
added host client2.localdomain on IPA server, added 'managedby', got the
keytab and put the 'client2.keytab' in /etc/krb5.keytab on client2
most important part of /etc/krb5.conf:
[realms]
LOCALDOMAIN = {
kdc = ipa.localdomain
admin_server = ipa.localdomain
}
[domain_realm]
.localdomain = LOCALDOMAIN
localdomain = LOCALDOMAIN
default_domain = localdomain
[libdefaults]
default_realm = LOCALDOMAIN
The following lets me think the KRB5 part of the setup is done correctly:
root@client2:/etc# kinit admin
Password for admin@LOCALDOMAIN:
root@client2:/etc# kdestroy
root@client2:/etc# kinit tester
Password for tester@LOCALDOMAIN:
root@client2:/etc# klis
-su: klis: command not found
root@client2:/etc# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: tester@LOCALDOMAIN
Valid starting ExpiresService principal
08/30/13 00:35:50 08/31/13 00:35:47 krbtgt/LOCALDOMAIN@LOCALDOMAIN
root@client2:/etc# kpasswd tester
Password for tester@LOCALDOMAIN:
Enter new password:
Enter it again:
Password changed.
I guess that's the point of snapshotting 'KRB done' state (can I be wrong?)
DNS for all the hosts involved is similar to:
root@client2:/etc# nslookup ipa
Server: 192.168.137.29
Address:192.168.137.29#53
Name: ipa.localdomain
Address: 192.168.137.13
root@client2:/etc# nslookup 192.168.137.13
Server: 192.168.137.29
Address:192.168.137.29#53
13.137.168.192.in-addr.arpa name = ipa.localdomain.
Now I guess it's time for certificates, where I do have some doubts...
I've added the SSH host keys via web interface, now the cert part:
having generated the CSR afte creating the new database:
certutil -R -d . -a -g 2048 -s 'CN=client2.localdomain,O=LOCALDOMAIN'
(in the /etc/pki dir) I paste the CSR and Issue the certificate for host
(/etc/pi contains newly created cert8.db key3.dbsecmod.db )
Which of those should be used to add the cert to?
(like certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i */path/to/*
ca.crt)
All of the tries result in:
root@client2:/etc/pki# certutil -A -d /etc/pki/cert8.db -n IPA CA -t
CT,C,C -a -i ./ca.crt
certutil: function failed: security library: bad database.
root@client2:/etc/pki# certutil -A -d /etc/pki/secmod.db -n IPA CA -t
CT,C,C -a -i ./ca.crt
certutil: function failed: security library: bad database.
root@client2:/etc/pki# certutil -A -d /etc/pki/key3.db -n IPA CA -t
CT,C,C -a -i ./ca.crt
certutil: function failed: security library: bad database.
Could someone show me my mistake?
Regards
Michal
On Thu, Aug 29, 2013 at 9:00 PM, Michał Dwużnik michal.dwuz...@gmail.comwrote:
As for now I have set up a 'known good' client on RH based distro, to get
the feeling how the config files
look like when configured correctly.
Thanks for the nice reference
M.
On Thu, Aug 29, 2013 at 7:56 PM, Rob Crittenden rcrit...@redhat.comwrote:
Michał Dwużnik wrote:
Hi folks,
did anyone succeed in connecting such an old thing recently to freeipa
server?
Is there a document (or an archive post) about connecting a 'non ipa
aware' client step by step?
I got as far as woing Kerberos with no issues, hit a wall with ldap
part..
You might try this: http://docs.fedoraproject.org/**
en-US/Fedora/17/html/FreeIPA_**Guide/linux-manual.htmlhttp://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/linux-manual.html
rob
--
Michal Dwuznik
--
Michal Dwuznik
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] setting up a client on Debian squeeze
Sorry for quick continuation...
Certificate added to nss DB in /etc/pki
certutil -A -d /etc/pki/ -n IPA CA -t CT,C,C -a -i pki/ca.crt
sssd configured according to
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/linux-manual.html
How do I test now, before changing PAM options that the pieces fit together?
(Sorry for being a bit too tired...)
M.
On Fri, Aug 30, 2013 at 1:49 AM, Michał Dwużnik michal.dwuz...@gmail.comwrote:
Ok, going step by step I did the following on squeeze:
set up ntp, time synced with ipa server
test setup is done on
ipa.localdomain (server)
client.localdomain
(client on Scientific Linux 6.4, looks ok after ipa-client-install, ssh
works for test users tester and tester2)
client2.localdomain is the Debian Squeeze client
added host client2.localdomain on IPA server, added 'managedby', got the
keytab and put the 'client2.keytab' in /etc/krb5.keytab on client2
most important part of /etc/krb5.conf:
[realms]
LOCALDOMAIN = {
kdc = ipa.localdomain
admin_server = ipa.localdomain
}
[domain_realm]
.localdomain = LOCALDOMAIN
localdomain = LOCALDOMAIN
default_domain = localdomain
[libdefaults]
default_realm = LOCALDOMAIN
The following lets me think the KRB5 part of the setup is done correctly:
root@client2:/etc# kinit admin
Password for admin@LOCALDOMAIN:
root@client2:/etc# kdestroy
root@client2:/etc# kinit tester
Password for tester@LOCALDOMAIN:
root@client2:/etc# klis
-su: klis: command not found
root@client2:/etc# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: tester@LOCALDOMAIN
Valid starting ExpiresService principal
08/30/13 00:35:50 08/31/13 00:35:47 krbtgt/LOCALDOMAIN@LOCALDOMAIN
root@client2:/etc# kpasswd tester
Password for tester@LOCALDOMAIN:
Enter new password:
Enter it again:
Password changed.
I guess that's the point of snapshotting 'KRB done' state (can I be wrong?)
DNS for all the hosts involved is similar to:
root@client2:/etc# nslookup ipa
Server: 192.168.137.29
Address:192.168.137.29#53
Name: ipa.localdomain
Address: 192.168.137.13
root@client2:/etc# nslookup 192.168.137.13
Server: 192.168.137.29
Address:192.168.137.29#53
13.137.168.192.in-addr.arpa name = ipa.localdomain.
Now I guess it's time for certificates, where I do have some doubts...
I've added the SSH host keys via web interface, now the cert part:
having generated the CSR afte creating the new database:
certutil -R -d . -a -g 2048 -s 'CN=client2.localdomain,O=LOCALDOMAIN'
(in the /etc/pki dir) I paste the CSR and Issue the certificate for host
(/etc/pi contains newly created cert8.db key3.dbsecmod.db )
Which of those should be used to add the cert to?
(like certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i */path/to/
*ca.crt)
All of the tries result in:
root@client2:/etc/pki# certutil -A -d /etc/pki/cert8.db -n IPA CA -t
CT,C,C -a -i ./ca.crt
certutil: function failed: security library: bad database.
root@client2:/etc/pki# certutil -A -d /etc/pki/secmod.db -n IPA CA -t
CT,C,C -a -i ./ca.crt
certutil: function failed: security library: bad database.
root@client2:/etc/pki# certutil -A -d /etc/pki/key3.db -n IPA CA -t
CT,C,C -a -i ./ca.crt
certutil: function failed: security library: bad database.
Could someone show me my mistake?
Regards
Michal
On Thu, Aug 29, 2013 at 9:00 PM, Michał Dwużnik
michal.dwuz...@gmail.comwrote:
As for now I have set up a 'known good' client on RH based distro, to get
the feeling how the config files
look like when configured correctly.
Thanks for the nice reference
M.
On Thu, Aug 29, 2013 at 7:56 PM, Rob Crittenden rcrit...@redhat.comwrote:
Michał Dwużnik wrote:
Hi folks,
did anyone succeed in connecting such an old thing recently to freeipa
server?
Is there a document (or an archive post) about connecting a 'non ipa
aware' client step by step?
I got as far as woing Kerberos with no issues, hit a wall with ldap
part..
You might try this: http://docs.fedoraproject.org/**
en-US/Fedora/17/html/FreeIPA_**Guide/linux-manual.htmlhttp://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/linux-manual.html
rob
--
Michal Dwuznik
--
Michal Dwuznik
--
Michal Dwuznik
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
