[Freeipa-users] Fwd: Fwd: Fwd: Scorched earth

Petr Viktorin pviktori at redhat.com
Fri Aug 30 09:03:49 UTC 2013


On 08/30/2013 10:23 AM, Bret Wortman wrote:
> Morning update. I made the change Rob suggested to
> /etc/ipa/default.conf, which appeared to work, but didn't quite. It
> asked me to back out the whole server installation and start over:
>
> [ipamaster2]# ipa-ca-install --skip-conncheck
> replica-info-ipamaster2.foo.net.gpg
> Directory Manager (existing master) password:
>
> COnfiguring certificate server (pki-tomcatd): Estimated time 3 minutes
> 30 seconds
>    [1/16]: creating certificate server user
>    [2/16]: configuring certificate server instance
> ipa         : CRITICAL failed to configure ca instance Command
> '/usr/sbin/pkispawn -s CA -f /tmp/tmpVC28HP' returned non-zero exit status 1
>
> Your system may be partly configured.
> Run/usr/sbin/ipa-server-install --uninstall to clean up.

Can you look into /var/log/ipareplica-ca-install.log? It should have 
more information on what caused pkispawn to fail.

> Configuration of CA failed.
> [ipamaster2]#
>
> Which uninstallation & cleanup I did.
>
> Now, when trying to re-install the
> replica file:
>
> [ipamaster2]# ipa-replica-install --setup-dns --no-forwarders --setup-ca
> /var/lib/ipa/replica-info-ipamaster2.foo.net.gpg
> Directory manager (existing master) password:
>
> Run connection check to master
> Check connection from replica to remote master 'ipamaster.foo.net
> <http://ipamaster.foo.net>':
>     Directory Service: Unsecure port (389): OK
>     Directory Service: Secure port (686): OK
>     Kerberos KDC: TCP (88): OK
>     Kerberos Kpasswd: TCP (464): OK
>     HTTP Server: Unsecure port (80): OK
>     HTTP Server: Secure port (443): OK
>
> The followign list of ports use UDP protocol and would need to be
> checked manually:
>     Kerberos KDC: UDP (88): SKIPPED
>     Kerberos Kpasswd: UDP (464): SKIPPED
>
> Connection from replica to master is OK.
> Start listening on required ports for remote master check
> Get credentials to log in to remote master
> admin at FOO.NET <mailto:admin at FOO.NET> password:
>
> Check SSH connection to remote master
> Execute check on remote master
> Check connection from master to remote replica 'ipamaster2.foo.net
> <http://ipamaster2.foo.net>':
>     Directory Service: Unsecure port (389): OK
>     Directory Service: Secure port (686): OK
>     Kerberos KDC: TCP (88): OK
>     Kerberos KDC: UDP (88): OK
>     Kerberos Kpasswd: TCP (464): OK
>     Kerberos Kpasswd: UDP (464): OK
>     HTTP Server: Unsecure port (80): OK
>     HTTP Server: Secure port (443): OK
>
> Connection from master to replica is OK.
>
> Connection check OK
> The host ipamaster2.foo.net <http://ipamaster2.foo.net> already exists
> on the master server.
> You should remove it before proceeding:
>      % ipa host-del ipamaster2.foo.net <http://ipamaster2.foo.net>
> ipa         : ERROR    Could not resolve hostname ipamaster.foo.net
> <http://ipamaster.foo.net> using DNS Clients may not function properly.
> Please check your DNS setup. (Note that this check queries IPA DNS
> directly and ignores /etc/hosts.)
> Continue? [no]: *yes*
> [ipamaster2]# host ipamaster.foo.net <http://ipamaster.foo.net>
> ipamaster.foo.net <http://ipamaster.foo.net> has address 1.2.3.4
>
> No matter what answer I give to the "Continue?" prompt, it just exits.
> "nslookup" returns the same value, and I have three different
> nameservers configured for this host (including ipamaster and two of the
> older replicas).

The error that caused the installation to fail is that 
ipamaster2.foo.net already exists on the master server.

The DNS warning and its "Continue?" prompt is unrelated, but the order 
of the output is very confusing. I've filed ticket 3889 for this.
Anyway, to do this DNS resolution check you'd need to explicitly ask for 
the IPA server:
$ dig @ipamaster.foo.net ipamaster2.foo.net

> And this message is the one that has prompted me to want to delete hosts
> before installing in the past, Simo.
>
> Any thoughts on how best to proceed now?

I believe you do need to delete he host at this point, but I'd rather 
have Rob or Simo confirm.

> *Bret Wortman*
>
> http://damascusgrp.com/
> http://about.me/wortmanbret
>
>
> On Thu, Aug 29, 2013 at 2:59 PM, Rob Crittenden <rcritten at redhat.com
> <mailto:rcritten at redhat.com>> wrote:
>
>     Bret Wortman wrote:
>
>         Okay, I got the cacert.p12 (turns out it was taking my
>         passphrase, but
>         the messages looked like errors to my addled eyes). This system
>         is on a
>         different network, so getting the file transferred would take me
>         about
>         24 hours. Is there something I can get that'll tell you what you
>         need
>         but is plaintext?
>
>
>     Ok, that's fine.
>
>     Try this. Set ra_plugin to dogtag in /etc/ipa/default.conf. This
>     will let it get past the error and it should install a CA. I'm
>     trying to think worst case scenario what it might do and I'm not
>     coming up with anything. I think the worst that happens is that
>     adding a CA fails later.
>
>     rob
>
>
>         I tried this and hope this subset of information is helpful:
>
>         # openssl pkcs12 -in cacert.p12 -out cacert.pem.bdw -cacerts -nokeys
>         # cat cacert.pem.bdw
>         Bag Attributes: <No Attributes>
>         subject=/O=FOO.NET/CN=__Certificate
>         <http://FOO.NET/CN=Certificate>
>         <http://FOO.NET/CN=Certificate__> Authority/
>         issuer=/O=FOO.NET/CN=__Certificate
>         <http://FOO.NET/CN=Certificate>
>         <http://FOO.NET/CN=Certificate__> Authority
>
>         -----BEGIN CERTIFICATE-----
>         MIIDgzCCA...
>         ...Iwk4r
>         -----END CERTIFICATE-----
>         # openssl pkcs12 -in cacert.p12 -out cert.pem.bdw -clcerts -nokeys
>         # cat cert.pem.bdw
>         Bag Attributes:
>               localKeyID: 82 81 2D 6E 5C 13 43 9A 5F BB C8 4D F5 6B DE
>         6C A7 2E 53 88
>               friendlyName: caSigningCert cert-pki-ca
>         subject=/O=FOO.NET/CN=__Certificate
>         <http://FOO.NET/CN=Certificate>
>         <http://FOO.NET/CN=Certificate__> Authority
>         issuer=/O=FOO.NET/CN=__Certificate
>         <http://FOO.NET/CN=Certificate>
>         <http://FOO.NET/CN=Certificate__> Authority
>
>         -----BEGIN CERTIFICATE-----
>         MIIDgzCCA...
>         ...Iwk4r
>         -----END CERTIFICATE-----
>         Bag Attributes:
>               localKeyID: 88 BF DF 56 30 BB A9 47 12 D4 5F 7B AE 39 DC
>         BF CF F5 92 22
>               friendlyName: ocspSigningCert cert-pki-ca
>         subject=/O=FOO.NET/CN=OCSP <http://FOO.NET/CN=OCSP>
>         <http://FOO.NET/CN=OCSP> Subsystem
>         issuer=/O=FOO.NET/CN=__Certificate
>         <http://FOO.NET/CN=Certificate>
>         <http://FOO.NET/CN=Certificate__> Authority
>
>         -----BEGIN CERTIFICATE-----
>         MIIDYTCCA...
>         ...wlr4Q=
>         -----END CERTIFICATE-----
>         Bag Attributes:
>               localKeyID: B5 3B 27 CC 57 72 45 E2 8D 46 C9 5E E1 C0 50
>         DF 2D 11 62 0E
>               friendlyName: subsystemCert cert-pki-ca
>         subject=/O=FOO.NET/CN=CA <http://FOO.NET/CN=CA>
>         <http://FOO.NET/CN=CA> Subsystem
>         issuer=/O=FOO.NET/CN=__Certificate
>         <http://FOO.NET/CN=Certificate>
>         <http://FOO.NET/CN=Certificate__> Authority
>
>         -----BEGIN CERTIFICATE-----
>         MIIDaTCCA...
>         ...BxqqA==
>         -----END CERTIFICATE-----
>         Bag Attributes:
>               localKeyID: 1F 69 62 C7 88 D8 95 2A B1 7D 61 F9 10 87 14
>         D0 76 Ba B9 44
>               friendlyName: auditSigningCert cert-pki-ca
>         subject=/O=FOO.NET/CN=CA <http://FOO.NET/CN=CA>
>         <http://FOO.NET/CN=CA> Audit
>         issuer=/O=FOO.NET/CN=__CertificateAUthority
>         <http://FOO.NET/CN=CertificateAUthority>
>         <http://FOO.NET/CN=__CertificateAUthority
>         <http://FOO.NET/CN=CertificateAUthority>>
>
>         -----BEGIN CERTIFICATE-----
>         MIIDRDCCA...
>         ...EAd+Ug7
>         -----END CERTIFICATE-----
>         # openssl pkcs12 -in cacert.p12 -out key.pem.bdw -nocerts
>         # cat key.pem.bdw
>         Bag Attributes
>               localKeyID: 82 81 2D 6E 5C 13 43 9A 5F BB C8 4D F5 6B DE
>         6C A7 2E 53 88
>               friendlyName: CN=Certificate Authority,O=FOO.NET
>         <http://FOO.NET> <http://FOO.NET>
>
>         Key Attributes: <No Attributes>
>         -----BEGIN ENCRYPTED PRIVATE KEY-----
>         MIIFDjBAB...
>         ...XLtoD8=
>         -----END ENCRYPTED PRIVATE KEY-----
>         Bag Attributes
>               localKeyID:  <let me know if you need this>
>               friendlyName: CN=OCSP Subsystem,O=FOO.NET <http://FOO.NET>
>         <http://FOO.NET>
>
>         Key Attributes: <No Attributes>
>         -----BEGIN ENCRYPTED PRIVATE KEY-----
>         :
>         -----END ENCRYPTED PRIVATE KEY-----
>         Bag Attributes
>               localKeyID:  <let me know if you need this>
>               friendlyName: CN=CA Subsystem,O=FOO.NET <http://FOO.NET>
>         <http://FOO.NET>
>
>         Key Attributes: <No Attributes>
>         Bag Attributes
>               localKeyID:  <let me know if you need this>
>               friendlyName: CN=CA Audit,O=FOO.NET <http://FOO.NET>
>         <http://FOO.NET>
>
>         Key Attributes: <No Attributes>
>
>         If you need to see anything else, please let me know.
>
>
>         _
>         _
>         *Bret Wortman*
>
>
>         http://damascusgrp.com/
>         http://about.me/wortmanbret
>
>
>         On Thu, Aug 29, 2013 at 11:58 AM, Rob Crittenden
>         <rcritten at redhat.com <mailto:rcritten at redhat.com>
>         <mailto:rcritten at redhat.com <mailto:rcritten at redhat.com>>> wrote:
>
>              Bret Wortman wrote:
>
>                  On Thu, Aug 29, 2013 at 11:40 AM, Rob Crittenden
>                  <rcritten at redhat.com <mailto:rcritten at redhat.com>
>         <mailto:rcritten at redhat.com <mailto:rcritten at redhat.com>>
>                  <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com> <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com>>>>____wrote:
>
>                       Bret Wortman wrote:
>
>                           On Thu, Aug 29, 2013 at 11:10 AM, Rob Crittenden
>                           <rcritten at redhat.com
>         <mailto:rcritten at redhat.com> <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com>>
>                  <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com> <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com>>>
>                           <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com>
>                  <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com>> <mailto:rcritten at redhat.com
>         <mailto:rcritten at redhat.com>
>                  <mailto:rcritten at redhat.com
>         <mailto:rcritten at 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 at 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 at .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 at .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 at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>


-- 
Petr³




More information about the Freeipa-users mailing list