Bug 827631 - X-Storage-Url should indicate external IP instead of 127.0.0.1
X-Storage-Url should indicate external IP instead of 127.0.0.1
Status: CLOSED CURRENTRELEASE
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: Documentation (Show other bugs)
2.0
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Divya
Saurabh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-01 18:12 EDT by Etsuji Nakai
Modified: 2016-01-19 01:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-04-10 03:15:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Etsuji Nakai 2012-06-01 18:12:20 EDT
Description of problem:

The return message of authentication request from Swift-API points 127.0.0.1 as X-Storage-Url.

< X-Storage-Url: https://127.0.0.1:443/v1/AUTH_vol01

This is interpreted as the URL for next operation according to the Swift-API protcol. Hence it should points the external IP instead of 127.0.0.1. 

As it returns 127.0.0.1 now, the native swift-client (/usr/bin/swift) cannot be used from a remote client. For example, when you use /usr/bin/swift on the UFO server itself(master01), it works as below:

[root@master01 swift]# swift -A https://master01/auth/v1.0 -U vol01:admin -K pas4vol01admin stat
   Account: AUTH_vol01
Containers: 0
   Objects: 0
     Bytes: 0
Accept-Ranges: bytes
X-Bytes-Used: 0
X-Container-Count: 0
X-Object-Count: 0
    X-Type: Account

However, when you use it from a remote machine(master02), it fails.

[root@master02 ~]# swift -A https://master01/auth/v1.0 -U vol01:admin -K pas4vol01admin stat
// No reply

This is because it receives "X-Storage-Url: https://127.0.0.1:443/v1/AUTH_vol01" on the authentication phase, and it tries to accsess localhost (instead of master01) on next phase (stat info request).

My setup is RHS2.0Beta2.

[root@master01 ~]# rpm -qa | grep gluster
gluster-swift-1.4.8-3.el6.noarch
glusterfs-3.3.0qa38-1.el6.x86_64
glusterfs-fuse-3.3.0qa38-1.el6.x86_64
gluster-swift-container-1.4.8-3.el6.noarch
glusterfs-server-3.3.0qa38-1.el6.x86_64
glusterfs-geo-replication-3.3.0qa38-1.el6.x86_64
gluster-swift-proxy-1.4.8-3.el6.noarch
gluster-swift-account-1.4.8-3.el6.noarch
gluster-swift-plugin-1.0-1.noarch
glusterfs-rdma-3.3.0qa38-1.el6.x86_64
gluster-swift-object-1.4.8-3.el6.noarch
Comment 2 Etsuji Nakai 2012-06-01 18:42:18 EDT
The reason of this behavior is based on the tempauth's implementation as below:

/usr/lib/python2.6/site-packages/swift/common/middleware/tempauth.py
---------
94                     url = 'https://' if 'cert_file' in conf else 'http://'
95                     ip = conf.get('bind_ip', '127.0.0.1')
96                     if ip == '0.0.0.0':
97                         ip = '127.0.0.1'
98                     url += ip
99                     url += ':' + conf.get('bind_port', '8080') + '/v1/' + \
100                            self.reseller_prefix + conf_key.split('_')[1]
---------

It looks up "bind_ip" in proxy-server.conf to build X-Storage-Url. Hence, a workaround is to set bind_ip to a specific external address(eg. bind_ip = master01)

I'm not sure if this is an intended behavior. If so, it should be documented in the user's guide that you have to set the "bind_ip".
Comment 3 Junaid 2012-06-05 02:22:05 EDT
Hi Etsuji,

The users must manually add the option "bind_ip = <ip>" in the proxy-server.conf file so that the swift will return that ip on successful authentication. If the ip is not mentioned, the authentication will use localhost as the ip.

Thanks for identifying it, we will update the documentation.

Junaid
Comment 4 Divya 2012-06-07 07:35:39 EDT
I have added a note for the same and it is available at: http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Storage/2.0/html/Administration_Guide/ch19s04s04.html

Note You need to log in before you can comment on or make changes to this bug.