[Freeipa-users] Replicas in a state of confusion

[Rich Megginson]

On 02/09/2012 03:21 PM, Ian Levesque wrote:
> On Feb 9, 2012, at 4:59 PM, Rich Megginson wrote:
>
>>>> I think you failed to properly clean=up before reinstalling the replica.
>>>>
>>>> On the replica make sure you run:
>>>> ipa-server-install --uninstall
>>>>
>>>> On the primary:
>>>> ipa-replica-manage --force del sbgrid-directory-replica.in.hwlab
>>>>
>>>> You will have to force because you already removed the replica.
>>>>
>>>> Once you do that you can generate a new replica file for the replica and
>>>> retry to set up replication.
>>>>
>>>> Let me know if you encounter any other error once you have done that.
>>> I tried what you suggested and today, the replication did complete.
>>>
>>> That said, there were a bunch of errors on the initial master, including:
>>>
>>> id2entry - str2entry returned NULL for id 12, string="rdn"
>>> _entry_set_tombstone_rdn - Failed to convert DN automountmapname=auto.direct to RDN
>>> (snip - continues for each automountmapname cn entry)
>> What version of 389-ds-base are you running?  rpm -qi 389-ds-base
> [root at sbgrid-directory ~]# rpm -qa | grep -e 389 -e ipa | sort
> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64
> 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
> ipa-admintools-2.1.3-9.el6.x86_64
> ipa-client-2.1.3-9.el6.x86_64
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> ipa-pki-common-theme-9.0.3-7.el6.noarch
> ipa-python-2.1.3-9.el6.x86_64
> ipa-server-2.1.3-9.el6.x86_64
> ipa-server-selinux-2.1.3-9.el6.x86_64
>
> [root at sbgrid-directory-replica ~]$ rpm -qa | grep -e 389 -e ipa | sort
> 389-ds-base-1.2.9.14-1.el6_2.2.x86_64
> 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64
> ipa-admintools-2.1.3-9.el6.x86_64
> ipa-client-2.1.3-9.el6.x86_64
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> ipa-pki-common-theme-9.0.3-7.el6.noarch
> ipa-python-2.1.3-9.el6.x86_64
> ipa-server-2.1.3-9.el6.x86_64
> ipa-server-selinux-2.1.3-9.el6.x86_64
This may be related to https://fedorahosted.org/389/ticket/273 and 
https://fedorahosted.org/389/ticket/274 which have been fixed in 1.2.10
>
>>> NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=sbgrid,dc=org: 20
>>> (repeated several times)
>> We believe this is benign.
>>
>>> slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context)
>>> slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials)
>>> (repeated several times)
>>>
>>> NSMMReplicationPlugin - agmt="cn=meTosbgrid-directory-replica.in.hwlab" (sbgrid-directory-replica:389): Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context)
>> err=49 either means the kerberos credentials are incorrect, or the sasl mapping of the principal to the DN of the entry failed
> OK, that's good to know. So, assuming the problem is that there was an invalid cached credential getting in the way, here's what I did to attempt a reconfiguration of the replica:
>
> replica: ipa-server-install --uninstall&&  reboot
> primary: ipa-replica-manage --force del sbgrid-directory-replica.in.hwlab&&  reboot
> primary: ipa-replica-prepare sbgrid-directory-replica.in.hwlab&  rsync ...
> replica: ipa-replica-install ./replica-info-sbgrid-directory-replica.in.hwlab.gpg
>
> The outcome was the same.
> Error logs from primary: http://pastebin.com/raw.php?i=jKnjZgwQ
>
> [root at sbgrid-directory ~]# ipa-replica-manage list
> sbgrid-directory.in.hwlab: master
>
> [root at sbgrid-directory-replica ~]$ ipa-replica-manage list
> sbgrid-directory.in.hwlab: master
> sbgrid-directory-replica.in.hwlab: master
>
> Thanks,
> Ian