<tt>> How would I access my Swift storage through a web-server? Is there > anything readily available that I can use? </tt> Sorry, I intended to say web-client, as in browser, not web-server. David Hernandez Contractor / HPSS IBM Global Business Services - US Federal 12301 Kurland Dr Suite 300 Houston, TX 77034-4812 Mobile 713-444-5755 From: Pete Zaitcev <zaitcev@redhat.com> To: David Hernandez/Houston/Contr/IBM@IBMUS Cc: Derek Higgins <derekh@redhat.com>, rhos-list@redhat.com, zaitcev@redhat.com Date: 11/19/2012 09:46 PM Subject: Re: More Swift questions - IBM HPSS VFS as backend storage <hr noshade> <tt>On Thu, 15 Nov 2012 18:00:48 -0600 David Hernandez <dhern@us.ibm.com> wrote: > What is the largest amount of extended attribute data Swift will try to > store for an account/container/object? Sorry to say that, but I do not know. I meant to research it, because I was curious why everyone suggests to allocate 1000-byte inodes (regardless of filesystem). I'll let you know what I find. > I am currently using the swift command utility locally to upload and list > containers and objects in my Swift (Essex Preview) install. What changes > do I need to do to my configuration to allow secure remote client access > to my Swift storage. I know I will need to create some self-signed > certificates but don't know to get it to work with my current > configuration. I would like still be able to access locally using the > swift command which uses port 8080. > > How would I access my Swift storage through a web-server? Is there > anything readily available that I can use? I sense a certain confusion here. Swift is a webserver and it uses token-based authentication over HTTP. "Local" swift(1) command is exactly the same as remote. So, if your Swift cluster is configured with proper authentication (e.g. swauth or Keystone), and SSL is configured, swift(1) or other apps can traverse public Internet in reasonable safety. But in any case, it makes little sense to talk about a separate "web-server". Note that in many installations, a load balancer terminates SSL in front of Swift proxy server, and so the client-visible endpoint could end at port 431 at LB's outside interface. This may not be well addressed in the documentation, being an operational detail. If this happens, there's a difference between "local" and "remote", like you said. I hope I did not confuse you even further with this. -- Pete </tt>