Exit code 60 just after starting

[gaeljw]

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]

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]

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.

[brendan-kellam]

Nice thanks for the info! I'm going to close this with #159 since it adds some error handling s.t., we don't immediately crash if those curl commands fail. Using #100 to track docs improvements / allowing a easy way to provide a private CA cert.

[brendan-kellam]

Fixed by #159