Websocket server configuration???

[emilfihlman]

The documentation is frankly very bad regarding the real time configuration. What, exactly, does --ws-url configure?

There are two different things that we should be able to configure:

1. Where the client tries to connect to for updates
2. Where the integrated websocket server listens at

In addition, the server should support unix domain sockets.

[emilfihlman]

Also the real time example doesn't work, the websocket connection times out.

[neocogent]

--ws-url is where the websocket listens, --port is where the html page is served that opens the websocket. It took me many trials to get his all figured out but it does work once setup correctly. I have now used this in my gopanel web menu interface for multiple log files.

Here's an example how I start goaccess for web interface behind a nginx reverse proxy with ssl.

/usr/bin/goaccess -a -g --real-time-html -p my.conf --port 7890

And in my.conf:

# example goaccess conf file for gopanel
# edit site1 values and change title to suit
html-report-title Site One

# the logs you want to process
log-format COMBINED
log-file /var/log/nginx/site1-access.log

# the location you will host from
output-format /var/www/example.com/gopanel/site1.html
ws-url wss://www.example.com/gopanel/ws:443

# other options as you prefer
ignore-crawlers true
ignore-referer example.com

And nginx include file to do the ssl proxying (include in existing ssl site conf using port 443) :

# gopanel nginx include 

location /gopanel {
    auth_basic "Admin Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
location /gopanel/ {
    proxy_pass http://localhost:7880/;
}
location /gopanel/ws {
    proxy_connect_timeout 7d;
    proxy_send_timeout 7d;
    proxy_read_timeout 7d;
    proxy_pass http://localhost:7890;
}

Hopefully this sheds some light on actually running it. I know it looks more complicated but this is actually working and on any real site you're going to want ssl and admin auth anyway. You can use openssl to create .htpasswd file. Just google that. Anyway, at least you can mimic my options for a working setup.

You may find the websocket times out if you proxy it without the timeout values increased.

Ignore port 7880 and gopanel as that's where my web menu is served not the goaccess itself.

[allinurl]

Thanks for the feedback, I'll look into expanding the documentation.

Just adding to the great info posted by @neocogent,

As indicated in the FAQ, --ws-url=<host> specifies the location/address/host where GoAccess is running and parsing logs. For instance, if GoAccess is running on my EU AWS instance, then I can point to that machine IP/hostname. Note that if you load the report.html from an HTTPS address, the report will automatically attempt to connect via a secure web socket (wss). Please make sure <host> is a valid host and should not contain http on it. If you are behind a proxy, you can also specify the port as well, --ws-url=wss://tld.com:443.

As far as --port=7890, essentially you can specify which port GoAccess should listen on. By default it will listen on 7890. You can listen on a different port if you choose to do so.

Can you please post how you are running goaccess and any relevant details about your environment and also the output of your browser's console. Thanks

[emilfihlman]

Ideally, I would give the client an URL, consisting of a protocol, a host, a port and a resource. This can all be handled to the WebSocket constructor as is so nothing special needs to be actually done with the argument given in the command line, it can be used directly.

Ideally, I would give the server a tuple of a protocol and a location. The location can either be a port or a filesystem path. Supporting abstract paths is also possible and of course recommended, perhaps it could be marked with having a leading space in the name.

These should be passed as something like: --ws-client-url and --ws-server-location, for example

--ws-client-url "wss://domain.tld/resource"

--ws-server-location "ws:///path"

--ws-server-location "wss://:9001"

--ws-server-location "wss:// abstract"

Of course one could have mutually exclusive options or even separate options just for protocol and port and path and that's not actually a too bad of a idea, as long as they are documented clearly.

I'll try the suggestions and see if I can get the thing working, but it seems to be exactly what I was after! Thanks @neocogent and @allinurl

[desnudopenguino]

not sure if this fits in here, i'm trying to run goaccess with --real-time-html, first time it would produce a static page. I followed the guide in the README. so i came to the github repo, and found this issue, i tried following it, but now i'm getting a blank page when i try to access the webpage. I thought I'd try to figure it out modelling it after the notes in this issue thread, but with no luck.

config file:

html-report-title Test
log-format COMBINED
log-file /var/log/nginx/access.log
output-format /home/bucky/receipts/public/report.html
ws-url ws://10.0.0.111/gopanel/ws

and the pertinent part of my nginx.conf: (i'm just messing around locally, so no need for ssl yet)

location /gopanel/ {
    proxy_pass http://localhost:7880/;
}

location /gopanel/ws {
    proxy_connect_time 7d;
    proxy_send_timeout 7d;
    proxy_read_timeout 7d;
    proxy_pass http://localhost:7890;
}

and my command is goaccess -a -g --real-time-html -p goaccess.conf --port 7890

the websocket output in the terminal says: Accepted: 12 127.0.0.1 Active: 0

Is there something I'm missing, or something in a guide somewhere that's more useful? i feel a little dumbfounded.

[neocogent]

You don't need the first location section there. That is for my gopanel daemon. I should have removed it from above but was lazy. It listens on port 7880 and unless you are running it (in which case post on my gopanel github for help) it's not there.

The static page location is defined by the output-format line in the conf. It has to match the location that your nginx conf points to. I can't tell that from your conf. There needs to be some conf line that makes some page on your site load the file: /home/bucky/receipts/public/report.html

Here's how it works:

goaccess will start up and write the static report page, which should be served by nginx. When your browser loads that it uses the embedded ws-url value to open a websocket connection which nginx will proxy to port 7890, where goaccess will handle it.

If nginx is serving https for your site then use wss for the ws-url, otherwise ws should work (but I've not tested plain ws myself).

Hope this helps.

edit: actually there is a bit of trick in that first location section. The fact the location and proxy end with "/" cause only items after the url to be proxied and not the directory index itself. That gets handled by the base conf (that is including this one). That's not very obvious but it's why on my gopanel the static page gets served by nginx but the sub items get proxied to gopanel daemon. So this means for you something has to be added to make sure the static page gets served.

[desnudopenguino]

@neocogent Thanks a ton! I got it figured out with your help. Another part of the issue is that I'm running a web proxy (squid) on some browsers, and it's not passing the web socket through. On a non-proxied browser it's working like a charm!

[narayan1599]

Thanks for the feedback, I'll look into expanding the documentation.

Just adding to the great info posted by @neocogent,

As indicated in the FAQ, --ws-url=<host> specifies the location/address/host where GoAccess is running and parsing logs. For instance, if GoAccess is running on my EU AWS instance, then I can point to that machine IP/hostname. Note that if you load the report.html from an HTTPS address, the report will automatically attempt to connect via a secure web socket (wss). Please make sure is a valid host and should not contain http on it. If you are behind a proxy, you can also specify the port as well, --ws-url=wss://tld.com:443.

As far as --port=7890, essentially you can specify which port GoAccess should listen on. By default it will listen on 7890. You can listen on a different port if you choose to do so.

Can you please post how you are running goaccess and any relevant details about your environment and also the output of your browser's console. Thanks

can u give full example

[beucismis]

--ws-url is where the websocket listens, --port is where the html page is served that opens the websocket. It took me many trials to get his all figured out but it does work once setup correctly. I have now used this in my gopanel web menu interface for multiple log files.

Here's an example how I start goaccess for web interface behind a nginx reverse proxy with ssl.

/usr/bin/goaccess -a -g --real-time-html -p my.conf --port 7890

And in my.conf:

# example goaccess conf file for gopanel
# edit site1 values and change title to suit
html-report-title Site One

# the logs you want to process
log-format COMBINED
log-file /var/log/nginx/site1-access.log

# the location you will host from
output-format /var/www/example.com/gopanel/site1.html
ws-url wss://www.example.com/gopanel/ws:443

# other options as you prefer
ignore-crawlers true
ignore-referer example.com

And nginx include file to do the ssl proxying (include in existing ssl site conf using port 443) :

# gopanel nginx include 

location /gopanel {
    auth_basic "Admin Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
location /gopanel/ {
    proxy_pass http://localhost:7880/;
}
location /gopanel/ws {
    proxy_connect_timeout 7d;
    proxy_send_timeout 7d;
    proxy_read_timeout 7d;
    proxy_pass http://localhost:7890;
}

Hopefully this sheds some light on actually running it. I know it looks more complicated but this is actually working and on any real site you're going to want ssl and admin auth anyway. You can use openssl to create .htpasswd file. Just google that. Anyway, at least you can mimic my options for a working setup.

You may find the websocket times out if you proxy it without the timeout values increased.

Ignore port 7880 and gopanel as that's where my web menu is served not the goaccess itself.

Thanks.