Help with changing Shell app

[btsherid]

Hi,

I am looking to create a new shell app that connects to a different host than the one configured in my /etc/ood/config/clusters.d/ file.

What I've done:
Copied /var/www/ood/apps/sys to /var/www/ood/apps/sys/ngs-shell
Changed manifest.yml in /var/www/ood/apps/sys/ngs-shell
This gives me another entry under the services menu.

As expected, the URL for the shell app and the URL for the ngs-shell app are the same: https://ondemand.bioinf.unc.edu/pun/sys/ngs-shell/ssh/login.host.edu

What I would like to do is change the ngs-shell app URL to something different like:
https://ondemand.bioinf.unc.edu/pun/sys/ngs-shell/ssh/ngs.host.edu

Essentially I would like the ngs-shell to SSH from the ondemand server to ngs.host.edu instead of login.host.edu.

I can't figure out how to do the above. I tried using the OOD_DEFAULT_SSHHOST and DEFAULT_SSHHOST environment variables with no luck. I tried putting those variables in the following files:
/var/www/ood/apps/sys/ngs-shell/env
/var/www/ood/apps/sys/ngs-shell/.env
/etc/ood/config/apps/ngs-shell/env

I also just noticed that app.js needed to be updated to change this line:
dotenv.config({path: '/etc/ood/config/apps/ngs-shell/env'});

However, that also did not help.

I restarted the PUN every time and I never saw the URL change.

Thanks,
Brendan

[johrstrom]

Essentially I would like the ngs-shell to SSH from the ondemand server to ngs.host.edu instead of login.host.edu.

Do you want to keep both login hosts or just change the one? Changing the one you only need to modify the v2.login.host of the cluster.d file.

Creating a new shell app may have weird side affects. Plus what I'm showing below is way simpler.

If you want both, I just tested this and it works. What you want to do is drop a new file in cluster.d for the login host you want and just remove the v2.job attributes. Removing the v2.job attribute will mean you can't schedule things on it, so batch connect apps and other things won't recognize it as a real cluster. but the shell app will.

We have a cluster called pitzer, and I just copied it to clusters.d/login_pitzer.yml, removed the v2.job and other stuff and changed the title.

---
v2:
  metadata:
    title: "Other Pitzer"
    url: "https://www.osc.edu/supercomputing/computing/pitzer"
    hidden: false
  login:
    host: "pitzer.osc.edu"

OOD_DEFAULT_SSHHOST (in 1.8+, DEFAULT_SSHHOST is 1.7 and below) should still respect this cluster configuration becuase it only checks v2.metadata and v2.login. Also /etc/ood/config/apps/shell/env is the right place for it.

[btsherid]

OK, I see what you're getting at. I did get this working but it creates another issue (I'm pretty close to what I want now).

Under the Services menu I created a Shells submenu. Ideally, what I would like to have is below:

Services
Shells
Interactive Partition Node -> This connects to login.host.edu and then runs srun --pty --cpus-per-task 1 --mem 2gb --partition interactive bash
Login Node -> This connects to login.host.edu (does not run srun)
NS-NGS Node -> This connects to ngs.host.edu

Individually I can get these working.

Interactive Partition Node -> I got this working by copying the existing shell app to an interactive-shell app and updating app.js with the srun command on the args = line. Maybe not the best solution and I'm fine with changing this if need be.
Login Node -> This works because I have lbg_cluster.yml set up in clusters.d
NS-NGS Node -> Successfully tested this after creating ns-ngs.yml in clusters.d

Also, to get the final product I want, naming seems to be an issue. I want the Services menu link to say Login Node (which I accomplished by using the title from manifest.yml) and not LBG Cluster Node (which is what I'll get if I use the cluster.metadata.title). I don't want to change the cluster title because that will change it in other places and make those things confusing/incorrect.

Thanks,
Brendan

[johrstrom]

I think we can accommodate the srun functionality with an ssh wrapper in the original shell app that just toggles the underlying commands given the host parameter.

To the naming issue, I'll have to dig deeper into the dashboard to find out if we can accommodate what you're looking for.

[btsherid]

Thanks for looking into it. I'm not sure how

toggles the underlying commands given the host parameter

will work since the host will be login.host.edu for both. Both the Interactive Partition Node and Login Node menu entries would connect to login.host.edu. Interactive Partition Node would then run srun, and Login Node would not do anything further. NS-NGS Node menu entry would connect to a different host (ngs.host.edu).

-Brendan

[btsherid]

So before, I had two shell apps. One connected to login.host.edu and one connected to login.host.edu and then run srun.

I realized I could have a third shell app that connected to login.host.edu and then run ssh ns-ngs.host.edu. I initially didn't want to do this because I thought it would be a security risk. But I figured out how to secure it today, so I currently have it working the way I want.

Services
Shells
Interactive Partition Node (interactive-shell app) -> Connects to login.host.edu and then runs srun
Login Node (shell app) -> Connects to login.host.edu
NGS Node -> Connects to login.host.edu and then runs ssh ns-ngs.host.edu

I understand based on your previous comment that having multiple shell apps may have weird side effects but I have this working the way I want, so feel free to close the ticket if you want.

Thanks,
Brendan

[johrstrom]

Ya know, I had another thought. That you could fake the hostname in cluster.d file and toggle off of it in the ssh wrapper.

So I'd fill out my interactive-pitzer.yml like this to give it a hostname that doesn't exist.

---
v2:
  metadata:
    title: "Interactive Pitzer"
    url: "https://www.osc.edu/supercomputing/computing/pitzer"
    hidden: false
  login:
    host: "interactive-pitzer.osc.edu"

Since the hostname doesn't exist, I can check for it in the ssh_wrapper and ssh to pitzer.osc.edu and run srun instead when that specific host is given.

In any case, glad to see you got it worked out. I'd still suggest investigating cluster.d and an ssh wrapper files as those are likely to be more forward compatible and overall just way easier to manage, but it's your system so it's your choice! Thanks for the ticket! Let us know if you have anything more.