Thanks Yehuda very much for the response. > In theory you could have either, however, the preferred mode of > installation is with having FastCgiExternalServer and manually running > the radosgw. How many radosgw daemons should be launched in such case, should it equal to the number of httpd processes?
Besides, it looks like a documentation issue on this page: http://ceph.com/docs/master/install/rpm/, it recommends using FastCgiExternalServer, however, it does not mention that part that radosgw application should be manually launched (maybe I am new to fastcgi though). Thanks, Guang On Sep 24, 2013, at 10:51 PM, Yehuda Sadeh wrote: > On Tue, Sep 24, 2013 at 12:46 AM, Guang <yguan...@yahoo.com> wrote: >> Hi ceph-users, >> I deployed a Ceph cluster (including RadosGW) with use of ceph-deploy on >> RHEL6.4, during the deployment, I have a couple of questions which need your >> help. >> >> 1. I followed the steps http://ceph.com/docs/master/install/rpm/ to deploy >> the RadosGW node, however, after the deployment, all requests failed with >> 500 returned. With some hints from >> http://irclogs.ceph.widodh.nl/index.php?date=2013-01-25, I changed the >> FastCgiExternalServer to FastCgiServer within rgw.conf. Is this change valid >> or I missed somewhere else which leads the need for this change? > > In theory you could have either, however, the preferred mode of > installation is with having FastCgiExternalServer and manually running > the radosgw. > >> >> 2. It still does not work and the httpd has the following error log: >> [Mon Sep 23 07:34:32 2013] [crit] (98)Address already in use: FastCGI: >> can't create server "/var/www/s3gw.fcgi": bind() failed [/tmp/radosgw.sock] >> which indicates that radosgw is not started properly, so that I manually run >> "radosgw --rgw-socket-path=/tmp/radosgw.sock -c /etc/ceph/ceph.conf -n >> client.radosgw.gateway" to start a radosgw daemon and then the gateway >> starts working as expected. >> Did I miss anything this part? > > That's one way to run the radosgw process. You still want to change > the apache conf to use the external server configuration, otherwise > apache will try relaunch it. > >> >> 3. When I was trying to run ceph admin-daemon command on the radosGW host, >> it failed because it does not have the corresponding asok file, however, I >> am able to run the command on monitor host and found that the radosGW's >> information can be retrieved there. >> >> @monitor (monitor and gateway are deployed on different hosts). >> [xxx@startbart ceph]$ sudo ceph --admin-daemon >> /var/run/ceph/ceph-mon.startbart.asok config show | grep rgw >> "rgw": "1\/5", >> "rgw_data": "\/var\/lib\/ceph\/radosgw\/ceph-startbart", >> "rgw_enable_apis": "s3, swift, swift_auth, admin", >> "rgw_cache_enabled": "true", >> "rgw_cache_lru_size": "10000", >> "rgw_socket_path": "", >> "rgw_host": "", >> "rgw_port": "", >> "rgw_dns_name": "", >> "rgw_script_uri": "", >> "rgw_request_uri": "", >> "rgw_swift_url": "", >> "rgw_swift_url_prefix": "swift", >> "rgw_swift_auth_url": "", >> "rgw_swift_auth_entry": "auth", >> "rgw_keystone_url": "", >> "rgw_keystone_admin_token": "", >> "rgw_keystone_accepted_roles": "Member, admin", >> "rgw_keystone_token_cache_size": "10000", >> "rgw_keystone_revocation_interval": "900", >> "rgw_admin_entry": "admin", >> "rgw_enforce_swift_acls": "true", >> "rgw_swift_token_expiration": "86400", >> "rgw_print_continue": "true", >> "rgw_remote_addr_param": "REMOTE_ADDR", >> "rgw_op_thread_timeout": "600", >> "rgw_op_thread_suicide_timeout": "0", >> "rgw_thread_pool_size": "100", >> Is this expected? > > The ceph configuration is monolithic, you see the mon configuration > here, and there are some rgw defaults, but it doesn't reflect the > actual rgw configuration. There's an open issue for gateway not > creating the admin socket by default, try adding 'admin socket' config > line to your gateway ceph.conf. > >> >> 4. cephx authentication. After reading through the cephx introduction, I got >> the feeling that cephx is for client to cluster authentication, so that each >> librados user will need to create a new key. However, this page >> http://ceph.com/docs/master/rados/operations/authentication/#enabling-cephx >> got me confused in terms of why should we create keys for mon and osd? And >> how does that fit into the authentication diagram? BTW, I found the keyrings >> under /var/lib/cecph/{role}/ for each roles, are they being used when talk >> to other roles? >> > > cephx is a kerberos-like authentication, and each entity needs to have > a key. In a distributed system like ceph, there's no single 'server' > (as in client-server). There could be many thousands of such servers, > and we want to authenticate each and one of them. That been said, when > a client gets a service ticket, it gets it for all services of the > same type, so it doesn't need to acquire a new ticket for each osd it > connects to. > > > Yehuda
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
