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@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@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@sbgrid-directory ~]# ipa-replica-manage list
sbgrid-directory.in.hwlab: master

[root@sbgrid-directory-replica ~]$ ipa-replica-manage list
sbgrid-directory.in.hwlab: master
sbgrid-directory-replica.in.hwlab: master

Thanks,
Ian

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to