Revision history [back]

click to hide/show revision 1
initial version

How to work with S3 API using Swift3?

Hi there,

I am wondering if there is any more documentation on how to get swift3 to work with S3 API. Specifically, if I created a swift account by seki@OS-CC:/var/log$ swift-auth-add-user -K devauth -a system root testpass https://192.168.1.33:8080/v1/AUTH_365f77c9d523435dbcf12c9d2678d197 And get the following seki@OS-CC:/var/log$ curl -k -v -H 'X-Storage-User: system:root' -H 'X-Storage-Pass: testpass' https://192.168.1.33:11000/v1.0 ... < X-Storage-Url: https://192.168.1.33:8080/v1/AUTH_365f77c9d523435dbcf12c9d2678d197 < X-Storage-Token: AUTH_tka3599de5039545809d181637d0f010a9 < X-Auth-Token: AUTH_tka3599de5039545809d181637d0f010a9 ...

Should I set the following variables export EC2_ACCESS_KEY=AUTH_tka3599de5039545809d181637d0f010a9 export EC2_SECRET_KEY=testpass export S3_URL=https://192.168.1.33:8080/v1/AUTH_365f77c9d523435dbcf12c9d2678d197

I've added to the following to /etc/swift/proxy-server.conf [filter:swift3] use = egg:swift#swift3 log_facility = LOG_LOCAL1

But I am still getting 401 error: seki@OS-CC:~/s3-curl$ ./s3curl.pl --id $EC2_ACCESS_KEY --key $EC2_SECRET_KEY --get -- -s -v $S3_URL -k Unknown option: get WARNING: It isn't safe to put your AWS secret access key on the command line! The recommended key management system is to store your AWS secret access keys in a file owned by, and only readable by you.

For example:

%awsSecretAccessKeys = ( # personal account personal => { id => '1ME55KNV6SBTR7EXG0R2', key => 'zyMrlZUKeG9UcYpwzlPko/+Ciu0K2co0duRM3fhi', },

# corporate account
company => {
    id => '1ATXQ3HHA59CYF1CVS02',
    key => 'WQY4SrSS95pJUT95V6zWea01gBKBCL6PI0cdxeH8',
},

);

$ chmod 600 /home/seki/.s3curl

Will sleep and continue despite this problem. Please set up /home/seki/.s3curl for future requests. * About to connect() to 192.168.1.33 port 8080 (#0) * Trying 192.168.1.33... connected * Connected to 192.168.1.33 (192.168.1.33) port 8080 (#0) * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using AES256-SHA * Server certificate: * subject: C=CA; ST=AB; L=Edmonton; O=VRS; OU=RD; CN=OS-CC; emailAddress=Shi.Jin@vrstorm.com * start date: 2011-04-23 15:55:37 GMT * expire date: 2011-05-23 15:55:37 GMT * common name: OS-CC (does not match '192.168.1.33') * issuer: C=CA; ST=AB; L=Edmonton; O=VRS; OU=RD; CN=OS-CC; emailAddress=Shi.Jin@vrstorm.com * SSL certificate verify result: self signed certificate (18), continuing anyway.

GET /v1/AUTH_365f77c9d523435dbcf12c9d2678d197 HTTP/1.1 User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18 Host: 192.168.1.33:8080 Accept: / Date: Tue, 26 Apr 2011 16:42:05 +0000 Authorization: AWS AUTH_tka3599de5039545809d181637d0f010a9:6L/VuKi4ZT5YQkI9JwnVIMT2TcI=

< HTTP/1.1 401 Unauthorized < Content-Type: text/html; charset=UTF-8 < Content-Length: 364 < Date: Tue, 26 Apr 2011 16:42:05 GMT < <html> <head> <title>401 Unauthorized</title> </head> <body>

401 Unauthorized

This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.

</body> * Connection #0 to host 192.168.1.33 left intact * Closing connection #0 * SSLv3, TLS alert, Client hello (1):