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.com>wrote: > 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 Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users