Swift trying to authenticate with keystone instead of swauth

asked 2013-02-21 16:54:31 -0600

stephen-kahmann
11 ●2 ●4 ●6

Hi,

I am trying to set up swift and use it as an object store for hadoop (see http://bigdatacraft.com/archives/406). I had originally set up swift to use keystone for authentication, but I need to switch to swauth for compatibility with cloud-files.

After making the switch I was able to run swauth-prep and swauth-add-user, but when I try to run swift -A <ip> -U account:user -K pass stat I get the following error:

=============================== root@irad-controller:/home/irad-controller# swift -V 2.0 -A http://7.7.7.101:8888/auth/v1.0 -U irad-user:irad-user -K password stat No handlers could be found for logger "keystoneclient.client" Traceback (most recent call last): File "/usr/bin/swift", line 1190, in error_queue) File "/usr/bin/swift", line 567, in st_stat headers = conn.head_account() File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 1000, in head_account return self._retry(None, head_account) File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 969, in _retry self.url, self.token = self.get_auth() File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 957, in get_auth os_options=self.os_options) File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 302, in get_auth key, kwargs['os_options']) File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 244, in get_keystoneclient_2_0 auth_url=auth_url) File "/usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py", line 80, in __init__ self.authenticate() File "/usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py", line 110, in authenticate "%s" % e) keystoneclient.exceptions.AuthorizationFailure: Authorization Failed: Unable to communicate with identity service: 400 Bad Request

The server could not comply with the request since it is either malformed or otherwise incorrect.

. (HTTP 400)

Here's my config:

=============================== [DEFAULT] bind_ip = 0.0.0.0 bind_port = 8888 user = swift swift_dir = /etc/swift

[pipeline:main] pipeline = healthcheck catch_errors cache swauth proxy-server

[filter:catch_errors] use = egg:swift#catch_errors

[app:proxy-server] use = egg:swift#proxy allow_account_management = true account_autocreate = true log_level=INFO

[filter:swauth] use = egg:swauth#swauth set log_name = swauth super_admin_key = ADMIN default_swift_cluster = irad_cluster#http://7.7.7.101:8888/v1

[filter:cache] use = egg:swift#memcache set log_name = cache memcache_servers = 10.0.1.4:11211

[filter:catch_errors] use = egg:swift#catch_errors

[filter:healthcheck]

use = egg:swift#healthcheck

Why is swift still trying to use keystone for authentication?

Thank you for your help!

edit retag flag offensive close merge delete

6 answers

Sort by » oldest newest most voted

0

answered 2013-02-21 16:56:21 -0600

stephen-kahmann
11 ●2 ●4 ●6

Also, I am able to run:

root@irad-controller:/home/irad-controller# curl -k -v -H 'X-Storage-User: irad-user:irad-user' -H 'X-Storage-Pass: ' http://7.7.7.101:8888/auth/v1.0 * About to connect() to 7.7.7.101 port 8888 (#0) * Trying 7.7.7.101... * connected * Connected to 7.7.7.101 (7.7.7.101) port 8888 (#0)

GET /auth/v1.0 HTTP/1.1 User-Agent: curl/7.27.0 Host: 7.7.7.101:8888 Accept: / X-Storage-User: irad-user:irad-user X-Storage-Pass: <pass>

additional stuff not fine transfer.c:1037: 0 0

HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK < X-Storage-Url: http://7.7.7.101:8888/v1/AUTH_58a22dbb-39ae-4507-a37d-24d0717f2177 (http://7.7.7.101:8888/v1/AUTH_58a22db...) < X-Storage-Token: AUTH_tk2e4157e39ae64bedb197beb7dd3447a0 < X-Auth-Token: AUTH_tk2e4157e39ae64bedb197beb7dd3447a0 < X-Trans-Id: tx9621ae114b7a4ee6a0a285802f928a31 < Content-Length: 126 < Date: Thu, 21 Feb 2013 16:55:28 GMT <

Connection #0 to host 7.7.7.101 left intact {"storage": {"default": "irad_cluster", "irad_cluster": "http://7.7.7.101:8888/v1/AUTH_58a22dbb-39ae-4507-a37d-24d0717f2177"}}* Closing connection #0

edit flag offensive delete link

0

answered 2013-02-21 16:56:24 -0600

stephen-kahmann
11 ●2 ●4 ●6

Also, I am able to run:

root@irad-controller:/home/irad-controller# curl -k -v -H 'X-Storage-User: irad-user:irad-user' -H 'X-Storage-Pass: ' http://7.7.7.101:8888/auth/v1.0 * About to connect() to 7.7.7.101 port 8888 (#0) * Trying 7.7.7.101... * connected * Connected to 7.7.7.101 (7.7.7.101) port 8888 (#0)

GET /auth/v1.0 HTTP/1.1 User-Agent: curl/7.27.0 Host: 7.7.7.101:8888 Accept: / X-Storage-User: irad-user:irad-user X-Storage-Pass: <pass>

additional stuff not fine transfer.c:1037: 0 0

HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK < X-Storage-Url: http://7.7.7.101:8888/v1/AUTH_58a22dbb-39ae-4507-a37d-24d0717f2177 (http://7.7.7.101:8888/v1/AUTH_58a22db...) < X-Storage-Token: AUTH_tk2e4157e39ae64bedb197beb7dd3447a0 < X-Auth-Token: AUTH_tk2e4157e39ae64bedb197beb7dd3447a0 < X-Trans-Id: tx9621ae114b7a4ee6a0a285802f928a31 < Content-Length: 126 < Date: Thu, 21 Feb 2013 16:55:28 GMT <

Connection #0 to host 7.7.7.101 left intact {"storage": {"default": "irad_cluster", "irad_cluster": "http://7.7.7.101:8888/v1/AUTH_58a22dbb-39ae-4507-a37d-24d0717f2177"}}* Closing connection #0

edit flag offensive delete link

0

answered 2013-02-21 18:19:25 -0600

clay-gerrard
41 ●1

It's the swift command line client using the keystone stuff to make the v2.0 auth request.

Swauth is v1.0 style auth requests, as your curl request notates.

I believe swauth should be fully compatible with the swift client's support of v1.0 style auth requests (e.g. tempauth).

Try:

swift -A http://7.7.7.101:8888/auth/v1.0 -U irad-user:irad-user -K password stat

i.e. w/o the "-V 2.0"

edit flag offensive delete link

0

answered 2013-02-21 18:50:10 -0600

stephen-kahmann
11 ●2 ●4 ●6

clayg I tried your suggestion, but no dice:

root@irad-controller:/home/irad-controller# swift -A http://7.7.7.101:8888/auth/v1.0 -U irad-user:irad-user -K password stat No handlers could be found for logger "keystoneclient.client" Traceback (most recent call last): File "/usr/bin/swift", line 1190, in error_queue) File "/usr/bin/swift", line 567, in st_stat headers = conn.head_account() File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 1000, in head_account return self._retry(None, head_account) File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 969, in _retry self.url, self.token = self.get_auth() File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 957, in get_auth os_options=self.os_options) File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 302, in get_auth key, kwargs['os_options']) File "/usr/lib/python2.7/dist-packages/swiftclient/client.py", line 244, in get_keystoneclient_2_0 auth_url=auth_url) File "/usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py", line 80, in __init__ self.authenticate() File "/usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py", line 110, in authenticate "%s" % e) keystoneclient.exceptions.AuthorizationFailure: Authorization Failed: Unable to communicate with identity service: 400 Bad Request

The server could not comply with the request since it is either malformed or otherwise incorrect.

. (HTTP 400)

Thank you!

edit flag offensive delete link

0

answered 2013-02-21 21:16:19 -0600

clay-gerrard
41 ●1

Hrmm... we'll removing the option on the commandline didn't seem to have prevented the swift command line tool from attempting v2.0 style auth.

Perhaps there's something in you shell environment vars?

env | egrep "(OS_|ST_)"

I believe the option "ST_AUTH_VERSION" might be wrong?

... try logging out and logging back in.

edit flag offensive delete link

0

answered 2013-02-22 16:11:31 -0600

stephen-kahmann
11 ●2 ●4 ●6

That was it, thank you! Actually it was the OS_AUTH_URL env variable being set to the keystone endpoint causing the problem. Thank you for point me in the right direction!

edit flag offensive delete link

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-02-21 16:54:31 -0600

Seen: 207 times

Last updated: Feb 22 '13

Related questions