From: Chuanyu <chuanyu@cs.nctu.edu.tw>
To: ceph-devel@vger.kernel.org
Subject: Re: "Radosgw installation and administration" docs
Date: Sun, 1 Jul 2012 20:22:34 +0000 (UTC) [thread overview]
Message-ID: <loom.20120701T222011-780@post.gmane.org> (raw)
In-Reply-To: CAC-hyiF5PVR9nzjewG6VjPCGdjAeuio8Gqf9_juZKWRZZ1KpaQ@mail.gmail.com
Yehuda Sadeh <yehuda <at> inktank.com> writes:
>
> On Tue, Jun 12, 2012 at 11:11 AM, Florian Haas <florian <at> hastexo.com>
wrote:
> > Hi Yehuda,
> >
> > thanks, that resolved a lot of questions for me. A few follow-up
> > comments below:
> >
> >>
> >> We currently use a slightly different rule:
> >>
> >> RewriteRule ^/(.*)
> >> /radosgw.fcgi?params=$1&%{QUERY_STRING}
> >> [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
> >
> > Could you explain what happened to "page"?
>
> Not really. I don't remember, was probably necessary originally and
> now it's not. Looking at the code, I think you can also drop the
> params=$1 part:
>
> RewriteRule ^/(.*) /radosgw.fcgi?%{QUERY_STRING}
> [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
>
> >
> >>> Also, for each of these, where would the logging output end up?
> >>> /var/log/ceph? Apache error log? If so, only if the Apache LogLevel is
> >>> more verbose than info? Syslog?
> >>
> >>
> >> The debug log would end up wherever you specified in the 'log file'
> >> config option.
> >
> > ... or syslog, if log file = "" and syslog = true. (iirc)
>
> Yeah. Whichever ceph logging scheme you're using.
>
> >
> >>> 6. Swift API: Keys
> >>>
> >>> Is it correct to assume that for any Swift client to work, we must set a
> >>> Swift key for the user, like so?
> >>>
> >>> radosgw-admin key create --key-type=swift --uid=<user>
> >>>
> >>> If so, is the secret_key that that creates for the user:
> >>>
> >>> "swift_keys": [
> >>> { "user": "<user>",
> >>> "secret_key": "<longbase64hash>"}]}
> >>>
> >>>
> >>> ... the same key that the swift command line client expects to be set
> >>> with th -K option?
> >>
> >> Yes.
> >
> > OK, but I realized that you apparently have to create a separate key
> > when creating a sub-user. Is that correct? Or is there a way for
> > sub-users to "inherit" the keys defined for their parent user?
> >
> >>> 7. Swift API: swift user name
> >>>
> >>> When we call "swift -U <user>", is that the verbatim user_id that we've
> >>> defined with "radosgw-admin user create --uid=<user_id>"? Or do we need
> >>> to set a prefix? Or define a separate Swift user ID?
> >>>
> >>
> >> In swift the terminology is a bit different. There is the account and
> >> under that there is the user. Since we already have a 'user' (which is
> >> actually the swift account), we created a 'subuser'. So a one liner
> >> user and swift-subuser creation would be as follows:
> >>
> >> # radosgw-admin user create --subuser=yehuda:yehuda1
> >> --display-name=Yehuda --key-type=swift --access=full
> >
> > It seems there is some magic involved so that if you do "user create",
> > set --subuser=<prefix>:<sub> and don't set --uid, it creates a new
> > parent user named <prefix>. Is this meant to be stable? Or is the
>
> The <user>:<subuser> notation is stable.
>
> > supported way of doing things to always first create a user, and then
> > use "subuser create" to create the subuser?
>
> Both are supported, but note that the 'user create' command requires a
> display-name to be specified, whereas the 'subuser create' doesn't. We
> can change that later and only require the display-name if the user
> does not exist, but at the moment that's how it works.
>
> >
> >> { "user_id": "yehuda",
> >> "rados_uid": 0,
> >> "display_name": "Yehuda",
> >> "email": "",
> >> "suspended": 0,
> >> "max_buckets": 1000,
> >> "subusers": [
> >> { "id": "yehuda:yehuda1",
> >> "permissions": "full-control"}],
> >> "keys": [],
> >> "swift_keys": [
> >> { "user": "yehuda:yehuda1",
> >> "secret_key": "7TD5f2QrwxkCnhthwowC4d9uEJ4mnX8nGsXjmnW8"}]}
> >>
> >
Hi Yehuda, Florian,
I follow the wiki, and steps which you discussed,
construct my ceph system with rados gateway,
and I can use libs3 to upload file via radosgw, (thanks a lot!)
but got "405 Method Not Allowed" when I use swift,
$ swift -v -A http://s3.paca.tw:80/auth -U paca:paca1 -K
UoJO4nFgdAoX+9nEftElIY+AMmDIkcrUBkycNKPA stat
Auth GET failed: http://s3.paca.tw:80/auth/tokens 405 Method Not Allowed
( Because there has no test step on wiki,
I follow the Florian's question, and guess the test command is above ?!)
my radosgw-admin config:
$ radosgw-admin user info --uid=paca
{ "user_id": "paca",
"rados_uid": 0,
"display_name": "chuanyu",
"email": "chuanyu@cs.nctu.edu.tw",
"suspended": 0,
"subusers": [
{ "id": "paca:paca1",
"permissions": "<none>"}],
"keys": [
{ "user": "paca",
"access_key": "DS932H4EI9HK7I1CTDNF",
"secret_key": "Rn\/5FqHzRPZFN6f9R\/LuTqvG0AYjbHtrurrGydVk"}],
"swift_keys": [
{ "user": "paca:paca1",
"secret_key": "UoJO4nFgdAoX+9nEftElIY+AMmDIkcrUBkycNKPA"}]}
ceph.conf:
[client.radosgw.gateway]
host = volume
keyring = /etc/ceph/keyring/radosgw.gateway.keyring
rgw socket path = /var/run/ceph/rgw.sock
log file = ""
syslog = true
debug rgw = 20
my log:
http://pastebin.com/rhGhATmv
Any advice would be appreciate!
Tthanks,
Chuanyu
> >>> 10. radosgw "OpenStack user" information
> >>>
> >>> From the radosgw-admin man page:
> >>> --os-user=group:name
> >>> The OpenStack user (only needed for use with OpenStack)
> >>> --os-secret=key
> >>> The OpenStack key
> >>
> >> Obsolete. That was the old way to configure swift users.
> >
> > OK. Should this be removed from the man page then?
>
> Yeah, should be updated.
>
> >
> > Silly question: If "auth supported = none", is it still required to run
> > the ceph-authtool and ceph-auth commands specified in radosgw(8)?
>
> Not for setting up radosgw.
>
> >> log file = /var/log/radosgw/radosgw.log
> >> debug rgw = 20
> >> rgw cache enabled = 1
> >> ; rgw swift url = http://skinny
> >> ; rgw swift url prefix = swift
> >
> > I ran across this option sifting through src/rgw, can you explain what
> > the URL prefix is used for?
>
> When authenticating the client, the swift_url and swift_prefix are
> concatenated and passed to the client as the storage URL, along with
> the token.
>
> Thanks,
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-07-02 0:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4FD71854.6060503@hastexo.com>
2012-06-12 10:44 ` "Radosgw installation and administration" docs Florian Haas
2012-06-12 16:47 ` Yehuda Sadeh
2012-06-12 18:11 ` Florian Haas
2012-06-12 18:54 ` Yehuda Sadeh
2012-06-28 7:50 ` Florian Haas
2012-07-01 20:22 ` Chuanyu [this message]
2012-07-02 7:06 ` Florian Haas
2012-07-02 9:35 ` Chuanyu Tsai
2012-07-03 17:45 ` "Radosgw installation and administration" docs Yehuda Sadeh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20120701T222011-780@post.gmane.org \
--to=chuanyu@cs.nctu.edu.tw \
--cc=ceph-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox