Bug 827631

Summary: X-Storage-Url should indicate external IP instead of 127.0.0.1
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Etsuji Nakai <enakai>
Component: DocumentationAssignee: Divya <divya>
Status: CLOSED CURRENTRELEASE QA Contact: Saurabh <saujain>
Severity: high Docs Contact:
Priority: unspecified    
Version: 2.0CC: ashetty, asriram, gluster-bugs, mzywusko, sdharane, storage-doc
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-10 07:15:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Etsuji Nakai 2012-06-01 22:12:20 UTC 
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 22:42:18 UTC 
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 06:22:05 UTC 
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 11:35:39 UTC 
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