Results 1 to 8 of 8

Thread: Remote gui not accessible in Phoronix Test Suite 5.2

  1. #1
    Join Date
    Jun 2014
    Posts
    5

    Default Remote gui not accessible in Phoronix Test Suite 5.2

    Hello,

    I came across to a potential bug in the WebSocket server setup procedure that prevents the Web gui to be accessible from a different host than the one where the test suite has been installed.

    To be more specific, I've installed the test suite on Ubuntu Server and started the remote gui via the command:
    Code:
    $ phoronix-test-suite start-remote-gui-server
    Of course I had performed all the necessary configuration setup in user-config.xml.

    When I tried to access the gui from a different machine, the page in the browser failed to load the contend and was continuously displaying the message: Connecting to WebSocket server.

    After some investigations I found the culprit in the content of the pts_websocket_server cookie. The WebSocket URL was not correct, it contained the IP of the local host (where the browser is running) instead of the remote server (where the WebSocket is listening to connections).

    A quick and dirty hack was to edit /usr/share/phoronix-test-suite/pts-core/objects/pts_webui.php and rewrite the server address, as you may see bellow.
    It fixed the issue but I'm wondering if that is indeed a bug or maybe a miss-configuration issue.

    PHP Code:
    // For some reason websockets don't seem to like ::1 which is ipv6 localhost.
    // So we will work around it by just pointing to localhost instead.
    if($_SERVER['REMOTE_ADDR'] === '::1')
    {
            
    $server_address 'localhost';
    }
    else
    {
            
    $server_address $_SERVER['REMOTE_ADDR'];
    }

    // Dirty fix for WebSocket address not reachable from remote clients
    $server_address '<server_IP>';

    define('PTS_WEBSOCKET_SERVER''ws://' $server_address ':' $pts_ws_port '/');
    setcookie('pts_websocket_server'PTS_WEBSOCKET_SERVER, (time() + 60 60 24), '/'); 

  2. #2

    Default

    What OS are you running this from?

  3. #3
    Join Date
    Jun 2014
    Posts
    5

    Default

    Hello Michael,

    Thank you for your prompt reply!

    The test suite has been installed on Ubuntu Server 14.04.
    I was accessing the Web UI from both Chromium and Firefox running on an older Ubuntu distro (10.04).

    I could try to revert the changes I've made to the test suite and then access it from a newer distro (e.g. Linux Mint 17 that is based on Ubuntu 14.04), although this shouldn't make any difference since it only relates to the web browser..

    Kind regards,
    Cristi
    Last edited by cristicc; 06-24-2014 at 02:12 AM.

  4. #4
    Join Date
    Jun 2014
    Posts
    5

    Default

    I don't have any experience with PHP development, but as far as I understood from the manual, 'REMOTE_ADDR' should be the IP address from which the user is viewing the current page. And that is also confirmed by the behavior I have already noticed.
    Instead, we should use either 'SERVER_ADDR' or 'LOCAL_ADDR' to set the web socket server address in the cookie, but unfortunately they are not available and therefore no values are returned.

    I added some debug info in the syslog when the websocket_setup_defines function is executed, just before applying the manual address override patch:

    PHP Code:
    syslog(LOG_WARNING"websocket_setup_defines: $access ServerAddr={$_SERVER['SERVER_ADDR']} LocalAddr={$_SERVER['LOCAL_ADDR']} RemoteAddr={$_SERVER['REMOTE_ADDR']} UserAgent={$_SERVER['HTTP_USER_AGENT']}"); 
    Here is the output in the log when a request is done from the remote client on http://171.18.38.20:8080/:

    Code:
    Jun 25 01:28:11 ubuntu-server-vm Phoronix Test Suite: websocket_setup_defines:  ServerAddr= LocalAddr= RemoteAddr=171.18.38.1 UserAgent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36
    I expected to have ServerAddr and/or LocalAddr set to one of the IPs available on the server. There are two network interfaces available there:

    Code:
    IP address for eth0: 192.168.1.7
    IP address for eth1: 171.18.38.20
    The RemoteAddr is the one from which the request is made, which is correct since the 171.18.38.1 is the IP on the remote host, where the browser is running.
    I've no idea how should we get the server address to which the request has been made, which is 171.18.38.20 in this case.

  5. #5
    Join Date
    Jun 2014
    Posts
    5

    Default

    I don't have any experience with PHP development, but as far as I understood from the manual, 'REMOTE_ADDR' should be the IP address from which the user is viewing the current page. And that is also confirmed by the behavior I have already noticed.
    Instead, we should use either 'SERVER_ADDR' or 'LOCAL_ADDR' to set the web socket server address in the cookie, but unfortunately they are not available and therefore no values are returned.

    I added some debug info in the syslog when the websocket_setup_defines function is executed, just before applying the manual address override patch:

    PHP Code:
    syslog(LOG_WARNING"websocket_setup_defines: $access ServerAddr={$_SERVER['SERVER_ADDR']} LocalAddr={$_SERVER['LOCAL_ADDR']} RemoteAddr={$_SERVER['REMOTE_ADDR']} UserAgent={$_SERVER['HTTP_USER_AGENT']}"); 
    Here is the output in the log when a request is done from the remote client on http://171.18.38.20:8080/:

    Code:
    Jun 25 01:28:11 ubuntu-server-vm Phoronix Test Suite: websocket_setup_defines:  ServerAddr= LocalAddr= RemoteAddr=171.18.38.1 UserAgent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36
    I expected to have ServerAddr and/or LocalAddr set to one of the IPs available on the server. There are two network interfaces available there:

    Code:
    IP address for eth0: 192.168.1.7
    IP address for eth1: 171.18.38.20
    The RemoteAddr is the one from which the request is made, which is correct since the 171.18.38.1 is the IP on the remote host, where the browser is running.
    I've no idea how should we get the server address to which the request has been made, which is 171.18.38.20 in this case.

  6. #6
    Join Date
    Jun 2014
    Posts
    5

    Default

    I don't have any experience with PHP development, but as far as I understood from the manual, 'REMOTE_ADDR' should be the IP address from which the user is viewing the current page. And that is also confirmed by the behavior I have already noticed.
    Instead, we should use either 'SERVER_ADDR' or 'LOCAL_ADDR' to set the web socket server address in the cookie, but unfortunately they are not available and therefore no values are returned.

    I added some debug info in the syslog when the websocket_setup_defines function is executed, just before applying the manual address override patch:

    PHP Code:
    syslog(LOG_WARNING"websocket_setup_defines: $access ServerAddr={$_SERVER['SERVER_ADDR']} LocalAddr={$_SERVER['LOCAL_ADDR']} RemoteAddr={$_SERVER['REMOTE_ADDR']} UserAgent={$_SERVER['HTTP_USER_AGENT']}"); 
    Here is the output in the log when a request is done from the remote client on 171.18.38.20:8080.

    Code:
    Jun 25 01:28:11 ubuntu-server-vm Phoronix Test Suite: websocket_setup_defines:  ServerAddr= LocalAddr= RemoteAddr=171.18.38.1 UserAgent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36
    I expected to have ServerAddr and/or LocalAddr set to one of the IPs available on the server. There are two network interfaces available there:

    Code:
    IP address for eth0: 192.168.1.7
    IP address for eth1: 171.18.38.20
    The RemoteAddr is the one from which the request is made, which is correct since the 171.18.38.1 is the IP on the remote host, where the browser is running.
    I've no idea how should we get the server address to which the request has been made, which is 171.18.38.20 in this case.

  7. #7
    Join Date
    Jul 2014
    Posts
    1

    Default

    Hi, I have the same problem. I think you're right the server_address should be fetched from $_SERVER['SERVER_ADDR'] instead of $_SERVER['REMOTE_ADDR'].
    However the $_SERVER['SERVER_ADDR'] is not set on my test machines (server is Apache on Ubuntu 14.04 and client is using Firefox).
    So we need a reliable way to get the server's IP address. I modify the file as following:

    PHP Code:
    if(!isset($_SERVER['SERVER_ADDR'])) {
            
    $_SERVER['SERVER_ADDR'] = gethostbyname(gethostname());
    }

    if(
    $_SERVER['SERVER_ADDR'] === '::1'

            
    $server_address 'localhost'

    else 

            
    $server_address $_SERVER['SERVER_ADDR']; 

    This method relies on /etc/hosts file to map hostname to its IP Address.
    Another way is to use "ifconfig" to get the server's IP address.

  8. #8

    Default

    Quote Originally Posted by naevus View Post
    Hi, I have the same problem. I think you're right the server_address should be fetched from $_SERVER['SERVER_ADDR'] instead of $_SERVER['REMOTE_ADDR'].
    However the $_SERVER['SERVER_ADDR'] is not set on my test machines (server is Apache on Ubuntu 14.04 and client is using Firefox).
    So we need a reliable way to get the server's IP address. I modify the file as following:

    PHP Code:
    if(!isset($_SERVER['SERVER_ADDR'])) {
            
    $_SERVER['SERVER_ADDR'] = gethostbyname(gethostname());
    }

    if(
    $_SERVER['SERVER_ADDR'] === '::1'

            
    $server_address 'localhost'

    else 

            
    $server_address $_SERVER['SERVER_ADDR']; 

    This method relies on /etc/hosts file to map hostname to its IP Address.
    Another way is to use "ifconfig" to get the server's IP address.
    Should be fixed in Git, thanks.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •