New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Graylog Enterprise Report generation failing #10267
Comments
Hey @ahmedsajid, thanks for reporting this! Your issue was well-written, contained the right details and helped a lot debugging this problem. While For now, a workaround would be to make |
Hi @dennisoelkers, You are very welcome. I understand the pain of trying to troubleshoot an issue without the other party providing the full detail. And I'm conscious of community effort here and I didn't want to create additional work without doing due diligence and thinking its a problem with the software while it might be a user error. I appreciate your rapid response on this. I'll add the DNS entry as a workaround for now. Thank you! |
If it helps others with a weird setup such as mine, the following workaround did the job for me. |
Prior to this change, all web interface assets were qualified according from the following data points, in order of precedence: - The `X-Graylog-Server-URL` header of the request - The `http_external_uri` config setting - The `http_publish_uri` config setting While this helps us supporting a couple of scenarios where the Graylog server is accessed through a reverse proxy, it also produces issues when naming schemes are different internally and externally and access from both directions is desired. The only scenario which works in these cases is configuring a valid `http_publish_uri`/`http_external_uri` for internal and using the `X-Graylog-Server-URL` on the proxy for external clients. This is related to all of these settings being absolute URLs, resulting in generating absolute URLs for the web assets as well, unnecessarily. In all of the cases this complexity of configuration would be unnecessary, if the references to the web assets would be relative. This would support all of the aforementioned use cases and does not rely on proper configuration of any of the settings _in order to be able to load the web assets properly_ if there is no additional path prefix. Therefore, this PR is determining the effective external URI in the same way as listed before, but takes only the path part of it to prefix all web assets. Fixes #10632. Fixes #10267.
Prior to this change, all web interface assets were qualified according from the following data points, in order of precedence: - The `X-Graylog-Server-URL` header of the request - The `http_external_uri` config setting - The `http_publish_uri` config setting While this helps us supporting a couple of scenarios where the Graylog server is accessed through a reverse proxy, it also produces issues when naming schemes are different internally and externally and access from both directions is desired. The only scenario which works in these cases is configuring a valid `http_publish_uri`/`http_external_uri` for internal and using the `X-Graylog-Server-URL` on the proxy for external clients. This is related to all of these settings being absolute URLs, resulting in generating absolute URLs for the web assets as well, unnecessarily. In all of the cases this complexity of configuration would be unnecessary, if the references to the web assets would be relative. This would support all of the aforementioned use cases and does not rely on proper configuration of any of the settings _in order to be able to load the web assets properly_ if there is no additional path prefix. Therefore, this PR is determining the effective external URI in the same way as listed before, but takes only the path part of it to prefix all web assets. Fixes #10632. Fixes #10267.
…nd backend API. (#10726) * Use relative URLs for web interface assets served by Graylog server. Prior to this change, all web interface assets were qualified according from the following data points, in order of precedence: - The `X-Graylog-Server-URL` header of the request - The `http_external_uri` config setting - The `http_publish_uri` config setting While this helps us supporting a couple of scenarios where the Graylog server is accessed through a reverse proxy, it also produces issues when naming schemes are different internally and externally and access from both directions is desired. The only scenario which works in these cases is configuring a valid `http_publish_uri`/`http_external_uri` for internal and using the `X-Graylog-Server-URL` on the proxy for external clients. This is related to all of these settings being absolute URLs, resulting in generating absolute URLs for the web assets as well, unnecessarily. In all of the cases this complexity of configuration would be unnecessary, if the references to the web assets would be relative. This would support all of the aforementioned use cases and does not rely on proper configuration of any of the settings _in order to be able to load the web assets properly_ if there is no additional path prefix. Therefore, this PR is determining the effective external URI in the same way as listed before, but takes only the path part of it to prefix all web assets. Fixes #10632 Fixes #10267 * Use relative URL for backend API as well. * Removing unused check for trailing slash. * Use relative URL for `index.html` in dev too. * Use relative URL in documentation REST resources. * Support relative URLs in shred library, used by swagger. * Removing commented out section.
@ahmedsajid: Starting with |
I wonder if this bug is not somehow back. I'm using 4.2.1 and my config looks like : 10.0.0.2:9000 -> http and IP only reverse-proxy -> CDN (resolves for mydomain.com and does the SSL) When generating report the chrome_debug.log shows that the resources are fetched from
Of course this fails as the server sends the http graylog "homepage" instead of the actual resource: expected behavior : actual behavior : Same if I do not set |
First of all, I appreciate all the work the Graylog Community and maintainers put into it to make it a GREAT product.
In my current setup, Graylog Cluster of 3 nodes is setup as follows:
Client -> Load balancer (443) -> Nginx (https 9000) -> Graylog (https 9001)
Client browser accesses Graylog via IP on Load Balancer as url
https://graylog.example.com/
URL. This is also thehttp_external_uri
.graylog.example.com
is not a DNS entry that server can resolve but it works on the client's machines.Then there's
http_publish_uri
set tohttps://<NodeIP>:9001/
.All of the functionality works as expected. However after installation of the Graylog Small Business Enterprise License for the reporting feature, whenever I try to generate report through the UI, I get following error:
According to the doc as I understood I need to adjust the
report_render_uri
which I have set tohttps://<NodeIP>:9001/
.Now I can solve this problem by adding entry for
graylog.example.com
in/etc/hosts
file but and I also want to know ifreport_render_uri
config if its working as expected or not? Did I misconfigure anything?Here's Nginx configuration for Graylog. Not sure if that makes a difference.
Expected Behavior
Report plugin to use
report_render_uri
for report generation.Current Behavior
Report plugin seems to use
http_external_uri
for report generation.Possible Solution
Steps to Reproduce (for bugs)
Send Report Now
to trigger generation of the particular report to be emailed after completion.Context
Trying to configure scheduled reports to be delivered via email.
Your Environment
The text was updated successfully, but these errors were encountered: