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

Running git clone <http url> in a session fails #216

Closed
olevski opened this issue Jan 25, 2022 · 4 comments
Closed

Running git clone <http url> in a session fails #216

olevski opened this issue Jan 25, 2022 · 4 comments

Comments

@olevski
Copy link
Member

olevski commented Jan 25, 2022

This is very similar (if not identical) to #196.

The message when trying to clone a repo with https is like this:

fatal: unable to access 'URL': server certificate verification failed. CAfile: none CRLfile: none

This can be addressed in a few ways:

  1. Updating the base jupyterlab image that all our images are based on (this requires a change in this repo). This is the same fix that was done when we saw this issue last year.
  2. Adding a line in the every sessions dockerfile to update the ca-certificates package when the image for the session is built (this would require a change in the project template)
  3. Controlling all of this by way of the certificates library chart which will replace the /etc/certs folder in any image. The problem with this is that we have little control of user images. And I wonder if doing this into a users image could lead to weird consequences. But still all our images are debian based so this should still work. Currently we do not inject the certificates in the user session container because it is not required - but we could do it in order to address this problem.

I am leaning towards option no. 2 or 3. What do you think?

@olevski
Copy link
Member Author

olevski commented Jan 25, 2022

It seems that this is just a result of the fix for #196 not being fully rolled out and deployed.

@rokroskar
Copy link
Member

has this been resolved @olevski ?

@olevski
Copy link
Member Author

olevski commented May 3, 2022

I can confirm that this is not a problem on renkulab.io. Will check that this is the case on limited and close the issue.

@olevski
Copy link
Member Author

olevski commented May 3, 2022

Using the latest image on limited does not have issues. If this issue crops up anywhere then updating to the latest base image for the renku session will resolve things.

For example this will occur on limited with renku/renkulab-py:3.9-0.10.1 but not with renku/renkulab-py:3.9-0.11.1

@olevski olevski closed this as completed May 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants