I’m looking for a way to create an “Interactive App” that starts a long lasting tmux session that the user will be able to connect and disconnect from. Similar to a VNC session, but console based. I was thinking if there was a way to specify a tmux session like you can specify a directory in the /pun/sys/shell/ssh app, this would make it much easier. Has anyone done anything like this?
You could get something really quickly by taking something like the Matlab application and replacing the matlab command with the command to start a terminal…? It would run in a very minimal VNC, but it’s in a browser window, so they don’t need a VNC client installed.
That would also give them access to scrollback buffer and other terminal functions that require special command sequences when in Tmux, and you won’t have people accidentally typing Ctrl-B something and getting to some Tmux function they didn’t intend.
Finally, they would also be able to start a second terminal window, and having two terminals can sometimes be really helpful, e.g., when running a program in one and top in another.
I know this is answering a different question, but I think it addresses the same scenario and overall desire. Sorry if I have gone too far astray.
There’s a similar discussion here. Regardless of how you schedule (through Slurm or the linux host adapter) - a VNC batch connect app will persist for as long as you like.
The last 2 comments in that topic specifically have some example apps.
To clarify a bit here, the reason I chose the Matlab application to start rather than VNC is that the Xfce desktop is empty, no dock, so the terminal window will not be lost in ‘clutter’
By replacing the matlab command with one of the terminal commands to run in full screen, e.g.,
The window manager Application menu is there, but it is very stripped down and contains only Firefox, Terminal emulator, and the File manager, all of which could be handy to have ‘right there’.
I can’t do much these days without looking something or other up on the web, and having a handy copy-and-paste is very useful. Having the reference material from the web next to the Terminal has distinct advantages.
I think many students might find the File manager also useful.
I am pretty sure this is how I would do this here, if we had a call for it.
I was able to do what you are trying to do using a program called ttyd and tmux. Only downside I could find is that the only way to stop the interactive job is to delete the card in OOD (really wish there was a stop/cancel button that left the card in place). I can’t share our code directly since our GitLab is not publicly available but if you are really interested I will see if I can rehost it.
Also, for using ttyd, and many other applications that end up having sensitive info like passwords in the command, it is important to do some system hardening around /proc. Specifically the hidepid mount option to prevent users from seeing processes that don’t belong to them.
Edit:
I also forgot to mention that you need to be very careful with tmux. When spawning tmux inside Slurm jobs you need to make sure tmux uses a unique socket name/path. If you don’t tmux escapes it’s cgroup if the users launches it inside a second job on the same node.
It’s important to note I had to build ttyd from it’s master branch as there is an unreleased fix for reverse proxies (-b flag). This is as of version 1.6.3. Also if you use Spack to build ttyd the default recipe in develop for libwebsockets needs to be asjusted
openssl (I had to backport it to 0.16 from develop. develop introduced a new flag called ‘docs’ which broke a lot of things as the flag does more then just enable/disable documentation. Just a heads up.)
@nvonwolf I just wanted to say thanks for sharing, this is really nice. I gave it quick spin, but I see persistence on an interactive session, yes! It works in our test cluster at Georgia Tech. Obviously, some form customizations aside, to over come some roadblocks I needed to get it going
set TERM to something that’s on our RHEL7 systems, e.g.
export TERM=xterm-color
There were some funky complaints (but warnings) with the default tmux.conf that I have yet to diagnose further
While we have Spack at our site, on RHEL7.6, I skipped using for building ttyd, and went with a manual build. All prerequisite problems were resolved with the installation of libwebsockets-devel and dependencies. I used your advice to build ttyd against the latest git.
As far as the “TERM” env, and set -g default-terminal "screen-256color" in tmux.conf, I’m unfamiliar with the correct/desirable values. I managed to land on something that worked and didn’t question it.
For tmux we provide a newer version of tmux on our cluster via Spack and lmod. The config file I bundled is based on tmux 3.2b. I’m not aware of a simple way make tmux configs backwards compatible which is probably my largest complaint about tmux to be honest.
Edit:
Also, I pushed an update that removed our site specific config from the ‘view.html.erb’ file in favor of a more dynamic method.
I just caved and built the newer tmux, less fighting with the default tmux.conf configuration (which was already pretty nice to begin with). Haven’t tried the ‘more dynamic’ method but I can give that a go soon.
The ‘more dynamic’ is just using some javascript to get the base url since i’m not sure I can add a username/password to a relative path. I put in a fix for the “TERM” variable as some users were getting an error that it was set to “unknown” for some reason. Eventually I intend to put in a drop down so users can select what version of tmux they want (incase they want to use the tmux.conf in their home directory and it needs a specific version).
@nvonwolf Separately, I have done some testing along with a fellow staffer. Have you seen issues with different web browsers for the click button passthrough to connect? On Safari and Firefox, the username and password are prompted (for which one needs to supply username = ttyd and password from connection.yml).
No issues with Chrome (connect just ‘works’). Maybe there’s a more general issue at play not specific to this app.
EDIT: maybe your sentence related to ‘username/password to a relative path’ was related.
Anyhow I can just retry testing with the latest version and follow up here.
Also @nvonwolf , since we don’t do the hidepid technique at our site (yet ), I modified the app so that it would read off the connection.yml and writing a simple auth script using ttyd's --url-arg option. That way the use of plaintext passwords being shown on the CLI can be avoided.
@kevinlee I was unable to get the --url-arg feature working myself and having the password shown in the url was not desirable (would show in screen sharing and such). If you do get it working I would be interested to see what it looks like though.