#7117 "401 Unauthorized:" error on parallel requests
Closed: fixed 2 years ago by rcritten. Opened 3 years ago by zultron.

The Ansible ipa_* modules talk to FreeIPA via json requests over http. It seems that when doing multiple requests in parallel, sometimes some of the requests may fail. Here is example Ansible output for two requests in parallel:

failed: [host1 -> localhost] (item={u'host': u'host1', u'a_rec': u''}) => {"failed": true, "item": {"a_rec": "", "host": "host1"}, "msg": "login: HTTP Error 401: Unauthorized", "requests": [], "responses": {}}
changed: [host2 -> localhost] => (item={u'host': u'host2', u'a_rec': u''})

Here are the corresponding httpd error logs on the FreeIPA side:

[Wed Aug 23 18:14:57.596730 2017] [:error] [pid 3189] ipa: INFO: 401 Unauthorized: kinit: Error constructing AP-REQ armor: No credentials cache found (filename: /var/run/ipa_memcached/krbcc_A_admin) while getting initial credentials
[Wed Aug 23 18:14:57.597427 2017] [:error] [pid 3189]
[Wed Aug 23 18:14:58.772824 2017] [:error] [pid 3189] ipa: INFO: [jsonserver_session] admin@EXAMPLE.COM: dnsrecord_find(u'example.com', None, idnsname=<DNS name host2>, all=True): SUCCESS
[Wed Aug 23 18:14:59.641660 2017] [:error] [pid 3190] ipa: INFO: [jsonserver_session] admin@EXAMPLE.COM: dnsrecord_add(u'example.com', <DNS name host2>, addattr=(u'arecord=',), all=True): SUCCESS

This error seems never to happen with a single request; with two requests it's pretty rare; and three requests seem to fail very often. One (at least?) of the parallel requests will always succeed.

Hello @zultron

The directory: .../ipa_memcached/... implies usage of memcached. FreeIPA 4.5 no longer use it so I expect that this is 4.4 or earlier.

What exact version of IPA this is? There was similar bug in some older version which was fixed.

Hi @pvoborni,

You're right about the version. I'm using the freeipa-container project: the centos-7 image tag is v. 4.4.0, reported above, and the fedora-25 tag is 4.4.4, problem reproduced. (I've built an f26 image with packages from the official freeipa 4.5 COPR, but ipa-server-install fails during the final ipa-client-install step....)

I couldn't find the similar bug you remember, either by googling or by searching here on pagure. If you happen to have a link, I'd be interested to look at the fix.

reminds me #5653 but it is not the same bug.

Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.6.1

3 years ago

Metadata Update from @tkrizek:
- Issue set to the milestone: FreeIPA 4.6.2 (was: FreeIPA 4.6.1)

3 years ago

This is pretty easy to duplicate in master but I've yet to determine the cause.

I'm using this script:

for i in 1 2 3 4 5
    curl -0 -v --negotiate -u : -H "Referer: https://`hostname`/ipa/json" -H "Content-Type: application/json" -d @post.json https://`hostname`/ipa/json 2>&1 | grep "< HTTP/" &

$ cat post.json 
    "id": 0,
    "method": "user_show/1",
    "params": [
            "version": "2.229"

One thing of interest is that if you drop making curl a background job and add sleep 2 then only some of the requests will begin to work. I'm not sure if this has to do with the curl request or something else.

It fails with the error:

GSS ERROR gss_acquire_cred_from failed to get server creds: [Unspecified GSS failure. Minor code may provide more information ( SPNEGO cannot find mechanisms to negotiate)], referer: https://ipa.example.com/ipa/json

Metadata Update from @tdudlak:
- Issue set to the milestone: FreeIPA 4.6.3 (was: FreeIPA 4.6.2)

3 years ago

Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.6.4 (was: FreeIPA 4.6.3)

2 years ago

FreeIPA 4.6.3 has been released, moving to FreeIPA 4.6.4 milestone

I'm not sure what changed but I can no longer reproduce this in 4.6.3+.

Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.6.5 (was: FreeIPA 4.6.4)

2 years ago

Marking as fixed. I still can't reproduce this against 4.7.2

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.