>>>>> <snip> >>>>> Strange. Is your 389-ds instance running? If so can you run this query: >>>>> >>>>> ldapsearch -x -b 'cn=services,cn=accounts,dc=sbgrid,dc=org' >>>>> '(krbprincipalname=*sbgrid-directory*)' >>>>> >>>>> I have the feeling that the principals for your IPA server have gone away. >>>> >>>> Rather than post all the output, I filtered on the krbPrincipalName >>>> attribute. Let me know if you want to see more: >>>> >>>> dn: >>>> krbprincipalname=dogtagldap/sbgrid-directory.in.hw...@sbgrid.org,cn=servic >>>> es,cn=accounts,dc=sbgrid,dc=org >>>> krbPrincipalName: dogtagldap/sbgrid-directory.in.hw...@sbgrid.org >>>> >>>> dn: >>>> krbprincipalname=ldap/sbgrid-directory.in.hw...@sbgrid.org,cn=services,cn= >>>> accounts,dc=sbgrid,dc=org >>>> krbPrincipalName: ldap/sbgrid-directory.in.hw...@sbgrid.org >>>> >>>> dn: >>>> krbprincipalname=HTTP/sbgrid-directory.in.hw...@sbgrid.org,cn=services,cn= >>>> accounts,dc=sbgrid,dc=org >>>> krbPrincipalName: HTTP/sbgrid-directory.in.hw...@sbgrid.org >>>> >>>> >>>> >>>>> Note that when removing a replica it is often necessary to restart its >>>>> replication partners because sometimes there are old tickets cached. I've >>>>> never seen a case where principals were actually removed though. >>>>> >>>>> What version of IPA are you running, on what distro? >>>> >>>> >>>> CentOS 6.2 >>>> ipa-server-2.1.3-9.el6.x86_64 >>>> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 >>>> >>>> Thanks, >>>> Ian >>> >>> Ok, this looks good. Is the krb5kdc process running? >> >> >> It is indeed: >> >> [root@sbgrid-directory dirsrv]# kinit ian >> Password for i...@sbgrid.org: >> >> [root@sbgrid-directory dirsrv]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: i...@sbgrid.org >> >> Valid starting Expires Service principal >> 02/07/12 15:51:02 02/08/12 15:51:00 krbtgt/sbgrid....@sbgrid.org >> >> ~irl > > Hmm, very strange. It seems like your server is actually up and running ok, > am I reading this incorrectly? > > Does your command-line work: ipa user-show admin > > Perhaps those are just spurious errors in the errors log.
Sorry if that wasn't clear - aside from the errors I'm seeing now (which I didn't see before the replication broke), LDAP, Kerberos and the cli/web UI seem to work on the primary server. The problems I'm having are: 1) The secondary replica is unable to sync and 2) the errors being logged are ominous and only started appearing after this disconnect. > You might try re-creating the replica again. You've done a restart since so > it should have cleared the ticket cache. I've rebooted both, and continue to have the same issue. On the replica: [21/29]: setting up initial replication Starting replication, please wait until this has completed. [sbgrid-directory.in.hwlab] reports: Update failed! Status: [-2 - System error] creation of replica failed: Failed to start replication On the "primary": slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot contact any KDC for requested realm)) slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) `ipa-replica-manage list` on the primary still lists both... sbgrid-directory.in.hwlab: master sbgrid-directory-replica.in.hwlab: master Thanks for your continued interest. ~irl -- Ian Levesque Research Systems Architect Harvard Medical School Structural Biology Grid http://cmcd.hms.harvard.edu http://core.sbgrid.org _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users