Closed aallrd closed 6 months ago
Just reading through, this does not seem like a specific issue that pertains towards self-hosted Sentry. I will transfer this over to symbolicator
I believe your DNS resolves to any one of these ranges, which is then resulting in such errors:
You should be able to set the connect_to_reserved_ips
to true
in order to circumvent this. @hubertdeng123 can help you find symbolicators config file, as I’m unsure how exactly one can modify that in self-hosted.
I think enabling this setting should be reasonable in self-hosted, as you control the whole infra and events, so there shouldn’t be any possibility of leaking internal requests via things like source context, etc.
Hello, Thank you for looking at this issue. I confirm that our network is configured in one of these ranges.
I added the configuration in the symbolicator/config.yml file in the Sentry self-hosted source bundle:
echo "connect_to_reserved_ips: true" >> symbolicator/config.yml
After restarting the docker-compose stack the "download failed: destination is restricted" error was gone.
Side questions if I may:
debuginfod-find
client, do you know why ?I assume you are using the Sentry-provided Symbolicator Docker image? So it might not be that straight forward to just add your custom CA to the system certificate store.
Otherwise, we have recently added a per-source configuration that skips certificate validation, like so: https://github.com/getsentry/sentry/blob/f3b740199ef0b8057c2c68a377fd3b4d42346deb/src/sentry/conf/server.py#L3324-L3330 Though this I believe is not exposed as a global setting (@loewenheim ?), and its also not exposed in the symbol source configuration UI. It was just added recently as a workaround for a "misbehaving" public symbol server.
Similarly, the /buildid/
path has to be part of the url by convention (and for backwards compatibility):
https://github.com/getsentry/sentry/blob/f3b740199ef0b8057c2c68a377fd3b4d42346deb/src/sentry/conf/server.py#L3387-L3394
Glad to hear things are working out otherwise, I will close this issue then.
@Swatinem Correct, I'm not sure we want to expose this setting to users.
Self-Hosted Version
24.2.0
CPU Architecture
x86_64
Docker Version
20.10.23
Docker Compose Version
2.15.1
Steps to Reproduce
I have a demo C++ program
sentry_crash
that I am using to try the Sentry native crash reporting feature. It uses the Sentry Native SDK 0.7.0, and is compiled from the source file _sentrycrash.cpp:I have a processing script that creates a debuginfo archive that I upload on our internal debuginfod server at https://debuginfod.company.com:
Once this archive is uploaded and processed on the debuginfod server, I can query it successfully using
debuginfod-find
:I have configured this debuginfod instance as SymbolServer Repository on my Sentry project:
Expected Result
After the
sentry_crash
binary is executed, I expect the native crash issue reported in Sentry to be symbolicated and the source context to be available.Actual Result
It seems that Sentry is not able to pull data from the debuginfod server:
I manually uploaded the _sentrycrash binary using the Sentry CLI:
It was still not able to report a symbolicated issue with source context. In the Debug Files Candidates view I found that Sentry seemed to contact the debuginfod server with the correct build ID but failed with an error: "download failed: destination is restricted":
I disabled SSL on the debuginfod server with the same result.
I tried to serve the files with a plain HTTP server after reading in the doc that "The files need to reside under buildid/ on the server." but it did not change anything:
Manually downloading the file was possible from the server hosting the Sentry stack:
I only managed to get a symbolicated stack with source context after manually uploading the files with the Sentry CLI:
Is there anything obvious I missed regarding the debuginfod support by Sentry ? I followed this documentation: Symbol Servers (debuginfod) I found later that Symbolicator does not support fetching sources from debuginfod: symbolicator: symbol-server-compatibility Related issue for Symbolicator: https://github.com/getsentry/symbolicator/issues/445
Thank you.
Event ID
No response