Re: Radosgw refusing to even attempt to use keystone auth

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

 



I still think that there is problem with the way radosgw is setup. Two things I want to point out - 

1. rgw keystone url - If this flag is under radosgw section of ceph.conf file, I do not see the packets being exchanged between keystone and gateway node when radosgw is restarted. I tried to run tcpdump on both the nodes. 

2. rgw.keystone url - If this is in global section (which is wrong), I do see the packets being exchanged between the nodes when radosgw is restarted. 

I have tried my best to follow the instructions as per http://ceph.com/docs/master/radosgw/config/ to setup radosgw. Also with this setup, I can still create users using radosgw-admin and make swift v1.0 calls from swift-client.

How should I go about resolving this issue? Please help.
Thanks,
Lakshmi.
 




On Wednesday, October 15, 2014 2:58 PM, Mark Kirkwood <mark.kirkwood@xxxxxxxxxxxxxxx> wrote:


On 16/10/14 10:37, Mark Kirkwood wrote:
> On 16/10/14 09:08, lakshmi k s wrote:
>> I am trying to integrate Openstack keystone with radosgw. I have
>> followed the instructions as per the link -
>> http://ceph.com/docs/master/radosgw/keystone/. But for some reason,
>> keystone flags under [client.radosgw.gateway] section are not being
>> honored. That means, presence of these flags never attempt to use
>> keystone. Hence, any swift v2.0 calls results in 401-Authorization
>> problem. But If I move the keystone url outside under global section, I
>> see that there is initial keystone handshake between keystone and
>> gateway nodes.
>>
>> Please note that swift v1 calls (without using keystone) work great.
>> Any thoughts on how to resolve this problem?
>>
>> ceph.conf
>>
>> [global]
>> fsid = f216cbe1-fa49-42ed-b28a-322aa3d48fff
>> mon_initial_members = node1
>> mon_host = 192.168.122.182
>> auth_cluster_required = cephx
>> auth_service_required = cephx
>> auth_client_required = cephx
>> filestore_xattr_use_omap = true
>>
>> [client.admin]
>> keyring = /etc/ceph/ceph.client.admin.keyring
>>
>> [client.radosgw.gateway]
>> host = radosgw
>> keyring = /etc/ceph/ceph.client.radosgw.keyring
>> rgw socket path = /var/run/ceph/ceph.radosgw.gateway.fastcgi.sock
>> log file = /var/log/ceph/client.radosgw.gateway.log
>> rgw dns name = radosgw
>>
>> rgw keystone url = "" shape="rect" href="http://192.168.122.165:5000/" target="_blank" class="" style="">http://192.168.122.165:5000
>> rgw keystone admin token = faedf7bc53e3371924e7b3ddb9d13ddd
>> rgw keystone accepted roles = admin Member _member_
>> rgw keystone token cache size = 500
>> rgw keystone revocation interval = 500
>> rgw s3 auth use keystone = true
>> nss db path = /var/ceph/nss
>>
>>
>
> I have managed to to reproduce this:
>
> If I copy your [client.radosgw.gateway] section and amend the obvious
> differences (hostnames and ips, and socket paths), then I too see auth
> failed and no sign of any attempt to use keystone auth logged. Making
> the following change:
>
> - rgw keystone url = "" shape="rect" href="http://192.168.122.165:5000/" target="_blank" class="" style="">http://192.168.122.165:5000
> + rgw keystone url = "" shape="rect" href="http://192.168.122.165:35357/" target="_blank" class="" style="">http://192.168.122.165:35357
>
> makes it work again. I'm guessing it is tied up with with the fact we
> needed to add WSGI Chunked encoding... and we did that only for the
> 35357 keystone virtualhost (I guess I can add it to 5000 too and see if
> that fixes it). I does seem odd that there is no log entry on the rgw...
> but it may be failing before the call gets logged (will look).
>
>


So amending the keystone site config:

<VirtualHost *:5000>
    ...
    WSGIChunkedRequest On
    ...
</VirtualHost>

makes the original keystone url with port 5000 work too.

The logging business is a bit more tricky - I'd copied your
[client.radosgw.gateway] section which lacks

debug rgw = 20

line, which explains *my* lack of seeing the keystone auth log lines.
When I add that line I'm seeing the debug auth info (even if I remove
the WSGI chunking for 5000 and make it fail again).

So Lakshmi, can you add the 'WSGIChunkedRequest On' as inidicated, and
make sure you have the debug line in there and retest?


Regards

Mark



_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

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


  Powered by Linux