Or just generate the secret/access key explicitly:
radosgw-admin user create --access-key `tr -dc A-Z0-9 < /dev/urandom |
head -c 20` --secret `tr -dc a-zA-Z0-9 < /dev/urandom | head -c 40`
I'm not sure why the documentation suggests just generating it over and
over, rather then just generating it in a way that won't cause problems.
On 6/27/2014 1:15 PM, Craig Lewis wrote:
backslash characters (\) are known to cause problems for some clients
(like s3cmd).
Try removing them from your secret, and see if that works. If it
doesn't, just remove the key and secret, and regenerate until the
secret doesn't have any backslashes.
On Fri, Jun 27, 2014 at 12:22 AM, Florent B <[email protected]
<mailto:[email protected]>> wrote:
I have a similar issue but I don't know if it is related to yours.
When secret key of a swift subuser contains "+" or "\" (I don't
which), authentification fails using python-swiftclient.
Is it an issue ?
On 06/25/2014 11:58 PM, Brian Rak wrote:
I'm trying to find an issue with RadosGW and special characters
in filenames. Specifically, it seems that filenames with a + in
them are not being handled correctly, and that I need to
explicitly escape them.
For example:
---request begin---
HEAD
/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb
HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Will fail with a 404 error, but
---request begin---
HEAD
/ubuntu/pool/main/a/adduser/adduser_3.113%2Bnmu3ubuntu3_all.deb
HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
will work properly.
I enabled debug mode on radosgw, and see this:
2014-06-25 17:30:37.383029 7f7ca7fff700 20 RGWWQ:
2014-06-25 17:30:37.383040 7f7ca7fff700 20 req: 0x7f7ca000b180
2014-06-25 17:30:37.383053 7f7ca7fff700 10 allocated request
req=0x7f7ca0015ef0
2014-06-25 17:30:37.383064 7f7c6cfa9700 20 dequeued request
req=0x7f7ca000b180
2014-06-25 17:30:37.383070 7f7c6cfa9700 20 RGWWQ: empty
2014-06-25 17:30:37.383121 7f7c6cfa9700 20 CONTENT_LENGTH=
2014-06-25 17:30:37.383123 7f7c6cfa9700 20 CONTENT_TYPE=
2014-06-25 17:30:37.383124 7f7c6cfa9700 20
DOCUMENT_ROOT=/etc/nginx/html
2014-06-25 17:30:37.383125 7f7c6cfa9700 20
DOCUMENT_URI=/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb
2014-06-25 17:30:37.383126 7f7c6cfa9700 20 FCGI_ROLE=RESPONDER
2014-06-25 17:30:37.383127 7f7c6cfa9700 20 GATEWAY_INTERFACE=CGI/1.1
2014-06-25 17:30:37.383128 7f7c6cfa9700 20 HTTP_ACCEPT=*/*
2014-06-25 17:30:37.383129 7f7c6cfa9700 20 HTTP_CONNECTION=Keep-Alive
2014-06-25 17:30:37.383129 7f7c6cfa9700 20 HTTP_HOST=xxx
2014-06-25 17:30:37.383130 7f7c6cfa9700 20
HTTP_USER_AGENT=Wget/1.12 (linux-gnu)
2014-06-25 17:30:37.383131 7f7c6cfa9700 20 QUERY_STRING=
2014-06-25 17:30:37.383131 7f7c6cfa9700 20 REDIRECT_STATUS=200
2014-06-25 17:30:37.383132 7f7c6cfa9700 20 REMOTE_ADDR=yyy
2014-06-25 17:30:37.383133 7f7c6cfa9700 20 REMOTE_PORT=43855
2014-06-25 17:30:37.383134 7f7c6cfa9700 20 REQUEST_METHOD=HEAD
2014-06-25 17:30:37.383134 7f7c6cfa9700 20
REQUEST_URI=/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb
2014-06-25 17:30:37.383135 7f7c6cfa9700 20
SCRIPT_NAME=/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb
2014-06-25 17:30:37.383136 7f7c6cfa9700 20 SERVER_ADDR=yyy
2014-06-25 17:30:37.383136 7f7c6cfa9700 20 SERVER_NAME=xxx
2014-06-25 17:30:37.383137 7f7c6cfa9700 20 SERVER_PORT=80
2014-06-25 17:30:37.383138 7f7c6cfa9700 20 SERVER_PROTOCOL=HTTP/1.0
2014-06-25 17:30:37.383138 7f7c6cfa9700 20
SERVER_SOFTWARE=nginx/1.4.6
2014-06-25 17:30:37.383140 7f7c6cfa9700 1 ====== starting new
request req=0x7f7ca000b180 =====
2014-06-25 17:30:37.383152 7f7c6cfa9700 2 req 1:0.000013::HEAD
/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb::initializing
2014-06-25 17:30:37.383158 7f7c6cfa9700 10 host=xxxx
rgw_dns_name=xxxx
2014-06-25 17:30:37.383199 7f7c6cfa9700 10
*s->object=ubuntu/pool/main/a/adduser/adduser_3.113
nmu3ubuntu3_all.deb s->bucket=ubuntu*
2014-06-25 17:30:37.383207 7f7c6cfa9700 2 req 1:0.000068:s3:HEAD
/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb::getting
op
2014-06-25 17:30:37.383211 7f7c6cfa9700 2 req 1:0.000072:s3:HEAD
/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb:get_obj:authorizing
2014-06-25 17:30:37.383218 7f7c6cfa9700 2 req 1:0.000079:s3:HEAD
/ubuntu/pool/main/a/adduser/adduser_3.113+nmu3ubuntu3_all.deb:get_obj:reading
permissions
2014-06-25 17:30:37.383268 7f7c6cfa9700 20 get_obj_state:
rctx=0x7f7c6cfa8640 obj=.rgw:ubuntu state=0x7f7c6800c0a8
s->prefetch_data=0
2014-06-25 17:30:37.383279 7f7c6cfa9700 10 cache get:
name=.rgw+ubuntu : miss
It seems that Ceph is attempting to urldecode the filename, even
when it shouldn't be. (Going by
http://stackoverflow.com/questions/1005676/urls-and-plus-signs
). Is this a bug, or is this the desired behavior?
_______________________________________________
ceph-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________
ceph-users mailing list
[email protected]
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
