[Freeipa-users] Replicas in a state of confusion

[Ian Levesque]

>>>>> <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.hwlab at SBGRID.ORG,cn=servic
>>>>  es,cn=accounts,dc=sbgrid,dc=org
>>>> krbPrincipalName: dogtagldap/sbgrid-directory.in.hwlab at SBGRID.ORG
>>>> 
>>>> dn: krbprincipalname=ldap/sbgrid-directory.in.hwlab at SBGRID.ORG,cn=services,cn=
>>>>  accounts,dc=sbgrid,dc=org
>>>> krbPrincipalName: ldap/sbgrid-directory.in.hwlab at SBGRID.ORG
>>>> 
>>>> dn: krbprincipalname=HTTP/sbgrid-directory.in.hwlab at SBGRID.ORG,cn=services,cn=
>>>>  accounts,dc=sbgrid,dc=org
>>>> krbPrincipalName: HTTP/sbgrid-directory.in.hwlab at 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 at sbgrid-directory dirsrv]# kinit ian
>> Password for ian at SBGRID.ORG:
>> 
>> [root at sbgrid-directory dirsrv]# klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: ian at SBGRID.ORG
>> 
>> Valid starting     Expires            Service principal
>> 02/07/12 15:51:02  02/08/12 15:51:00  krbtgt/SBGRID.ORG at 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