# Openssl mismatch between RStudio and conda environments

**URL:** <https://discourse.jupyter.org/t/openssl-mismatch-between-rstudio-and-conda-environments/14123>\
**Category:** JupyterHub\
**Tags:** how-to, help-wanted\
**Created:** [May 5, 2022, 1:50pm UTC](https://discourse.jupyter.org/t/openssl-mismatch-between-rstudio-and-conda-environments/14123 "2022-05-05T13:50:44Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![damianavila](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/damianavila/32/46_2.png) [@damianavila](https://discourse.jupyter.org/u/damianavila)\
**Post date:** [May 5, 2022, 1:50pm UTC](https://discourse.jupyter.org/t/openssl-mismatch-between-rstudio-and-conda-environments/14123/1 "2022-05-05T13:50:44Z")

</div>

This is a short communication about issues we have found trying to deploy Keras + Tensorflow in a custom Python + R environment/image. Hopefully, it helps others in the community!

## `tl;dr`

RStudio uses the “system” version of OpenSSL. Conda also installs OpenSSL. If you use RStudio to run a `conda`-installed package that calls OpenSSL, there is a good chance that it won’t work due to an OpenSSL “mismatch”. This is because RStudio forces the use of a system version of OpenSSL, while `conda` expects its own version of OpenSSL. To fix it, either call the function that requires OpenSSL from a Jupyter interface, or separate your `conda` and `RStudio` environments entirely.

## Introduction

Recently, [2i2c](https://2i2c.org) received a request to install **Tensorflow** and **Keras** in an image containing **conda** environments along wit several **R** packages, including **RStudio** : [GitHub - 2i2c-org/utoronto-image: User image for the UToronto Hub](https://github.com/2i2c-org/utoronto-image).

We were able to install the [python TensorFlow package](https://github.com/2i2c-org/utoronto-image/blob/d422076c3695e44f09a959b14cb10f89b6e5f538/environment.yml#L58) and the [R counterparts](https://github.com/2i2c-org/utoronto-image/blob/d422076c3695e44f09a959b14cb10f89b6e5f538/install.R#L105-L106) as instructed by the corresponding documentation.

We also needed to set up the `RETICULATE_PYTHON` environment variable so the **R** packages could properly find the python ones: [utoronto-image/Rprofile.site at d422076c3695e44f09a959b14cb10f89b6e5f538 · 2i2c-org/utoronto-image · GitHub](https://github.com/2i2c-org/utoronto-image/blob/d422076c3695e44f09a959b14cb10f89b6e5f538/Rprofile.site#L11)

## Problem

Our users began reporting issues when trying to download example datasets from within RStudio. For example:

```auto
Error in py_call_impl(callable, dots$args, dots$keywords) : 
  Exception: URL fetch failure on https://storage.googleapis.com/tensorflow/tf-keras-datasets/mnist.npz: None -- unknown url type: https

```

which suggested some underlying OpenSSL-related issues.

## Investigation

Upon several rounds of debugging sessions, we have found that **RStudio** seems to load the “system” OpenSSL libraries when it is opened. Our hypothesis for what is happening:

- when **RStudio** starts the session, it loads the OpenSSL “system” components
- when you try to load a dataset, the **TensorFlow** + **Keras** libraries (and underlying packages) try to use this OpenSSL “system” version
- but the conda (python) libraries are (somehow) expecting the `conda`-installed OpenSSL version
- This then fails!

To test if this specific mismatch was causing the problem, we tried a symbolic link hack:

```auto
mv /opt/conda/lib/libssl.so.1.1 /opt/conda/lib/libssl.so.1.1.backup
ln -s /usr/lib/x86_64-linux-gnu/libssl.so.1.1 /opt/conda/lib/libssl.so.1.1

```

and then, it worked!

![Screen Shot 2022-03-22 at 12 01 33](https://user-images.githubusercontent.com/1640669/159516899-44388340-4138-47f6-aa97-5c2b7ead4798.png)

This confirmed our suspicion but is likely not a long-term solution because it is probably a very brittle fix that will break in unexpected ways.

## Possible workarounds

After spending a lot of hours on this issue we finally decided to stop trying, look for reasonable workarounds, and post here to disseminate the information we collected.

We have verified the OpenSSL mismatch does **NOT** happen when you use the Jupyter Notebook application with the **R** -kernel. So the problem seems to be an **RStudio** -specific issue when you have multiple co-existing environments (most likely caused by RStudio somehow loading the “system” OpenSSL libraries instead of the **conda** one). Hence, an immediate workaround is to use a Jupyter interface to download the dataset and then return to RStudio for the rest of your task.

Another alternative would be to create a different image without a **conda** environment to run your RStudio workflows, so that any python package (including TF or Keras) actually uses the “system” OpenSSL library instead of a conflicting one.

There might be other options involving fixes/enhancements at the **RStudio** level, but this is outside of our expertise to fix. If others have experience with RStudio and an idea for how to resolve this, please share your ideas!

Hopefully, all this information is useful for future readers!

## Appendix

### Things we have tried (and it did not work!)

First, we thought about syncing the OpenSSL versions in both environments (“system” and **conda** ): [Try downgrading the openssl version on the conda environment by damianavila · Pull Request #28 · 2i2c-org/utoronto-image · GitHub](https://github.com/2i2c-org/utoronto-image/pull/28). But that approach did NOT work!

Then we tried pointing the `LD_LIBRARY_PATH` environment variable to **conda** -specific OpenSSL-related paths (to “force” **RStudio** to load the expected OpenSSL libraries) but that approach also failed: [A different approach trying to make RStudio lo load the proper libssl stuff by damianavila · Pull Request #29 · 2i2c-org/utoronto-image · GitHub](https://github.com/2i2c-org/utoronto-image/pull/29) and triggered other potential issues!

### Checking OpenSSL versions

To check the OpenSSL “system” version being used, you used the `ldd` command:

```auto
$ ldd /usr/lib/rstudio-server/bin/rserver | grep ssl libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f0413833000)

```

and the “system” version was `1.1.1f`. We also confirmed the installed version with the `dpkg -l` command:

```auto
$ dpkg -l | grep openssl
ii libcurl4-openssl-dev:amd64 7.68.0-1ubuntu2.7 amd64 development files and documentation for libcurl (OpenSSL flavour)
ii openssl 1.1.1f-1ubuntu2.12 amd64 Secure Sockets Layer toolkit - cryptographic utility

```

To check the OpenSSL conda-associated version, we listed the `openssl` conda package and also directly checked the version:

```auto
$ conda list openssl
# packages in environment at /opt/conda:
#
# Name Version Build Channel
openssl 1.1.1l h7f98852_0 conda-forge
pyopenssl 19.1.0 py_1 conda-forge
$ openssl version
OpenSSL 1.1.1l 24 Aug 2021

```

and the **conda** main environment had version `1.1.1l`.

---

<div class="post-metadata">

**Author:** ![manics](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/manics/32/85_2.png) [@manics](https://discourse.jupyter.org/u/manics)\
**Post date:** [May 5, 2022, 7:07pm UTC](https://discourse.jupyter.org/t/openssl-mismatch-between-rstudio-and-conda-environments/14123/2 "2022-05-05T19:07:24Z")

</div>

Thanks for the investigation, it sounds like it could affect other libraries too e.g.

> <https://github.com/jupyterhub/repo2docker/issues/1153>
>
> \### Bug description
> 
> The R package \`tidyverse\` loads successfully in JupyterLa…b but fails in RStudio.
> 
> We use as an example \[this repository\](https://github.com/plasmabio/template-r/) that contains the description of a R environment with the \`tidyverse\` package installed with conda.
> 
> \#### Expected behaviour
> 
> The R instruction
> 
> \`\`\`r
> library(tidyverse)
> \`\`\`
> should work without any error.
> 
> \#### Actual behaviour
> 
> In JupyterLab, we can load \`tidyverse\` both in a R notebook:
> 
> !\[image\](https://user-images.githubusercontent.com/733861/164316464-d38ae2c9-5add-4c1d-92f2-a68d7b8d205a.png)
> 
> and in a terminal:
> 
> !\[image\](https://user-images.githubusercontent.com/733861/164316671-9d6369b7-2895-4c68-9127-a9a5c4f0acf4.png)
> 
> In RStudio, this fails:
> 
> !\[image\](https://user-images.githubusercontent.com/733861/164316990-f7c71761-ae6b-494b-8871-64b350f6228f.png)
> 
> For debugging purpose, here is the output of the \`sessionInfo()\` instruction:
> \`\`\`r
> R version 4.1.3 (2022-03-10)
> Platform: x86\_64-conda-linux-gnu (64-bit)
> Running under: Ubuntu 18.04.6 LTS
> 
> Matrix products: default
> BLAS/LAPACK: /srv/conda/envs/notebook/lib/libopenblasp-r0.3.20.so
> 
> locale:
> \[1\] LC\_CTYPE=en\_US.UTF-8 LC\_NUMERIC=C              
> \[3\] LC\_TIME=en\_US.UTF-8 LC\_COLLATE=en\_US.UTF-8    
> \[5\] LC\_MONETARY=en\_US.UTF-8 LC\_MESSAGES=en\_US.UTF-8   
> \[7\] LC\_PAPER=en\_US.UTF-8 LC\_NAME=C                 
> \[9\] LC\_ADDRESS=C LC\_TELEPHONE=C            
> \[11\] LC\_MEASUREMENT=en\_US.UTF-8 LC\_IDENTIFICATION=C       
> 
> attached base packages:
> \[1\] stats graphics grDevices utils datasets methods base     
> 
> loaded via a namespace (and not attached):
> \[1\] fansi\_1.0.3 utf8\_1.2.2 digest\_0.6.29 crayon\_1.5.1   
> \[5\] IRdisplay\_1.1 repr\_1.1.4 lifecycle\_1.0.1 jsonlite\_1.8.0 
> \[9\] evaluate\_0.15 pillar\_1.7.0 rlang\_1.0.2 cli\_3.2.0      
> \[13\] uuid\_1.1-0 vctrs\_0.4.1 ellipsis\_0.3.2 IRkernel\_1.2   
> \[17\] tools\_4.1.3 glue\_1.6.2 fastmap\_1.1.0 compiler\_4.1.3 
> \[21\] base64enc\_0.1-3 pbdZMQ\_0.3-7 htmltools\_0.5.2
> \`\`\`
> 
> \### How to reproduce
> 
> Create an environment with \`repo2docker\` and \[this repository\](https://github.com/plasmabio/template-r/).
> 
> Try to run the R command:
> \`\`\`r
> library(tidyverse)
> \`\`\`
> 
> You are sure \`tidyverse\` is loaded correctly when you can run this second command also without error:
> \`\`\`r
> as\_tibble(mtcars)
> \`\`\`
> 
> \### Your personal set up
> 
> - OS: Linux Ubuntu 20.04
> - Docker version: 20.10.14, build a224086
> - repo2docker version: 2022.02.0+19.g1d218af
> 
> 
> \### A possible lead (or not)
> 
> I suspect an issue with the availability of C++ libraries.
> 
> In a terminal, in RStudio, I have:
> \`\`\`bash
> $ strings /usr/lib/x86\_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX\_3.4.26
> $ strings /srv/conda/envs/notebook/lib/libstdc++.so.6 | grep GLIBCXX.3.4.26
> GLIBCXX\_3.4.26
> GLIBCXX\_3.4.26
> \`\`\`
> So, I guess R within RStudio should have access to \`/srv/conda/envs/notebook/lib/libstdc++.so.6\` rather to \`/usr/lib/x86\_64-linux-gnu/libstdc++.so.6\` only.
> 
> What puzzles me is that in RStudio we have:
> 
> \`\`\`r
> \> Sys.getenv("LD\_LIBRARY\_PATH")
> \[1\] "/srv/conda/envs/notebook/lib/R/lib"
> \`\`\`
> 
> but in JupyterLab we have:
> 
> \`\`\`r
> \> Sys.getenv("LD\_LIBRARY\_PATH")
> \[1\] ""
> \`\`\`
> So this lead could be wrong...

---

<div class="post-metadata">

**Author:** ![Bryan\_Paget](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/bryan_paget/32/12293_2.png) [@Bryan\_Paget](https://discourse.jupyter.org/u/Bryan_Paget)\
**Post date:** [February 1, 2024, 5:13pm UTC](https://discourse.jupyter.org/t/openssl-mismatch-between-rstudio-and-conda-environments/14123/3 "2024-02-01T17:13:00Z")

</div>

I was also having this issue but I found:

```auto
echo "rsession-ld-library-path=/opt/conda/lib" >> /etc/rstudio/rserver.conf 

```

resolved things nicely.

Reference:

- [curl not able to load from Rstudio but does load from R running in Rstudio terminal · Issue #14060 · rstudio/rstudio · GitHub](https://github.com/rstudio/rstudio/issues/14060)