Re: "Radosgw installation and administration" docs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx",
  "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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux