Skip to content
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

Exit code 60 just after starting #90

Open
gaeljw opened this issue Nov 25, 2024 · 2 comments
Open

Exit code 60 just after starting #90

gaeljw opened this issue Nov 25, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@gaeljw
Copy link

gaeljw commented Nov 25, 2024

Hello folks,

When starting Sourcebot (container, v2.5.0), the container immediately exits with status code 60. With no error message.

After troubleshooting, I found out that it's due to the curl calls done in the entrypoint.sh script for telemetry. Exit code 60 is the way cURL says there's something wrong with the SSL certificate.

In my case, it's due to internal network policies that happen to manipulate the SSL certificate the container sees for the Posthog URLs.

While the actual root cause is out of Sourcebot scope, it might be interesting to add slightly more logs or "catch" the cURL errors to give a hint to users that this might be the reason of the container not starting.

Anyway, I though to log this as an issue to help other people that may encounter the same issue.

@brendan-kellam brendan-kellam added the enhancement New feature or request label Nov 25, 2024
@brendan-kellam
Copy link
Contributor

Hey thanks for raising! Yea we should add some error handling for those curl calls.

I'm also curious to know how we could get these calls to succeed in a network environment similar to yours. Is there a minimal setup that could be configured to replicate this issue? Is the network policy only messing with the SSL certs for traffic to PostHog, and not traffic to GitHub/GitLab?

@gaeljw
Copy link
Author

gaeljw commented Nov 25, 2024

I'm also curious to know how we could get these calls to succeed in a network environment similar to yours.

To be fair, I think what we do is not really best practice.

However, to workaround it, we usually expect to be able to configure the SSL authorities trusted by the container and/or app. We usually find a way to "inject" our private CA certificate somehow.

In this case, I guess we'd need it for the cURL commands to Posthog but also theoretically for calls made by the app to GitHub/GitLab.

Is the network policy only messing with the SSL certs for traffic to PostHog, and not traffic to GitHub/GitLab?

I didn't have issues when testing a GitHub repo. Either we're not messing with GitHub certificates, or the app (Sourcebot) ignores such SSL errors?

To be noted, that we also use a self hosted GitLab with a SSL cert generated by our private CA. Theoretically (I didn't test yet against this GitLab instance), we will face similar errors when Sourcebot tries to access our GitLab. Unless, again, the app ignores such errors.

Is there a minimal setup that could be configured to replicate this issue?

I don't know enough these stuff to be able to give you a reproduction case. If I were to try to reproduce it, I'll try to setup some kind of proxy that presents a certificate generated by a private CA not trusted by default in Ubuntu (or whatever base image you're using for Sourcebot).

Actually.. instead of a proxy, you may reproduce it by starting a dummy server presenting a non-trusted SSL cert and adding temporarily a cURL to this server in the entry point script.


I hope this helps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants