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:
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.
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
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), '/');
Comment