----- Original Message ----- > From: "Steffen W Sørensen" <stefws@xxxxxx> > To: ceph-users@xxxxxxxxxxxxxx > Sent: Friday, February 27, 2015 6:40:01 AM > Subject: RadosGW S3ResponseError: 405 Method Not Allowed > > Hi, > > Newbie to RadosGW+Ceph, but learning... > Got a running Ceph Cluster working with rbd+CephFS clients. Now I'm trying to > verify a RadosGW S3 api, but seems to have an issue with RadosGW access. > > I get the error (not found anything searching so far...): > > S3ResponseError: 405 Method Not Allowed > > when trying to access the rgw. > > Apache vhost access log file says: > > 10.20.0.29 - - [27/Feb/2015:14:09:04 +0100] "GET / HTTP/1.1" 405 27 "-" > "Boto/2.34.0 Python/2.6.6 Linux/2.6.32-504.8.1.el6.x86_64" > > and Apache's general error_log file says: > > [Fri Feb 27 14:09:04 2015] [warn] FastCGI: 10.20.0.29 GET http://{fqdn}:8005/ > auth AWS WL4EJJYTLVYXEHNR6QSA:X6XR4z7Gr9qTMNDphTNlRUk3gfc= > > > RadosGW seems to launch and run fine, though /var/log/messages at launches > says: > > Feb 27 14:12:34 rgw kernel: radosgw[14985]: segfault at e0 ip > 0000003fb36cb1dc sp 00007fffde221410 error 4 in > librados.so.2.0.0[3fb3200000+6d0000] > > # ps -fuapache > UID PID PPID C STIME TTY TIME CMD > apache 15113 15111 0 14:07 ? 00:00:00 /usr/sbin/fcgi- > apache 15114 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15115 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15116 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15117 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15118 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15119 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15120 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15121 15111 0 14:07 ? 00:00:00 /usr/sbin/httpd > apache 15224 1 1 14:12 ? 00:00:25 /usr/bin/radosgw -n > client.radosgw.owmblob > > RadosGW create my FastCGI socket and a default .asok, (not sure why/what > default socket are meant for) as well as the configured log file though it > never logs anything... > > # tail -18 /etc/ceph/ceph.conf: > > [client.radosgw.owmblob] > keyring = /etc/ceph/ceph.client.radosgw.keyring > host = rgw > rgw data = /var/lib/ceph/radosgw/ceph-rgw > log file = /var/log/radosgw/client.radosgw.owmblob.log > debug rgw = 20 > rgw enable log rados = true > rgw enable ops log = true > rgw enable apis = s3 > rgw cache enabled = true > rgw cache lru size = 10000 > rgw socket path = /var/run/ceph/ceph.radosgw.owmblob.fastcgi.sock > ;#rgw host = localhost > ;#rgw port = 8004 > rgw dns name = {fqdn} > rgw print continue = true > rgw thread pool size = 20 > > Turned out /etc/init.d/ceph-radosgw didn't chown $USER even when log_file > didn't exist, > assuming radosgw creates this log file when opening it, only it creates it as > root not $USER, thus not output, manually chowning it and restarting GW > gives output ala: > > 2015-02-27 15:25:14.464112 7fef463e9700 20 enqueued request req=0x25dea40 > 2015-02-27 15:25:14.465750 7fef463e9700 20 RGWWQ: > 2015-02-27 15:25:14.465786 7fef463e9700 20 req: 0x25dea40 > 2015-02-27 15:25:14.465864 7fef463e9700 10 allocated request req=0x25e3050 > 2015-02-27 15:25:14.466214 7fef431e4700 20 dequeued request req=0x25dea40 > 2015-02-27 15:25:14.466677 7fef431e4700 20 RGWWQ: empty > 2015-02-27 15:25:14.467888 7fef431e4700 20 CONTENT_LENGTH=0 > 2015-02-27 15:25:14.467922 7fef431e4700 20 DOCUMENT_ROOT=/var/www/html > 2015-02-27 15:25:14.467941 7fef431e4700 20 FCGI_ROLE=RESPONDER > 2015-02-27 15:25:14.467958 7fef431e4700 20 GATEWAY_INTERFACE=CGI/1.1 > 2015-02-27 15:25:14.467976 7fef431e4700 20 HTTP_ACCEPT_ENCODING=identity > 2015-02-27 15:25:14.469476 7fef431e4700 20 HTTP_AUTHORIZATION=AWS > WL4EJJYTLVYXEHNR6QSA:OAT0zVItGyp98T5mALeHz4p1fcg= > 2015-02-27 15:25:14.469516 7fef431e4700 20 HTTP_DATE=Fri, 27 Feb 2015 > 14:25:14 GMT > 2015-02-27 15:25:14.469533 7fef431e4700 20 HTTP_HOST={fqdn}:8005 > 2015-02-27 15:25:14.469550 7fef431e4700 20 HTTP_USER_AGENT=Boto/2.34.0 > Python/2.6.6 Linux/2.6.32-504.8.1.el6.x86_64 > 2015-02-27 15:25:14.469571 7fef431e4700 20 PATH=/sbin:/usr/sbin:/bin:/usr/bin > 2015-02-27 15:25:14.469589 7fef431e4700 20 QUERY_STRING= > 2015-02-27 15:25:14.469607 7fef431e4700 20 REMOTE_ADDR=10.20.0.29 > 2015-02-27 15:25:14.469624 7fef431e4700 20 REMOTE_PORT=34386 > 2015-02-27 15:25:14.469641 7fef431e4700 20 REQUEST_METHOD=GET > 2015-02-27 15:25:14.469658 7fef431e4700 20 REQUEST_URI=/ > 2015-02-27 15:25:14.469677 7fef431e4700 20 > SCRIPT_FILENAME=/var/www/html/s3gw.fcgi > 2015-02-27 15:25:14.469694 7fef431e4700 20 SCRIPT_NAME=/ > 2015-02-27 15:25:14.469711 7fef431e4700 20 SCRIPT_URI=http://{fqdn}:8005/ > 2015-02-27 15:25:14.469730 7fef431e4700 20 SCRIPT_URL=/ > 2015-02-27 15:25:14.469748 7fef431e4700 20 SERVER_ADDR=10.20.0.29 > 2015-02-27 15:25:14.469765 7fef431e4700 20 SERVER_ADMIN={email} > 2015-02-27 15:25:14.469782 7fef431e4700 20 SERVER_NAME={fqdn} > 2015-02-27 15:25:14.469801 7fef431e4700 20 SERVER_PORT=8005 > 2015-02-27 15:25:14.469818 7fef431e4700 20 SERVER_PROTOCOL=HTTP/1.1 > 2015-02-27 15:25:14.469835 7fef431e4700 20 SERVER_SIGNATURE= > 2015-02-27 15:25:14.469852 7fef431e4700 20 SERVER_SOFTWARE=Apache/2.2.22 > (Fedora) > 2015-02-27 15:25:14.469882 7fef431e4700 1 ====== starting new request > req=0x25dea40 ===== > 2015-02-27 15:25:14.470558 7fef431e4700 2 req 1:0.000679::GET > /::initializing > 2015-02-27 15:25:14.470669 7fef431e4700 10 host={fqdn}:8005 > rgw_dns_name={fqdn} > 2015-02-27 15:25:14.471810 7fef431e4700 2 req 1:0.001933::GET /::http > status=405 > > any clues what I'm missing out would be appreciated, TIA! 405 would usually mean one of two things. Either you sent the request to a misconfigured apache and it didn't get to the gateway at all, or the gateway got the request but couldn't match it to a known operation. It seems that your request did find its way to the gateway, but the question here is why doesn't it match to a known operation. This really looks like a valid list all buckets request, so I'm not sure what's happening. I'd look at two things first. One is the '{fqdn}' string, which I'm not sure whether that's the actual string that you have, or whether you just replaced it for the sake of anonymity. The second is the port number, which should be fine, but maybe the fact that it appears as part of the script uri triggers some issue. Yehuda > > /Steffen > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |