Bret Wortman wrote:
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?
It's the same passphrase you'd use to install a replica, the DM password. rob
_ _ *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Aug 29, 2013 at 11:58 AM, Rob Crittenden <rcrit...@redhat.com <mailto:rcrit...@redhat.com>> wrote: Bret Wortman wrote: On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden <rcrit...@redhat.com <mailto:rcrit...@redhat.com> <mailto: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>> <mailto: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 Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users