I thought I’d read that OOD was now able to run RStudio without relying on Singularity but can’t find documentation to support that notion. Was I dreaming??
Thanks - Susan Litzinger
PSC
You may have seen something by Morgan to use unshare though I don’t believe we got it working (you need to be ‘root’ with subuids so there’s added complexity).
I’m only now realizing that rstuido is open source so maybe they just fixed the bug? I haven’t checked, but it seems possible that they did.
The bug was this: rstudio server creates a temporary file that’s hard coded. Meaning, you cannot have 2 instances of it (2 users) running on the same machine. Unless you chroot the tmp directory, which we do through singularity.
That’s the the only reason we’re using singularity, so if that simple single thing got fixed, or we could unshare a different mount, or figure out if R_SESSION_TMPDIR is useful (I just happened upon this looking at some of the tickets) or whatever we would switch because it does seem to add to folks’ confusion.
Hope that helps!
We’re not using singularity to run rstudio. I modified the rserver source to support a “–server-secure-key-dir” option to over-ride the hardcoded “/tmp/rstudio-server”. I’m happy to share my patch but I’m not sure how to include a file here.
–Mike Dugan
Yes! Maybe we can provide the patch upstream.
I’ve found this ticket of theirs that I’m going to start commenting on saying we need this.
Yea it seems that Rstudio 1.3 that’s in beta right now resolves this issue. Though I’m trying to get it to run, in preparation for their release, and am having a bit of trouble. I don’t know what QT_QPA_PLATFORM we should use.
Got keys from plugin meta data ("xcb")
QFactoryLoader::QFactoryLoader() checking directory path "/users/PZS0714/johrstrom/temp/rstudio/rstudio-1.3.895/bin/platforms" ...
loaded library "/users/PZS0714/johrstrom/temp/rstudio/rstudio-1.3.895/plugins/platforms/libqxcb.so"
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Mike, I would be also curious to see the fix.
I am also wondering how did you install the RStudio Server. We install all our apps here as non-root and I haven’t been able to find any info it it’s possible to install the RStudio Server this way. We were dabbling with installing it into the OS image but that’s something our admins don’t like for non RedHat official RPMs, and they were also concerned about security implications of running the server.
That’s the other reason why we are running it in the container.
MC
I’m a novice with discourse and can’t figure out how to attach a file here without mangling it.
So here’s my patch:
https://scv.bu.edu/server-secure-key-dir-option.patch
We also install apps as non-root into a shared filesystem so they are available to every compute node.
So I configured the rstudio build to install into /usr/local/ood/rstudio-server. The files are owned my me
but the server is started from the batch script and runs as the user.
–Mike
1 Like
Thanks @dugan for the patch!
Yes in RStuido 1.3 (currently in beta/preview) you won’t need a container. We’ll try to update the community when it becomes stable and we have a working example of how it works (we’ll likely want to run it at OSC too).
We’ve been testing RStudio Server 1.3.959. The issue #4666 referenced above addresses PID files. New version includes a new flag --server-data-dir that changes the location of rstudio-rsession. It does not address rstudio-server which contains the secure-cookie-key file. I think we still need something like @dugan’s patch to avoid dependency on Singularity or PRoot.
It fact 1.3.959 solves all problems. It also has a “–secure-cookie-key-file” option.
You can use that to put the cookie file anywhere you like. I’m using the unmodified rpm
binaries but I didn’t install the rpm. I just dumped the files with rpm2cpio and moved them
to a shared filesystem accessible to all my compute nodes.
–Mike
Thanks for that suggestion. I guess I expected there should be one flag to control temp file location rather than two. We also use the rpm2cpio method of installation. I put together our config and some notes from our recent experience with 1.3.959.
Hopefully it’s useful to someone.
1 Like
@dugan and @maflister – Thank you both for the tips. I was also looking for a way to run RStudio Server without Singularity, so I was happy to see the --server-data-dir and --secure-cookie-key-file options included in v1.3.
Special thanks to @maflister for the GitHub repo. It looks like this will do exactly what we need. I will be cloning and testing this today.
I was thinking of doing this too, but the pre/post scripts looked intimidating. Was it that easy? I did see that the files are all installed into /usr/lib/rstudio-server on both rpm and deb machines. So then it’s just the pre/post scripts which I presume create + populate /etc/rstudio/, create /var/run/xxx and install a systemd script?
I guess if running it out of a Module, you don’t need the systemd script - what do you do about the other two functions?
Yes, it was that easy. The rpm scripts do things that are needed to run rstudio-server
as a daemon but we don’t want that with ondemand. The config files installed in /etc/rstudio are empty. All the rserver config parameters that we need can be specified
on the commandline. If you needed an rsession config file, rserver has a “–rsession-config-file” option.
1 Like
Me. It was useful to me. Thank you.