CEPH filesystem development
 help / color / mirror / Atom feed
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

  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