Red Hat Bugzilla – Bug 1116551
Can't get a token with curl when keystone is running in Apache with LDAP
Last modified: 2016-04-26 19:59:39 EDT
Created attachment 914917 [details] Rich Megginson's script for keystone-ldap-ipa.sh Description of problem: This patch seems to be missing: https://review.openstack.org/#/c/90476/ When keystone is working with LDAP and running under Apache, I can only use the keystone client but I can't authenticate using curl. I get a 500 Internal Server Error and I see the following error in the log: ==> /var/log/httpd/error_log <== [Thu Jul 03 17:33:46.808584 2014] [:error] [pid 13454] [remote 10.35.64.157:216] mod_wsgi (pid=13454): Exception occurred processing WSGI script '/var/www/cgi-bin/keystone/main'. [Thu Jul 03 17:33:46.808634 2014] [:error] [pid 13454] [remote 10.35.64.157:216] TypeError: expected byte string object for header value, value of type unicode found No other errors seen in other logs. I tried with v3 as well as v2 tokens and failed with both. When I stop httpd and start openstack-keystone I have no problems. The script I use to get a token with curl is: Version-Release number of selected component (if applicable): openstack-keystone-2014.1-5.el7ost.noarch python-keystone-2014.1-5.el7ost.noarch python-keystoneclient-0.9.0-1.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Configure keystone to use LDAP using the attached script by Rich Megginson 2. See that you can get a token from /v3/auth/tokens as well as by using the client 3. Run keystone under Apache (insturctions are here: https://wiki.test.redhat.com/RhevmQe/OpenStackTeam/Keystone/WSGI2) 4. Check if you can get a token again Actual results: Can't get a token by calling /v3/auth/tokens, only with the client Expected results: You should be able to get a token by calling /v3/auth/tokens just as you can when keystone is running stand-alone. Additional info: This patch seems to be missing: https://review.openstack.org/#/c/90476/
To get a token with curl: #!/bin/bash KEYSTONE_USER=keystone KEYSTONE_TENANT=admin KEYSTONE_USERPASS=redhat123 KEYSTONE_DOMAIN=default KEYSTONE_URL=http://10.35.64.157:5000/v3 cat << EOF > ~/auth1.json { "auth": { "identity": { "methods": [ "password" ], "password": { "user": { "domain": { "name": "$KEYSTONE_DOMAIN" }, "name": "$KEYSTONE_USER", "password": "$KEYSTONE_USERPASS" } } }, "scope": { "project": { "domain": { "name": "$KEYSTONE_DOMAIN" }, "name": "$KEYSTONE_TENANT" } } } } EOF MYTOKEN=$(curl -si -d @auth1.json -H "Content-type: application/json" ${KEYSTONE_URL}/auth/tokens?nocatalog| tee result.raw | awk '/X-Subject-Token/ {print $2}') MYTOKEN=$(echo "$MYTOKEN" | tr -d '\r') rm -f ~/auth1.json # echo result.raw to stderr if MYTOKEN is blank, so the user can read the error on the console if [ "x$MYTOKEN" == "x" ]; then cat result.raw >&2 echo "" >&2 else echo $MYTOKEN echo "export TESTV3_TOKEN=${MYTOKEN}" > ~/keystone_v3testtoken fi
I recreated this bug also without LDAP, so in general we have a problem running under Apache.
This has been proposed for backport to stable/icehouse upstream: https://review.openstack.org/#/c/116991/
This was addressed in the upstream 2014.1.3 Icehouse release.
Verified: openstack-keystone-2014.1.3-2.el7ost.noarch python-keystone-2014.1.3-2.el7ost.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2014-1790.html