i was wondering if someone ever made a interactive terminal app? so similar to a desktop, but only a terminal.
i guess using something like ttyd - Share your terminal over the web with some websockify magic is the way to set it up?
thanks,
stijn
We ship a shell app in the main distribution. Does it not show up in the âclustersâ navbar menu for you?
I think what @stdweird is suggesting is interactive batch job without an X server. So for example at OSC on a login node (or through the shell app to a login node) I could execute this:
salloc --nodes=1 --ntasks-per-node=1 --time=1:00:00 srun --pty /bin/bash
The idea would be instead an âappâ would appear that a user could just launch and it would start an interactive session with terminal access.
Two options
- Extend the shell app to execute the command necessary to provide an interactive terminal.
- Use something like xfce terminal as the main app.
First is more performant but may require more site by site configuration (you need to have that option for users using ssh session from a login node).
Second can piggy back off of the existing infrastructure to support GUI desktops in OnDemand, but is less performant since you are running websockify, XFCE etc. on the compute node.
I guess both would have a certain appeal
1 Like
I agree that having an interactive job on a compute node would be beneficial to us at times with a similar terminal emulator âŚ
yes, what i am looking for is what @efranz is describing.
doing some more reading, using something like GitHub - proxmox/vncterm: VNC Terminal Emulator which hopefully could use the current nonvc setup might be easier than using xfce terminal as main app.
feedback is much appreciated
stijn
Would adding a command to open a terminal window by default to the regular VNC desktop application be sufficient?
Is the overhead of the desktop environment that heavy?
Would people find that they really donât want just a terminal after all and want the rest of the desktop eventually, too?
Seems like there comes a point at which adding things to the applications menu make the menu unweildy. Does every application, or possible combination of applications really need a full-blown application of its own?
Just curious.
Clearly OODâs terminal function can satisfy the needs to obtain one or more sessions on the resources supporting the OOD instance. I donât see a need to add a terminal session spawning interface directly on those resources.
The use case proposed here, however, is I think of a different nature. The idea might be illustrated by the use case of someone debugging a piece of code that they want to test on different partitions or queues of a heterogeneous cluster, or on multiple clusters that are reachable from the command line within a terminal session on the OOD resource. (The slurm salloc / interactive example given would be one such method.)
While in principle this is solvable just by having the user select a different resource from the terminal launch options in the OOD web session, that does not match the user experience of having a non-OOD (say, ssh) connection to a login node and spawning an interactive session request within that session. In principle it is no different from launching multiple interactive command requests within a regular ssh session.
Thinking through the above, it doesnât seem to me to require new OOD functionality, but just requires that your cluster and/or OOD configurations support selection of alternate partitions for the session launch, whichever method you choose. Am I missing something in the use case?
1 Like
Terminal Interactive App:
Based on the above, I also can see a middle ground use case for a terminal interactive app. That would address the persistence of a terminal session whenever experiencing network fluctuations/disruptions.
@bennet iâm not sure the overhead worries me, the lighter the better ofcourse.
up until recently, ssh/terminal/interactive batch job was the only thing people needed and/or were using (or were able to use).
and tbh, when debugging stuff, i also just want a terminal.
i guess future will tell how popular it will be with the users; at least with OOD itâs very easy to switch and try.
i like the simplicity of the current ssh terminal, but i just want one app for our users to click on. but indeed, need to be able to change requested resources/reservations/âŚ
perhaps once we figured out how to make it work, the desktop app could simply provide a checkbox to turn it in âterminal-onlyâ mode.
@emily.dragowsky yes, the app would be similar to ssh+screen/tmux+interactive batch; but then via browser+clicks so any user can start one with having to understand any of the above commands (and yes, it might seem odd that one assumes that a user can do valuable work in a terminal if understanding the above 3 commands is too much, but we see it happen. talk to anyone who teaches/gives training using HPC resources, they all say that connecting is the biggest obstacle for a smooth experience with new users).
@stdweird you can modify any of the generic vnc apps to use xfce4-terminal rather than the app command in script.sh.erb. Example here, https://github.com/mcw-rcc/bc_desktop_terminal.
Regarding your comment about checkbox, OOD already adds a link to compute node shell in every app that shows up after launch.
Exactly, I just setup a xfce terminal app today based on vnc app with the following:
#/bin/gnome-terminal --full-screen
/bin/xfce4-terminal --maximize
John
The problem with the built in terminal is that it does not provide persistence and only connects to the login node. Should the tab be closed or the user have any network issue you lose your session. Then there is the fact that if the user wants an interactive terminal session, on a compute node, they have to use srun/salloc and tmux (on login node) for persistence. Having the knowledge to do that is good but goes against OODs idea of making things easy for new users. That is why having a interactive shell app is so desirable.
Personally I think a desktop environment has way too much overhead, so it is best not to use it unless you specifically need it. I donât know if such an app is something OOD needs to develop itself or not. For my institution I went with ttyd+tmux which seems to have worked out well. Infact xtermjs, which is what ttyd uses, seems to have way less visual bugs compared to the hterm terminal used by the Cluster/Shell app.
I posted this in another thread so Iâll include it here.
2 Likes