shinyproxy-rstudio-ide-demo icon indicating copy to clipboard operation
shinyproxy-rstudio-ide-demo copied to clipboard

Building image not working in ShinyProxy

Open danielquintao opened this issue 2 years ago • 2 comments

Hello,

I tried to build the image myself and use it with ShinyProxy, but it does not work. More precisely, I am testing locally with shinyproxy-2.6.1 (as a .jar) and I have the following error message: image

It is worth noting, however, that everything works fine with your image openanalytics/shinyproxy-rstudio-ide-demo:2021.09.2_382__4.1.2 and the same configurations in the application.yml:

  # BUILT FROM SOURCE -- DOES NOT WORK
  - id: rstudio_custom
    display-name: RStudio Custom
    container-image: rstudio:4.1.2
    port: '8787'
    container-env:
      DISABLE_AUTH: true
      WWW_ROOT_PATH: "#{proxy.getRuntimeValue('SHINYPROXY_PUBLIC_PATH')}"
  # PULLED FROM DOCKERHUB -- WORKS
  - id: rstudio_openanalytics
    display-name: RStudio (ShinyProxy official image)
    container-image: openanalytics/shinyproxy-rstudio-ide-demo:2021.09.2_382__4.1.2
    port: '8787'
    container-env:
      DISABLE_AUTH: true
      WWW_ROOT_PATH: "#{proxy.getRuntimeValue('SHINYPROXY_PUBLIC_PATH')}"

The Dockerfile I used was the default one in the main branch, just without the comments:

FROM rocker/rstudio:4.1.2
RUN echo "www-frame-origin=same" >> /etc/rstudio/disable_auth_rserver.conf
RUN echo "www-verify-user-agent=0" >> /etc/rstudio/disable_auth_rserver.conf
ADD 03_setup_root_path.sh /etc/cont-init.d/03_setup_root_path.sh

Can you reproduce the error? Do you have any idea why I can't use the image I am building myself?

By the way, while trying to understand the problem, I compared the image history of openanalytics/shinyproxy-rstudio-ide-demo:2021.09.2_382__4.1.2 with the image history of rocker/rstudio:4.1.2. Other than the three lines we add in the Dockerfile after the FROM ..., there are other differences. In particular, we invoke the files /rocker_scripts/install_R.sh and /rocker_scripts/patch_install_command.sh which do not exist in rocker-versioned2/scripts (where /rocker_scripts/ is a directory in the container that is copied from a local scripts/ directory in the Dockerfile, so I wonder this scripts/ would be the rocker one).

Would these two missing files consist of custom scripts you made and without which we cannot have an image compatible with ShinyProxy?

danielquintao avatar May 12 '23 20:05 danielquintao

Hi

I'm unable to reproduce your problem, I can re-build the image locally and this works fine. The difference in history is just because the rocker project refactored a few things and we didn't rebuild the image since then. I think that the 404 you are getting is caused by the root path setting not working properly.

LEDfan avatar Jun 29 '23 08:06 LEDfan

Hello,

Thank you for your response. Do you mean the env variable WWW_ROOT_PATH? I've just opened a bash shell with docker exec in both containers: the one I built (I used the latest version of your demo repo by this day) which still does not work, and the one that I had pushed from DockerHub and which still works. In both cases, the value of the variable is the same up to the app id:

root@e33c3476fd40:/# echo $WWW_ROOT_PATH
/app_direct_i/rstudio_custom/_/
root@b06f492c4dc1:/# echo $WWW_ROOT_PATH
/app_direct_i/rstudio_openanalytics/_/

However, I am not sure to understand the actual meaning of this environment var. The docs (v2.6.1) say

SHINYPROXY_PUBLIC_PATH: the public path used to access the app. This path conforms to $CONTEXT_PATH/app_direct/$APP_ID. However, by exposing this path as environment variable to every app, it can be used by the app without depending on a specific name for the path. but I wonder where this path should hold. It must not be in the container's file system because ls $WWW_ROOT_PATH gets me nothing in both containers I tested (the custom one that did not work for me, and the official one which worked). Is that expeted?

In summary, my question here would be how is WWW_ROOT_PATH supposed to be used/what does it represent in Shinyproxy's perspective; and, in case root path setting not working properly is behind the cause of the error, whether this is a bug or some misconfiguration in application.yaml.

Thank you for your attention

danielquintao avatar Jul 01 '23 13:07 danielquintao