Path Prefix change

Before you post: Your responses to these questions will help the community help you. Please complete this template if you’re asking a support question.
Don’t forget to select tags to help index your topic!

1. Describe your incident:
Currently my Graylog 4.2.9 is running the web interface from http://10.0.0.1/. In other words it has no path prefix. But I now want a prefix such that it looks like http://10.0.0.1/path_prefix/

It seems like from Graylog 3.0.x, it is possible to implement this path prefix in /etc/graylog/server/server.conf by modifying http_publish_uri

http_publish_uri = http://$http_bind_address:9000/path_prefix

After the modifications, I get what I want. But I also get an error in the logs

2023-02-16T16:28:15.997+02:00 WARN [ProxiedResource] Unable to call http://path_prefix/api/system/metrics/multiple on node <5483c7b2-b7e8-44d7-9f92-7c8a6ab8a118>, result: Service Unavailable

2. Describe your environment:

  • OS Information:
    Rocky Linux 8
  • Package Version:
    Graylog 4.2.9
  • Service logs, configurations, and environment variables:

Error log →
2023-02-16T16:28:15.997+02:00 WARN [ProxiedResource] Unable to call http://path_prefix/api/system/metrics/multiple on node <5483c7b2-b7e8-44d7-9f92-7c8a6ab8a118>, result: Service Unavailable

3. What steps have you already taken to try and solve the problem?

I also tried to set http_external_uri to match this new path prefix I want to use. But this doesnt suppress the error message. It also looks like the target path is not correct as it doesnt address the server via 10.0.0.1 or 127.0.0.1.

4. How can the community help?
Can the community point me in the direction for resolving this error?

Helpful Posting Tips: Tips for Posting Questions that Get Answers [Hold down CTRL and link on link to open tips documents in a separate tab]

Hey @ofentselogger

I think because of the API system && Web UI. It seams to be hardcoded for…

http://8.8.8.8:9000

Perhaps try testing this out with a load balancer like Apache or Nginx.

Actually I was trying the Graylog config because I was avoiding the Apache troubles I experience. Either way I still have to use Apache Reverse Proxy.

With Apache, I get error 404. Here is the lastest config I use for Apache based on some solutions I saw in the forum:
Is the RequestHeader part suitable? I have some doubts as to what to put in in place of localhost.

<Location /graylog>
        RequestHeader set X-Graylog-Server-URL "http://localhost/api/"
        ProxyPass http://graylog_ip/ nocanon
        ProxyPassReverse http://graylog_ip/
</Location>

hey @ofentselogger

I was think something like this.

<VirtualHost *:80>
    ServerName graylog.example.org
    ProxyRequests Off
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    <Location />
        RequestHeader set X-Graylog-Server-URL "http://graylog.example.org/"
        ProxyPass http://127.0.0.1:9000/
        ProxyPassReverse http://127.0.0.1:9000/
    </Location>

</VirtualHost>

Oh yes this is it. So I must literally use graylog.example.org as the server name? This is where I got confused. If yes, I will implement this.

Also I use port forwarding on Graylog server to hide the port 9000. I guess in Apache I can then ignore port 9000 since I access my graylog as http://graylog_ip/ on port 80. I guess I can easily figure this one out myself as my port 9000 is still available for use if I want to say http://graylog_ip:9000/.

Aaa @gsmith, I missed a small detail. In your proxy script you are referring to Graylog on 127.0.0.1. I assume that Apache is loaded on the Graylog server.

In my case, I am literally proxying from a different server for firewall reasons. I am not sure if this makes a material difference. But I have tried your config and I still get 404 error.

Maybe I can get a better effect with nginx on graylog server so that everything works well for the Apache front end.

The NGINX route seems relatively straightforward. I just enjoyed success with this route. What is nice is that if you go to the Graylog manual, you get the exact configuration needed for it to work. When you couple/cascade it with an Apache proxy on a different machine, it seems to be magical.

Now I can proxy via Apache on the firewall edge in order to deliver the required result :slight_smile:

I am sure there are solutions simpler than mine without having to cascade multiple proxies. I am just happy that mine works.

1 Like

Hey @ofentselogger

Awesome, sorry I was on va-ca.YYeah I probably should have said something about nginx I accualy use that instead plus just an FYI you can check this out from one of our members.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.