https://bugzilla.redhat.com/show_bug.cgi?id=755119
Description of problem: There appears to be a race failing when the DNA Plugin attempts to make a uid range replication request backed by gssapi. Version-Release number of selected component (if applicable): 389-ds-base-libs-1.2.10-0.5.a5.fc15.x86_64 389-ds-base-1.2.10-0.5.a5.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install IPA Server (ipa-server-install) 2. Prepare Replica (ipa-replica-prepare replica-hostname) 3. Transfer resulting replica-hostname.gpg 4. Install Replica (ipa-replica-install replica-hostname.gpg) 5. kinit admin 6. Attempt to create new user (ipa user-add test) Actual results: ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. Expected results: Expected new user to be added and range to be transferred. Additional info:
I managed to reproduce the problem. With plain 389 I set up 3 way MMR with SASL/GSSAPI, and dna. I used an IPA-like DNA configuration - for the first master I use dnanextvalue: 1101 dnamaxvalue: 999999
For subsequent masters I use dnanextvalue: 1100
So that an add user request against one of the other masters will trigger a DNA range request. Then I just add users round robin among the masters. I'm using localhost.localdomain for my hostname, and in the keytabs. I had to hack directory server to allow me to bypass the typical sasl and kerberos hostname lookups. I had to do this to force the use of the loopback interface for my testing. This setup runs fine - I can add thousands of users, range requests work fine.
However, if I add a loopback delay using tc: tc qdisc add dev lo root netem delay 500ms
I get the following error in the other master error log: [17/Jan/2012:15:50:51 -0700] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [cn=replrepl,cn=config] mech [GSSAPI]: error -1 (Can't contact LDAP server) ((null)) [17/Jan/2012:15:50:51 -0700] slapi_ldap_bind - Error: could not perform interactive bind for id [cn=replrepl,cn=config] mech [GSSAPI]: error -1 (Can't contact LDAP server) [17/Jan/2012:15:50:51 -0700] dna-plugin - dna_request_range: Error binding to replica server localhost.localdomain:1389. [error -1] [17/Jan/2012:15:50:51 -0700] dna-plugin - dna_get_next_value: no more values available!!
0001-Ticket-12-389-DS-DNA-Plugin-Replication-failing-on-G.patch 0001-Ticket-12-389-DS-DNA-Plugin-Replication-failing-on-G.patch
0001-add-a-hack-to-disable-sasl-hostname-canonicalization.patch 0001-add-a-hack-to-disable-sasl-hostname-canonicalization.patch
To ssh://git.fedorahosted.org/git/389/ds.git 48e99c1..7bbce96 master -> master commit changeset:7bbce96/389-ds-base Author: Rich Megginson rmeggins@redhat.com Date: Wed Jan 18 11:01:35 2012 -0700 Reviewed by: nhosoi (Thanks!) Branch: master Fix Description: The problem is due to timeout. The default DNA range reque timeout is 10ms, which is far too short in WAN environments. The fix is two fold 1) make the default DNA range request timeout 10 minutes, the same as the default replication timeout 2) openldap uses errno to report the timeout, so be sure to print the errno and message when we get connection/bind failures. Platforms tested: RHEL6 x86_64 Flag Day: no Doc impact: no commit changeset:6aaeb77/389-ds-base Author: Rich Megginson rmeggins@redhat.com Date: Mon Dec 19 09:17:54 2011 -0700 add a hack to disable sasl hostname canonicalization - helps with testing when you don't want to set up correct host name resolution and/or cannot set the default system hostname export HACK_SASL_NOCANON=1 before starting the server (e.g. in the /etc/sysconfig/dirsrv file along with the keytab and other env vars) Reviewed by: nhosoi (Thanks!)
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=788741
Added initial screened field value.
Metadata Update from @rmeggins: - Issue assigned to rmeggins - Issue set to the milestone: 1.2.10.a7
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/12
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.