Project

General

Profile

Actions

Bug #19582

open

us-east-1 seems to be assumed by the s3 interface

Added by David Collier-Brown about 7 years ago. Updated about 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

While experimenting with authentication on a new ceph project, one using the s3-compatible interface, I discovered that I needed to set a particular region, us-east-1.

I know that's a well-known aws region, but I did not expect ceph to require it. Nevertheless, the logs said
2017-04-11 12:38:49.607490 7f9c3d3d0700 10 v4 credential format = WHF0J757LOLM09WMNIJT/20170411/us-east-1/s3/aws4_request
followed by
2017-04-11 12:38:49.607496 7f9c3d3d0700 10 credential scope = 20170411/us-east-1/s3/aws4_request

To the best of my knowledge, we did not name our region us-east-1: we would be more likely to name it can-east-1, as we're not in the US (;-))

If these are, as I assume, set in the ceph s3 interface, could we return an error saying something like "you must use a region of us-east-1 for compatibility with s3" ?

--dave
IMHO, including the region in the v4 authentication serves to make it harder to use anything except genuine Amazon s3, a bit of a self-serving change on their part. I hate it when people do that (:-()

Actions #1

Updated by David Collier-Brown about 7 years ago

background information:

This applies to everything that uses the v4 authentication, but I encountered it using the aws Go sdk, github.com/aws/aws-sdk-go, as downloaded on Apr 10 17:10

$ go version
go version go1.7.5 linux/amd64

$ uname -a
Linux miles 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Actions #2

Updated by Nathan Cutler about 7 years ago

  • Project changed from Ceph to rgw
Actions #3

Updated by David Collier-Brown about 7 years ago

A colleague reported he had reproduced the behavior using .net

Actions #4

Updated by Marcus Watts about 7 years ago

boto has a similar issue.
If running boto w/: export S3_USE_SIGV4=1

then after doing,
conn = boto.connect_s3(...
I find boto blows up if I don't do,
conn._auth_handler.region_name = "default"
I suspect there's a better way to do this.

Actions

Also available in: Atom PDF