SOLVED! Thank you Flo! That did the trick. Once I made the change to the certificate and restarted the IPA services everything came back up like it was supposed to.
High five! *Mike Plemmons | Senior DevOps Engineer | CROSSCHX* 614.427.2411 mike.plemm...@crosschx.com www.crosschx.com On Thu, May 18, 2017 at 10:28 AM, Florence Blanc-Renaud <f...@redhat.com> wrote: > On 05/18/2017 03:49 PM, Michael Plemmons wrote: > >> >> >> >> >> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX >> * >> 614.427.2411 >> mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com> >> www.crosschx.com <http://www.crosschx.com/> >> >> On Thu, May 18, 2017 at 8:02 AM, Florence Blanc-Renaud <f...@redhat.com >> <mailto:f...@redhat.com>> wrote: >> >> On 05/15/2017 08:33 PM, Michael Plemmons wrote: >> >> I have done more searching in my logs and I see the following >> errors. >> >> This is in the localhost log file /var/lib/pki/pki-tomcat/logs >> >> May 15, 2017 3:08:08 PM >> org.apache.catalina.core.ApplicationContext log >> SEVERE: StandardWrapper.Throwable >> java.lang.NullPointerException >> >> May 15, 2017 3:08:08 PM org.apache.catalina.core.StandardContext >> loadOnStartup >> SEVERE: Servlet [castart] in web application [/ca] threw load() >> exception >> java.lang.NullPointerException >> >> May 15, 2017 3:08:09 PM >> org.apache.catalina.core.StandardHostValve invoke >> SEVERE: Exception Processing /ca/admin/ca/getStatus >> javax.ws.rs <http://javax.ws.rs> >> <http://javax.ws.rs>.ServiceUnavailableException: Subsystem >> unavailable >> >> >> Looking at the debug log it says Authentication failed for port >> 636. >> >> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: >> init() >> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: >> init begins >> [15/May/2017:17:39:25][localhost-startStop-1]: LdapAuthInfo: >> init ends >> [15/May/2017:17:39:25][localhost-startStop-1]: init: before >> makeConnection errorIfDown is true >> [15/May/2017:17:39:25][localhost-startStop-1]: makeConnection: >> errorIfDown true >> [15/May/2017:17:39:25][localhost-startStop-1]: >> SSLClientCertificateSelectionCB: Setting desired cert nickname >> to: >> subsystemCert cert-pki-ca >> [15/May/2017:17:39:25][localhost-startStop-1]: LdapJssSSLSocket: >> set >> client auth cert nickname subsystemCert cert-pki-ca >> [15/May/2017:17:39:25][localhost-startStop-1]: >> SSLClientCertificatSelectionCB: Entering! >> [15/May/2017:17:39:25][localhost-startStop-1]: >> SSLClientCertificateSelectionCB: returning: null >> [15/May/2017:17:39:25][localhost-startStop-1]: SSL handshake >> happened >> Could not connect to LDAP server host ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>> port 636 Error >> netscape.ldap.LDAPException: Authentication failed (48) >> at >> com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConne >> ction(LdapBoundConnFactory.java:205) >> >> >> I looked at the validity of the cert it mentions and it is fine. >> >> (root)>getcert status -v -d /etc/pki/pki-tomcat/alias -n >> 'subsystemCert >> cert-pki-ca' >> State MONITORING, stuck: no. >> >> >> I then looked at the ldap errors around the time of this failure >> and I >> am seeing this log entry. >> >> >> [15/May/2017:17:38:42.063080758 +0000] set_krb5_creds - Could >> not get >> initial credentials for principal >> [ldap/ipa12.mgmt.crosschx....@mgmt.crosschx.com >> <mailto:ipa12.mgmt.crosschx....@mgmt.crosschx.com> >> <mailto:ipa12.mgmt.crosschx....@mgmt.crosschx.com >> <mailto:ipa12.mgmt.crosschx....@mgmt.crosschx.com>>] in keytab >> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any >> KDC for >> requested realm) >> >> When I perform a klist against that keytab nothing appears out >> of the >> ordinary compared to working IPA servers. >> >> I am not sure what to look at next. >> >> >> Hi, >> >> you can try the following to manually replay the connection >> established by Dogtag to LDAP server: >> >> root$ export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias >> root$ export LDAPTLS_CERT='subsystemCert cert-pki-ca' >> >> The above commands specify the NSSDB containing the user certificate >> and its name for SASL-EXTERNAL authentication. >> >> Then note the value obtained below as it will be used for the next >> step as the password to access the private key in the NSSDB: >> root$ grep internal /etc/pki/pki-tomcat/password.conf >> internal=<some value> >> >> root$ ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL >> -Q -LLL dn namingcontexts >> Please enter pin, password, or pass phrase for security token >> 'ldap(0)': <<<< here supply the value found >> above >> dn: >> namingcontexts: cn=changelog >> namingcontexts: dc=ipadomain,dc=com >> namingcontexts: o=ipaca >> >> >> >> So I guess I found my problem. >> >> (root)>ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL -Q >> -LLL dn namingcontexts >> Please enter pin, password, or pass phrase for security token 'ldap(0)': >> ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) >> additional info: TLS error -12195:Peer does not recognize and trust >> the CA that issued your certificate. >> >> >> I looked at our certs in /etc/dirsrv/slapd-IPADOMAIN-COM and found the >> following. >> >> IPA12 - problem server >> (root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> Server-Cert u,u,u >> IPADOMAIN-COM IPA CA C,, >> >> >> >> IPA11/IPA13 - 11 was the master and 13 is the new master >> (root)>certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM >> >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> >> Server-Cert u,u,u >> IPADOMAIN-COM IPA CA CT,C,C >> >> >> >> Good news! In this case the fix is trivial: > root$ certutil -M -d /etc/dirsrv/slapd-IPADOMAIN-COM -n 'IPADOMAIN-COM > IPA CA' -t CT,C,C > > Flo. > >> >> In the LDAP server access log (in >> /etc/dirsrv/slapd-IPADOMAIN.COM/access), you should see the >> corresponding connection: >> >> [18/May/2017:13:35:14.822090417 +0200] conn=297 fd=150 slot=150 SSL >> connection from xxx to yyy >> [18/May/2017:13:35:15.789414017 +0200] conn=297 TLS1.2 128-bit >> AES-GCM; client CN=CA Subsystem,O=IPADOMAIN.COM >> <http://IPADOMAIN.COM>; issuer CN=Certificate >> Authority,O=IPADOMAIN.COM <http://IPADOMAIN.COM> >> [18/May/2017:13:35:15.793108509 +0200] conn=297 TLS1.2 client bound >> as uid=pkidbuser,ou=people,o=ipaca >> [18/May/2017:13:35:15.798101505 +0200] conn=297 op=0 BIND dn="" >> method=sasl version=3 mech=EXTERNAL >> [18/May/2017:13:35:15.800322076 +0200] conn=297 op=0 RESULT err=0 >> tag=97 nentries=0 etime=0 dn="uid=pkidbuser,ou=people,o=ipaca" >> >> HTH, >> Flo. >> >> >> >> >> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX >> * >> 614.427.2411 >> mike.plemm...@crosschx.com <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> www.crosschx.com <http://www.crosschx.com> >> <http://www.crosschx.com/> >> >> On Wed, May 10, 2017 at 3:35 PM, Michael Plemmons >> <michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>>> >> wrote: >> >> The PKI service came up successfully but only when it uses >> BasicAuth >> rather than SSL auth. I am not sure about what I need to do >> in >> order to get the auth working over SSL again. >> >> None of the certs are expired when I run getcert list and >> ipa-getcert list. >> >> Since the failure is with attempts to login to LDAP over >> 636. I >> have been attempting to auth to LDAP via port 636 and the >> ldapsearch >> is not completing. When looking at packet captures, I see >> some the >> TCP handshake and what appears to be the start of a SSL >> process and >> then everything hangs. >> >> What is the proper method to test performing a ldapsearch >> over 636? >> Also, the CS.cfg shows it wants to auth as cn=Directory >> Manager. I >> can successfully auth with cn=Directory Manager over 389 but >> I think >> I am not performing ldapsearch over 636 correctly. >> >> >> >> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX >> * >> 614.427.2411 >> mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> www.crosschx.com <http://www.crosschx.com> >> <http://www.crosschx.com/> >> >> On Fri, May 5, 2017 at 3:33 PM, Michael Plemmons >> <michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>>> wrote: >> >> I think I found the email thread. Asking for help with >> crashed >> freeIPA istance. That email pointed to this >> link, >> https://www.redhat.com/archives/freeipa-users/2017-January/ >> msg00215.html >> <https://www.redhat.com/archives/freeipa-users/2017-January/ >> msg00215.html> >> >> <https://www.redhat.com/archives/freeipa-users/2017-January/ >> msg00215.html >> <https://www.redhat.com/archives/freeipa-users/2017-January/ >> msg00215.html>>. >> That link talked about changing the CS.cfg file to use >> port 389 >> for PKI to auth to LDAP. I made the necessary changes >> and PKI >> came up successfully. >> >> >> >> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX >> * >> 614.427.2411 >> mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> www.crosschx.com <http://www.crosschx.com> >> <http://www.crosschx.com/> >> >> On Fri, May 5, 2017 at 3:19 PM, Michael Plemmons >> <michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>>> wrote: >> >> >> >> >> >> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX >> * >> 614.427.2411 >> mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> www.crosschx.com <http://www.crosschx.com> >> <http://www.crosschx.com/> >> >> On Fri, May 5, 2017 at 3:15 PM, Rob Crittenden >> <rcrit...@redhat.com <mailto:rcrit...@redhat.com> >> <mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>> wrote: >> >> Michael Plemmons wrote: >> > I just realized that I sent the reply directly >> to Rob >> and not to the >> > list. My response is inline >> >> Ok, this is actually good news. >> >> I made a similar proposal in another case and I >> was >> completely wrong. >> Flo had the user do something and it totally >> fixed their >> auth error, I >> just can't remember what it was or find the e-mail >> thread. I'm pretty >> sure it was this calendar year though. >> >> rob >> >> >> Do you or Flo know what I could search for in the past >> emails to find the answer to the problem? >> >> >> >> > >> > >> > >> > *Mike Plemmons | Senior DevOps Engineer | >> CROSSCHX >> > * >> > 614.427.2411 >> > mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>>> >> > www.crosschx.com <http://www.crosschx.com> >> <http://www.crosschx.com> >> <http://www.crosschx.com/> >> > >> > On Thu, May 4, 2017 at 9:39 AM, Michael Plemmons >> > <michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>>>> >> > wrote: >> > >> > >> > >> > >> > >> > *Mike Plemmons | Senior DevOps Engineer | >> CROSSCHX >> > * >> > 614.427.2411 >> > mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>>> >> > www.crosschx.com <http://www.crosschx.com> >> <http://www.crosschx.com> >> <http://www.crosschx.com/> >> > >> > On Thu, May 4, 2017 at 9:24 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: >> > >> > Michael Plemmons wrote: >> > > I realized that I was not very clear >> in my >> statement about >> > testing with >> > > ldapsearch. I had initially run it >> without >> logging in with a >> > DN. I was >> > > just running the local ldapsearch -x >> command. I then tested on >> > > ipa12.mgmt and ipa11.mgmt logging in >> with a >> full DN for the >> > admin and >> > > "cn=Directory Manager" from ipa12.mgmt >> (broken server) and >> > ipa11.mgmt >> > > and both ldapsearch command succeeded. >> > > >> > > I ran the following from ipa12.mgmt >> and >> ipa11.mgmt as a non >> > root user. >> > > I also ran the command showing a >> line count >> for the output and >> > the line >> > > counts for each were the same when >> run from >> ipa12.mgmt and >> > ipa11.mgmt. >> > > >> > > ldapsearch -LLL -h >> ipa12.mgmt.crosschx.com <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>> >> > <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>>> >> > > <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>> >> > <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>>>> -D "DN" -w PASSWORD -b >> > > >> "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" >> dn >> > > >> > > ldapsearch -LLL -h >> ipa12.mgmt.crosschx.com <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>> >> > <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>>> >> > > <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>> >> > <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>>>> -D "cn=directory >> manager" -w >> > PASSWORD dn >> > >> > The CA has its own suffix and >> replication >> agreements. Given the auth >> > error and recent (5 months) renewal of >> CA >> credentials I'd check >> > that the >> > CA agent authentication entries are >> correct. >> > >> > Against each master with a CA run: >> > >> > $ ldapsearch -LLL -x -D 'cn=directory >> manager' >> -W -b >> > uid=ipara,ou=people,o=ipaca description >> > >> > The format is 2;serial#,subject,issuer >> > >> > Then on each run: >> > >> > # certutil -L -d /etc/httpd/alias -n >> ipaCert >> |grep Serial >> > >> > The serial # should match that in the >> description everywhere. >> > >> > rob >> > >> > >> > >> > On the CA (IPA13.MGMT) I ran the ldapsearch >> command and see that the >> > serial number is 7. I then ran the certutil >> command on all three >> > servers and the serial number is 7 as well. >> > >> > >> > I also ran the ldapsearch command against >> the >> other two servers and >> > they also showed a serial number of 7. >> > >> > >> > >> > >> > > >> > > >> > > >> > > >> > > >> > > *Mike Plemmons | Senior DevOps >> Engineer | >> CROSSCHX >> > > * >> > > 614.427.2411 >> > > mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>>> >> > <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>> >> > <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com> >> <mailto:mike.plemm...@crosschx.com >> <mailto:mike.plemm...@crosschx.com>>>> >> > > www.crosschx.com >> <http://www.crosschx.com> <http://www.crosschx.com> >> <http://www.crosschx.com> >> > <http://www.crosschx.com/> >> > > >> > > On Wed, May 3, 2017 at 5:28 PM, >> Michael Plemmons >> > > <michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>> >> > <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>>> >> > <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>> >> > <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com> >> <mailto:michael.plemm...@crosschx.com >> <mailto:michael.plemm...@crosschx.com>>>>> >> > > wrote: >> > > >> > > I have a three node IPA cluster. >> > > >> > > ipa11.mgmt - was a master over 6 >> months ago >> > > ipa13.mgmt - current master >> > > ipa12.mgmt >> > > >> > > ipa13 has agreements with ipa11 >> and >> ipa12. ipa11 and >> > ipa12 do not >> > > have agreements between each >> other. >> > > >> > > It appears that either >> ipa12.mgmt lost >> some level of its >> > replication >> > > agreement with ipa13. I saw >> some level >> because users / >> > hosts were >> > > replicated between all systems >> but we >> started seeing DNS >> > was not >> > > resolving properly from ipa12. >> I do not >> know when this >> > started. >> > > >> > > When looking at replication >> agreements >> on ipa12 I did not >> > see any >> > > agreement with ipa13. >> > > >> > > When I run ipa-replica-manage >> list all >> three hosts show >> > has master. >> > > >> > > When I run ipa-replica-manage >> ipa11.mgmt >> I see ipa13.mgmt >> > is a replica. >> > > >> > > When I run ipa-replica-manage >> ipa12.mgmt >> nothing returned. >> > > >> > > I ran ipa-replica-manage connect >> --cacert=/etc/ipa/ca.crt >> > > ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>>> >> > <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com> >> <http://ipa12.mgmt.crosschx.com >> <http://ipa12.mgmt.crosschx.com>>>> >> > > ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>>> >> > <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>> >> > <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>>>> on ipa12.mgmt >> > > >> > > I then ran the following >> > > >> > > ipa-replica-manage force-sync >> --from >> > ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>>> >> > > <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>> >> > <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>>>> >> > > >> > > ipa-replica-manage re-initialize >> --from >> > ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>>> >> > > <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>> >> > <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com> >> <http://ipa13.mgmt.crosschx.com >> <http://ipa13.mgmt.crosschx.com>>>> >> > > >> > > I was still seeing bad DNS >> returns when >> dig'ing against >> > ipa12.mgmt. >> > > I was able to create user and DNS >> records and see the >> > information >> > > replicated properly across all >> three nodes. >> > > >> > > I then ran ipactl stop on >> ipa12.mgmt and >> then ipactl start on > >
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
