baseURL setting doesn't seem to work

[bryanrossUK]

Hi,

First of all, great job on this. I originally looked at an ELK stack for my home server, but the cpu/memory usage was just crazy. Logsniffer does a much better job!

I've got logsniffer working nicely (in a docker container no less) - but I was hoping to change the base URL to something more friendly. I tried setting it in the GUI and played around with a few variations in the config.properties file, but no matter what I do, Logsniffer still keeps producing URLs based on / (e.g. /static/, /c/, etc). Any ideas?

[archenroot]

@liquidstate and what is your intention, what do you want? You mean the ending / is a problem?

[mbok]

Did you tried the '-Dlogsniffer.contextPath' JVM system property to be passed via command line? It's described on the Wiki page https://github.com/logsniffer/logsniffer/wiki/3.-Extended-setup. This setting take effect only when passed from command line.

[bryanrossUK]

Hi @archenroot, my intention is to put Logsniffer behind an Nginx reverse proxy such that requests for http://mydomain.com/logs get proxied to http://mydomain.com:8082/. I've set up the proxy, but it doesn't work correctly because Logsniffer produces HTML assuming that the root URL path (/). I want to reconfigure Logsniffer to produce links that use /logs

The description of the Base URL setting in the General Settings page would seem to do what I want, but when I enter http://mydomain.com/logs, it doesn't make any difference to the HTML produced by Logsniffer.

Base URL Specify the HTTP address of the logsniffer installation, such as http://yourhost.yourdomain/logsniffer/. This value is used to let logsniffer know how to refer to itself, ie. to to create links in emails etc. for referencing events and other resources.

I've also now tried your suggestion @mbok of using the logsniffer.contextPath JVM option from the Extended Setup wiki page, but that doesn't seem to do anything either:

logsniffer.contextPath The context path of logsniffer's web interface. The default is / — i.e. exposing logsniffer from the root path. For example, to make logsniffer accessible at http://localhost:8082/logsniffer, set -Dlogsniffer.contextPath=logsniffer.

$ ps auxw | grep logsniffer logsniffer 33204 59.8 5.8 3091820 356056 ? Sl 20:33 0:30 /usr/bin/java -jar -Dlogsniffer.home=/logsniffer -Dlogsniffer.contentPath=logs -Dlogsniffer.httpPort=8082 /logsniffer.war

In both cases, the HTML produced by Logsniffer assumes the URL path to be / resulting in things like this:

<link href="/static/logsniffer.css?v=0.5.6" rel="stylesheet" /> <a href="/c/sources">Logs</a>

I'm running Logsniffer version 0.5.6 by the way, with Google Chrome in Developer mode with Caching disabled. Any ideas?

[archenroot]

Hm, could you please show the relevant "location" or complete "http" block from nginx.conf file?

Anyway, I will install tomorrow on my nginx reverse proxy and test it myself and return back.

[bryanrossUK]

Thanks @archenroot, my Nginx config is very basic (and working well for other tools like Gogs, Tonido, etc).

server {
    listen 80;
    server_name mydomain.com;

    location /logs/ {
        proxy_pass http://mydomain.com:8082/;
    }

When I visit http://mydomain.com/logs, it successfully returns the Logsniffer HTML, but the CSS formatting is all broken (because its trying to source files from locations beginning with /static/..) and the links are broken (because they're pointing at /c/...).

I've confirmed that the reverse proxy is serving up those files as I would expect: e.g. http://mydomain.com/logs/static/logsniffer.css returns the expected CSS file. So, if I could get Logsniffer to prepend its URLs with /logs/, everything should work.

[bryanrossUK]

I've also double checked the HTML output using curl at the command line just to rule out any silly browser caching!

[mbok]

You have a typo in the command line, please use this parameter: -Dlogsniffer.contextPath=logs

[bryanrossUK]

So sorry for wasting your time gents, I'm a muppet! I can confirm that using -Dlogsniffer.contextPath does indeed work as documented and now my reverse proxy is happy. Many thanks!

(there still looks like a bug with Base URL in the GUI unless I misunderstand its function)