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

Reply via email to