]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | =========================== |
2 | Install Ceph Object Gateway | |
3 | =========================== | |
4 | ||
5 | As of `firefly` (v0.80), Ceph Object Gateway is running on Civetweb (embedded | |
6 | into the ``ceph-radosgw`` daemon) instead of Apache and FastCGI. Using Civetweb | |
7 | simplifies the Ceph Object Gateway installation and configuration. | |
8 | ||
9 | .. note:: To run the Ceph Object Gateway service, you should have a running | |
10 | Ceph storage cluster, and the gateway host should have access to the | |
11 | public network. | |
12 | ||
13 | .. note:: In version 0.80, the Ceph Object Gateway does not support SSL. You | |
14 | may setup a reverse proxy server with SSL to dispatch HTTPS requests | |
15 | as HTTP requests to CivetWeb. | |
16 | ||
17 | Execute the Pre-Installation Procedure | |
18 | -------------------------------------- | |
19 | ||
20 | See Preflight_ and execute the pre-installation procedures on your Ceph Object | |
21 | Gateway node. Specifically, you should disable ``requiretty`` on your Ceph | |
22 | Deploy user, set SELinux to ``Permissive`` and set up a Ceph Deploy user with | |
23 | password-less ``sudo``. For Ceph Object Gateways, you will need to open the | |
24 | port that Civetweb will use in production. | |
25 | ||
26 | .. note:: Civetweb runs on port ``7480`` by default. | |
27 | ||
28 | Install Ceph Object Gateway | |
29 | --------------------------- | |
30 | ||
31 | From the working directory of your administration server, install the Ceph | |
32 | Object Gateway package on the Ceph Object Gateway node. For example:: | |
33 | ||
34 | ceph-deploy install --rgw <gateway-node1> [<gateway-node2> ...] | |
35 | ||
36 | The ``ceph-common`` package is a dependency, so ``ceph-deploy`` will install | |
37 | this too. The ``ceph`` CLI tools are intended for administrators. To make your | |
38 | Ceph Object Gateway node an administrator node, execute the following from the | |
39 | working directory of your administration server:: | |
40 | ||
41 | ceph-deploy admin <node-name> | |
42 | ||
43 | Create a Gateway Instance | |
44 | ------------------------- | |
45 | ||
46 | From the working directory of your administration server, create an instance of | |
47 | the Ceph Object Gateway on the Ceph Object Gateway. For example:: | |
48 | ||
49 | ceph-deploy rgw create <gateway-node1> | |
50 | ||
51 | Once the gateway is running, you should be able to access it on port ``7480`` | |
52 | with an unauthenticated request like this:: | |
53 | ||
54 | http://client-node:7480 | |
55 | ||
56 | If the gateway instance is working properly, you should receive a response like | |
57 | this:: | |
58 | ||
59 | <?xml version="1.0" encoding="UTF-8"?> | |
60 | <ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> | |
61 | <Owner> | |
62 | <ID>anonymous</ID> | |
63 | <DisplayName></DisplayName> | |
64 | </Owner> | |
65 | <Buckets> | |
66 | </Buckets> | |
67 | </ListAllMyBucketsResult> | |
68 | ||
69 | If at any point you run into trouble and you want to start over, execute the | |
70 | following to purge the configuration:: | |
71 | ||
72 | ceph-deploy purge <gateway-node1> [<gateway-node2>] | |
73 | ceph-deploy purgedata <gateway-node1> [<gateway-node2>] | |
74 | ||
75 | If you execute ``purge``, you must re-install Ceph. | |
76 | ||
77 | Change the Default Port | |
78 | ----------------------- | |
79 | ||
80 | Civetweb runs on port ``7480`` by default. To change the default port (e.g., to | |
81 | port ``80``), modify your Ceph configuration file in the working directory of | |
82 | your administration server. Add a section entitled | |
83 | ``[client.rgw.<gateway-node>]``, replacing ``<gateway-node>`` with the short | |
84 | node name of your Ceph Object Gateway node (i.e., ``hostname -s``). | |
85 | ||
86 | .. note:: As of version 11.0.1, the Ceph Object Gateway **does** support SSL. | |
87 | See `Using SSL with Civetweb`_ for information on how to set that up. | |
88 | ||
89 | For example, if your node name is ``gateway-node1``, add a section like this | |
90 | after the ``[global]`` section:: | |
91 | ||
92 | [client.rgw.gateway-node1] | |
93 | rgw_frontends = "civetweb port=80" | |
94 | ||
95 | .. note:: Ensure that you leave no whitespace between ``port=<port-number>`` in | |
96 | the ``rgw_frontends`` key/value pair. The ``[client.rgw.gateway-node1]`` | |
97 | heading identifies this portion of the Ceph configuration file as | |
98 | configuring a Ceph Storage Cluster client where the client type is a Ceph | |
99 | Object Gateway (i.e., ``rgw``), and the name of the instance is | |
100 | ``gateway-node1``. | |
101 | ||
102 | Push the updated configuration file to your Ceph Object Gateway node | |
103 | (and other Ceph nodes):: | |
104 | ||
105 | ceph-deploy --overwrite-conf config push <gateway-node> [<other-nodes>] | |
106 | ||
107 | To make the new port setting take effect, restart the Ceph Object | |
108 | Gateway:: | |
109 | ||
110 | sudo systemctl restart ceph-radosgw.service | |
111 | ||
112 | Finally, check to ensure that the port you selected is open on the node's | |
113 | firewall (e.g., port ``80``). If it is not open, add the port and reload the | |
114 | firewall configuration. If you use the ``firewalld`` daemon, execute:: | |
115 | ||
116 | sudo firewall-cmd --list-all | |
117 | sudo firewall-cmd --zone=public --add-port 80/tcp --permanent | |
118 | sudo firewall-cmd --reload | |
119 | ||
120 | If you use ``iptables``, execute:: | |
121 | ||
122 | sudo iptables --list | |
123 | sudo iptables -I INPUT 1 -i <iface> -p tcp -s <ip-address>/<netmask> --dport 80 -j ACCEPT | |
124 | ||
125 | Replace ``<iface>`` and ``<ip-address>/<netmask>`` with the relevant values for | |
126 | your Ceph Object Gateway node. | |
127 | ||
128 | Once you have finished configuring ``iptables``, ensure that you make the | |
129 | change persistent so that it will be in effect when your Ceph Object Gateway | |
130 | node reboots. Execute:: | |
131 | ||
132 | sudo apt-get install iptables-persistent | |
133 | ||
134 | A terminal UI will open up. Select ``yes`` for the prompts to save current | |
135 | ``IPv4`` iptables rules to ``/etc/iptables/rules.v4`` and current ``IPv6`` | |
136 | iptables rules to ``/etc/iptables/rules.v6``. | |
137 | ||
138 | The ``IPv4`` iptables rule that you set in the earlier step will be loaded in | |
139 | ``/etc/iptables/rules.v4`` and will be persistent across reboots. | |
140 | ||
141 | If you add a new ``IPv4`` iptables rule after installing | |
142 | ``iptables-persistent`` you will have to add it to the rule file. In such case, | |
143 | execute the following as the ``root`` user:: | |
144 | ||
145 | iptables-save > /etc/iptables/rules.v4 | |
146 | ||
147 | Using SSL with Civetweb | |
148 | ----------------------- | |
149 | .. _Using SSL with Civetweb: | |
150 | ||
151 | Before using SSL with civetweb, you will need a certificate that will match | |
152 | the host name that that will be used to access the Ceph Object Gateway. | |
153 | You may wish to obtain one that has `subject alternate name` fields for | |
154 | more flexibility. If you intend to use S3-style subdomains | |
155 | (`Add Wildcard to DNS`_), you will need a `wildcard` certificate. | |
156 | ||
157 | Civetweb requires that the server key, server certificate, and any other | |
158 | CA or intermediate certificates be supplied in one file. Each of these | |
159 | items must be in `pem` form. Because the combined file contains the | |
160 | secret key, it should be protected from unauthorized access. | |
161 | ||
162 | To configure ssl operation, append ``s`` to the port number. Currently | |
163 | it is not possible to configure the radosgw to listen on both | |
164 | http and https, you must pick only one. So:: | |
165 | ||
166 | [client.rgw.gateway-node1] | |
167 | rgw_frontends = civetweb port=443s ssl_certificate=/etc/ceph/private/keyandcert.pem | |
168 | ||
169 | Migrating from Apache to Civetweb | |
170 | --------------------------------- | |
171 | ||
172 | If you're running the Ceph Object Gateway on Apache and FastCGI with Ceph | |
173 | Storage v0.80 or above, you're already running Civetweb--it starts with the | |
174 | ``ceph-radosgw`` daemon and it's running on port 7480 by default so that it | |
175 | doesn't conflict with your Apache and FastCGI installation and other commonly | |
176 | used web service ports. Migrating to use Civetweb basically involves removing | |
177 | your Apache installation. Then, you must remove Apache and FastCGI settings | |
178 | from your Ceph configuration file and reset ``rgw_frontends`` to Civetweb. | |
179 | ||
180 | Referring back to the description for installing a Ceph Object Gateway with | |
181 | ``ceph-deploy``, notice that the configuration file only has one setting | |
182 | ``rgw_frontends`` (and that's assuming you elected to change the default port). | |
183 | The ``ceph-deploy`` utility generates the data directory and the keyring for | |
184 | you--placing the keyring in ``/var/lib/ceph/radosgw/{rgw-intance}``. The daemon | |
185 | looks in default locations, whereas you may have specified different settings | |
186 | in your Ceph configuration file. Since you already have keys and a data | |
187 | directory, you will want to maintain those paths in your Ceph configuration | |
188 | file if you used something other than default paths. | |
189 | ||
190 | A typical Ceph Object Gateway configuration file for an Apache-based deployment | |
191 | looks something similar as the following: | |
192 | ||
193 | On Red Hat Enterprise Linux:: | |
194 | ||
195 | [client.radosgw.gateway-node1] | |
196 | host = {hostname} | |
197 | keyring = /etc/ceph/ceph.client.radosgw.keyring | |
198 | rgw socket path = "" | |
199 | log file = /var/log/radosgw/client.radosgw.gateway-node1.log | |
200 | rgw frontends = fastcgi socket\_port=9000 socket\_host=0.0.0.0 | |
201 | rgw print continue = false | |
202 | ||
203 | On Ubuntu:: | |
204 | ||
205 | [client.radosgw.gateway-node] | |
206 | host = {hostname} | |
207 | keyring = /etc/ceph/ceph.client.radosgw.keyring | |
208 | rgw socket path = /var/run/ceph/ceph.radosgw.gateway.fastcgi.sock | |
209 | log file = /var/log/radosgw/client.radosgw.gateway-node1.log | |
210 | ||
211 | To modify it for use with Civetweb, simply remove the Apache-specific settings | |
212 | such as ``rgw_socket_path`` and ``rgw_print_continue``. Then, change the | |
213 | ``rgw_frontends`` setting to reflect Civetweb rather than the Apache FastCGI | |
214 | front end and specify the port number you intend to use. For example:: | |
215 | ||
216 | [client.radosgw.gateway-node1] | |
217 | host = {hostname} | |
218 | keyring = /etc/ceph/ceph.client.radosgw.keyring | |
219 | log file = /var/log/radosgw/client.radosgw.gateway-node1.log | |
220 | rgw_frontends = civetweb port=80 | |
221 | ||
222 | Finally, restart the Ceph Object Gateway. On Red Hat Enterprise Linux execute:: | |
223 | ||
224 | sudo systemctl restart ceph-radosgw.service | |
225 | ||
226 | On Ubuntu execute:: | |
227 | ||
228 | sudo service radosgw restart id=rgw.<short-hostname> | |
229 | ||
230 | If you used a port number that is not open, you will also need to open that | |
231 | port on your firewall. | |
232 | ||
233 | Configure Bucket Sharding | |
234 | ------------------------- | |
235 | ||
236 | A Ceph Object Gateway stores bucket index data in the ``index_pool``, which | |
237 | defaults to ``.rgw.buckets.index``. Sometimes users like to put many objects | |
238 | (hundreds of thousands to millions of objects) in a single bucket. If you do | |
239 | not use the gateway administration interface to set quotas for the maximum | |
240 | number of objects per bucket, the bucket index can suffer significant | |
241 | performance degradation when users place large numbers of objects into a | |
242 | bucket. | |
243 | ||
244 | In Ceph 0.94, you may shard bucket indices to help prevent performance | |
245 | bottlenecks when you allow a high number of objects per bucket. The | |
246 | ``rgw_override_bucket_index_max_shards`` setting allows you to set a maximum | |
247 | number of shards per bucket. The default value is ``0``, which means bucket | |
248 | index sharding is off by default. | |
249 | ||
250 | To turn bucket index sharding on, set ``rgw_override_bucket_index_max_shards`` | |
251 | to a value greater than ``0``. | |
252 | ||
253 | For simple configurations, you may add ``rgw_override_bucket_index_max_shards`` | |
254 | to your Ceph configuration file. Add it under ``[global]`` to create a | |
255 | system-wide value. You can also set it for each instance in your Ceph | |
256 | configuration file. | |
257 | ||
258 | Once you have changed your bucket sharding configuration in your Ceph | |
259 | configuration file, restart your gateway. On Red Hat Enteprise Linux execute:: | |
260 | ||
261 | sudo systemctl restart ceph-radosgw.service | |
262 | ||
263 | On Ubuntu execute:: | |
264 | ||
265 | sudo service radosgw restart id=rgw.<short-hostname> | |
266 | ||
267 | For federated configurations, each zone may have a different ``index_pool`` | |
268 | setting for failover. To make the value consistent for a region's zones, you | |
269 | may set ``rgw_override_bucket_index_max_shards`` in a gateway's region | |
270 | configuration. For example:: | |
271 | ||
272 | radosgw-admin region get > region.json | |
273 | ||
274 | Open the ``region.json`` file and edit the ``bucket_index_max_shards`` setting | |
275 | for each named zone. Save the ``region.json`` file and reset the region. For | |
276 | example:: | |
277 | ||
278 | radosgw-admin region set < region.json | |
279 | ||
280 | Once you've updated your region, update the region map. For example:: | |
281 | ||
282 | radosgw-admin regionmap update --name client.rgw.ceph-client | |
283 | ||
284 | Where ``client.rgw.ceph-client`` is the name of the gateway user. | |
285 | ||
286 | .. note:: Mapping the index pool (for each zone, if applicable) to a CRUSH | |
287 | ruleset of SSD-based OSDs may also help with bucket index performance. | |
288 | ||
289 | Add Wildcard to DNS | |
290 | ------------------- | |
291 | .. _Add Wildcard to DNS: | |
292 | ||
293 | To use Ceph with S3-style subdomains (e.g., bucket-name.domain-name.com), you | |
294 | need to add a wildcard to the DNS record of the DNS server you use with the | |
295 | ``ceph-radosgw`` daemon. | |
296 | ||
297 | The address of the DNS must also be specified in the Ceph configuration file | |
298 | with the ``rgw dns name = {hostname}`` setting. | |
299 | ||
300 | For ``dnsmasq``, add the following address setting with a dot (.) prepended to | |
301 | the host name:: | |
302 | ||
303 | address=/.{hostname-or-fqdn}/{host-ip-address} | |
304 | ||
305 | For example:: | |
306 | ||
307 | address=/.gateway-node1/192.168.122.75 | |
308 | ||
309 | ||
310 | For ``bind``, add a wildcard to the DNS record. For example:: | |
311 | ||
312 | $TTL 604800 | |
313 | @ IN SOA gateway-node1. root.gateway-node1. ( | |
314 | 2 ; Serial | |
315 | 604800 ; Refresh | |
316 | 86400 ; Retry | |
317 | 2419200 ; Expire | |
318 | 604800 ) ; Negative Cache TTL | |
319 | ; | |
320 | @ IN NS gateway-node1. | |
321 | @ IN A 192.168.122.113 | |
322 | * IN CNAME @ | |
323 | ||
324 | Restart your DNS server and ping your server with a subdomain to ensure that | |
325 | your DNS configuration works as expected:: | |
326 | ||
327 | ping mybucket.{hostname} | |
328 | ||
329 | For example:: | |
330 | ||
331 | ping mybucket.gateway-node1 | |
332 | ||
333 | Add Debugging (if needed) | |
334 | ------------------------- | |
335 | ||
336 | Once you finish the setup procedure, if you encounter issues with your | |
337 | configuration, you can add debugging to the ``[global]`` section of your Ceph | |
338 | configuration file and restart the gateway(s) to help troubleshoot any | |
339 | configuration issues. For example:: | |
340 | ||
341 | [global] | |
342 | #append the following in the global section. | |
343 | debug ms = 1 | |
344 | debug rgw = 20 | |
345 | ||
346 | Using the Gateway | |
347 | ----------------- | |
348 | ||
349 | To use the REST interfaces, first create an initial Ceph Object Gateway user | |
350 | for the S3 interface. Then, create a subuser for the Swift interface. You then | |
351 | need to verify if the created users are able to access the gateway. | |
352 | ||
353 | Create a RADOSGW User for S3 Access | |
354 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
355 | ||
356 | A ``radosgw`` user needs to be created and granted access. The command ``man | |
357 | radosgw-admin`` will provide information on additional command options. | |
358 | ||
359 | To create the user, execute the following on the ``gateway host``:: | |
360 | ||
361 | sudo radosgw-admin user create --uid="testuser" --display-name="First User" | |
362 | ||
363 | The output of the command will be something like the following:: | |
364 | ||
365 | { | |
366 | "user_id": "testuser", | |
367 | "display_name": "First User", | |
368 | "email": "", | |
369 | "suspended": 0, | |
370 | "max_buckets": 1000, | |
371 | "auid": 0, | |
372 | "subusers": [], | |
373 | "keys": [{ | |
374 | "user": "testuser", | |
375 | "access_key": "I0PJDPCIYZ665MW88W9R", | |
376 | "secret_key": "dxaXZ8U90SXydYzyS5ivamEP20hkLSUViiaR+ZDA" | |
377 | }], | |
378 | "swift_keys": [], | |
379 | "caps": [], | |
380 | "op_mask": "read, write, delete", | |
381 | "default_placement": "", | |
382 | "placement_tags": [], | |
383 | "bucket_quota": { | |
384 | "enabled": false, | |
385 | "max_size_kb": -1, | |
386 | "max_objects": -1 | |
387 | }, | |
388 | "user_quota": { | |
389 | "enabled": false, | |
390 | "max_size_kb": -1, | |
391 | "max_objects": -1 | |
392 | }, | |
393 | "temp_url_keys": [] | |
394 | } | |
395 | ||
396 | .. note:: The values of ``keys->access_key`` and ``keys->secret_key`` are | |
397 | needed for access validation. | |
398 | ||
399 | .. important:: Check the key output. Sometimes ``radosgw-admin`` generates a | |
400 | JSON escape character ``\`` in ``access_key`` or ``secret_key`` | |
401 | and some clients do not know how to handle JSON escape | |
402 | characters. Remedies include removing the JSON escape character | |
403 | ``\``, encapsulating the string in quotes, regenerating the key | |
404 | and ensuring that it does not have a JSON escape character or | |
405 | specify the key and secret manually. Also, if ``radosgw-admin`` | |
406 | generates a JSON escape character ``\`` and a forward slash ``/`` | |
407 | together in a key, like ``\/``, only remove the JSON escape | |
408 | character ``\``. Do not remove the forward slash ``/`` as it is | |
409 | a valid character in the key. | |
410 | ||
411 | Create a Swift User | |
412 | ^^^^^^^^^^^^^^^^^^^ | |
413 | ||
414 | A Swift subuser needs to be created if this kind of access is needed. Creating | |
415 | a Swift user is a two step process. The first step is to create the user. The | |
416 | second is to create the secret key. | |
417 | ||
418 | Execute the following steps on the ``gateway host``: | |
419 | ||
420 | Create the Swift user:: | |
421 | ||
422 | sudo radosgw-admin subuser create --uid=testuser --subuser=testuser:swift --access=full | |
423 | ||
424 | The output will be something like the following:: | |
425 | ||
426 | { | |
427 | "user_id": "testuser", | |
428 | "display_name": "First User", | |
429 | "email": "", | |
430 | "suspended": 0, | |
431 | "max_buckets": 1000, | |
432 | "auid": 0, | |
433 | "subusers": [{ | |
434 | "id": "testuser:swift", | |
435 | "permissions": "full-control" | |
436 | }], | |
437 | "keys": [{ | |
438 | "user": "testuser:swift", | |
439 | "access_key": "3Y1LNW4Q6X0Y53A52DET", | |
440 | "secret_key": "" | |
441 | }, { | |
442 | "user": "testuser", | |
443 | "access_key": "I0PJDPCIYZ665MW88W9R", | |
444 | "secret_key": "dxaXZ8U90SXydYzyS5ivamEP20hkLSUViiaR+ZDA" | |
445 | }], | |
446 | "swift_keys": [], | |
447 | "caps": [], | |
448 | "op_mask": "read, write, delete", | |
449 | "default_placement": "", | |
450 | "placement_tags": [], | |
451 | "bucket_quota": { | |
452 | "enabled": false, | |
453 | "max_size_kb": -1, | |
454 | "max_objects": -1 | |
455 | }, | |
456 | "user_quota": { | |
457 | "enabled": false, | |
458 | "max_size_kb": -1, | |
459 | "max_objects": -1 | |
460 | }, | |
461 | "temp_url_keys": [] | |
462 | } | |
463 | ||
464 | Create the secret key:: | |
465 | ||
466 | sudo radosgw-admin key create --subuser=testuser:swift --key-type=swift --gen-secret | |
467 | ||
468 | The output will be something like the following:: | |
469 | ||
470 | { | |
471 | "user_id": "testuser", | |
472 | "display_name": "First User", | |
473 | "email": "", | |
474 | "suspended": 0, | |
475 | "max_buckets": 1000, | |
476 | "auid": 0, | |
477 | "subusers": [{ | |
478 | "id": "testuser:swift", | |
479 | "permissions": "full-control" | |
480 | }], | |
481 | "keys": [{ | |
482 | "user": "testuser:swift", | |
483 | "access_key": "3Y1LNW4Q6X0Y53A52DET", | |
484 | "secret_key": "" | |
485 | }, { | |
486 | "user": "testuser", | |
487 | "access_key": "I0PJDPCIYZ665MW88W9R", | |
488 | "secret_key": "dxaXZ8U90SXydYzyS5ivamEP20hkLSUViiaR+ZDA" | |
489 | }], | |
490 | "swift_keys": [{ | |
491 | "user": "testuser:swift", | |
492 | "secret_key": "244+fz2gSqoHwR3lYtSbIyomyPHf3i7rgSJrF\/IA" | |
493 | }], | |
494 | "caps": [], | |
495 | "op_mask": "read, write, delete", | |
496 | "default_placement": "", | |
497 | "placement_tags": [], | |
498 | "bucket_quota": { | |
499 | "enabled": false, | |
500 | "max_size_kb": -1, | |
501 | "max_objects": -1 | |
502 | }, | |
503 | "user_quota": { | |
504 | "enabled": false, | |
505 | "max_size_kb": -1, | |
506 | "max_objects": -1 | |
507 | }, | |
508 | "temp_url_keys": [] | |
509 | } | |
510 | ||
511 | Access Verification | |
512 | ^^^^^^^^^^^^^^^^^^^ | |
513 | ||
514 | Test S3 Access | |
515 | """""""""""""" | |
516 | ||
517 | You need to write and run a Python test script for verifying S3 access. The S3 | |
518 | access test script will connect to the ``radosgw``, create a new bucket and | |
519 | list all buckets. The values for ``aws_access_key_id`` and | |
520 | ``aws_secret_access_key`` are taken from the values of ``access_key`` and | |
521 | ``secret_key`` returned by the ``radosgw-admin`` command. | |
522 | ||
523 | Execute the following steps: | |
524 | ||
525 | #. You will need to install the ``python-boto`` package:: | |
526 | ||
527 | sudo yum install python-boto | |
528 | ||
529 | #. Create the Python script:: | |
530 | ||
531 | vi s3test.py | |
532 | ||
533 | #. Add the following contents to the file:: | |
534 | ||
535 | import boto.s3.connection | |
536 | ||
537 | access_key = 'I0PJDPCIYZ665MW88W9R' | |
538 | secret_key = 'dxaXZ8U90SXydYzyS5ivamEP20hkLSUViiaR+ZDA' | |
539 | conn = boto.connect_s3( | |
540 | aws_access_key_id=access_key, | |
541 | aws_secret_access_key=secret_key, | |
542 | host='{hostname}', port={port}, | |
543 | is_secure=False, calling_format=boto.s3.connection.OrdinaryCallingFormat(), | |
544 | ) | |
545 | ||
546 | bucket = conn.create_bucket('my-new-bucket') | |
547 | for bucket in conn.get_all_buckets(): | |
548 | print "{name} {created}".format( | |
549 | name=bucket.name, | |
550 | created=bucket.creation_date, | |
551 | ) | |
552 | ||
553 | ||
554 | Replace ``{hostname}`` with the hostname of the host where you have | |
555 | configured the gateway service i.e., the ``gateway host``. Replace ``{port}`` | |
556 | with the port number you are using with Civetweb. | |
557 | ||
558 | #. Run the script:: | |
559 | ||
560 | python s3test.py | |
561 | ||
562 | The output will be something like the following:: | |
563 | ||
564 | my-new-bucket 2015-02-16T17:09:10.000Z | |
565 | ||
566 | Test swift access | |
567 | """"""""""""""""" | |
568 | ||
569 | Swift access can be verified via the ``swift`` command line client. The command | |
570 | ``man swift`` will provide more information on available command line options. | |
571 | ||
572 | To install ``swift`` client, execute the following commands. On Red Hat | |
573 | Enterprise Linux:: | |
574 | ||
575 | sudo yum install python-setuptools | |
576 | sudo easy_install pip | |
577 | sudo pip install --upgrade setuptools | |
578 | sudo pip install --upgrade python-swiftclient | |
579 | ||
580 | On Debian-based distributions:: | |
581 | ||
582 | sudo apt-get install python-setuptools | |
583 | sudo easy_install pip | |
584 | sudo pip install --upgrade setuptools | |
585 | sudo pip install --upgrade python-swiftclient | |
586 | ||
587 | To test swift access, execute the following:: | |
588 | ||
589 | swift -A http://{IP ADDRESS}:{port}/auth/1.0 -U testuser:swift -K '{swift_secret_key}' list | |
590 | ||
591 | Replace ``{IP ADDRESS}`` with the public IP address of the gateway server and | |
592 | ``{swift_secret_key}`` with its value from the output of ``radosgw-admin key | |
593 | create`` command executed for the ``swift`` user. Replace {port} with the port | |
594 | number you are using with Civetweb (e.g., ``7480`` is the default). If you | |
595 | don't replace the port, it will default to port ``80``. | |
596 | ||
597 | For example:: | |
598 | ||
599 | swift -A http://10.19.143.116:7480/auth/1.0 -U testuser:swift -K '244+fz2gSqoHwR3lYtSbIyomyPHf3i7rgSJrF/IA' list | |
600 | ||
601 | The output should be:: | |
602 | ||
603 | my-new-bucket | |
604 | ||
605 | .. _Preflight: ../../start/quick-start-preflight |