You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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)
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?
The text was updated successfully, but these errors were encountered:
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
This is very similar (if not identical) to #196.
The message when trying to clone a repo with https is like this:
This can be addressed in a few ways:
/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?
The text was updated successfully, but these errors were encountered: