I am using perl module "Expect" to achieve automation of interactive sessions. The script intends to spawn a ssh terminal on localhost(say).So the problem is can use two spawn commands (for spawning two ssh terminals)from the same script. In that case how the two spawned process share the ssh terminal. I found that both the spawned commands actually share the ssh terminal. So the UI on terminal is actually messy. Is the above assertion true?
Question 1) If true, is there any better way of controlling the spawned process in accessing the ssh terminal.
Scenario:
1) say perl script "demo.pl" has two spawn commands which does spawn a ssh terminal locally.
2) Spawned process are actually sharing the ssh terminal from which perl script is executed.
Question 2)
So is there any way to launch a totally new ssh terminal, instead of using existing one.
Terminal emulators and ssh are distinct programs. You could spawn separate terminals, each containing an ssh command — but interacting with them would not be possible from the script, because the terminal is handling the communication to its contained ssh, not making it available to your script.
Your options here are to use a Perl widget package or to use a terminal emulator in "slave" mode (see the -S option to xterm, for example) — and in either case, you would need to track the input and output for each spawnid separately and direct it to the appropriate widget or emulator.
Related
I am doing some analyses using vscode on a remote server that has got SLURM installed to manage jobs and provide parallel computing. I would like to run each cell in the Jupyter notebook as an interactive job on SLURM the same way my command line code would be run as an interactive SLURM job after I have used srun to request compute nodes. The jobs I need to run on the Jupyter notebook require a lot of memory, so I need to run them using SLURM.
My current work around is to run srun on the terminal and start a python terminal, then I copy and paste the code from each cell of my notebook into the python terminal. I'd really appreciate your help.
It is an old question, but answering as I also came across this problem recentrly.
After you do srun on a terminal, you should be able to ssh directly into your compute node in VScode and use all the capabilities of the compute node in the interactive mode/notebook
The steps I take, for example, are:
in a terminal (e.g. powershell), srun into a node
add that node to your config file, so that you can ssh into it
open vscode and ssh into that node
run code in interactive window/notebook, with access to CPU/GPU of the node
Problem
I am trying to connect to my school's computing cluster (aka a linux server with "login node" and "computing node") using VS Code's Remote SSH, but I cannot figure out how to run a command after SSH-ing.
Goal
I simply want to view Python code and test some small lines in a .ipynb jupyter notebook in the computing platform's environment.
Description
Basically, normally in the command line (or mobaXterm of a Windows machine) of my local machine, I first log onto the computing platform's login node with ssh -Y -L PORT:127.0.0.1:PORT username#computing.cluster.ip, and then run srun -t 0-12:00 --pty -p gpu --gres=gpu:1 --x11 --tunnel PORT:PORT /bin/bash to log onto the computing node interactively (shown command allows for port forwarding). The problem is, in VS Code I can only connect to the login node, but after that there's no way for me to run another command and log onto the computing node. The reason I need to get to computing node is that I want to test something with a .ipynb file interactively on VS Code while reading the code, and the login node does not allow me to perform computation.
Failed trials
I've been trying Code-Server, but it does not support .ipynb well (it keeps asking me to install jupyter notebook even though I have installed it in my conda env), possibly because it by default recognizes HPC cluster's Python interpreter which I cannot modify (I can't even select Jupyter kernel in code-server). I also tried to directly use Jupyter Notebook (open Jupyter with port forwarding after getting onto computing node), but reading code on it is much more inconvenient.
Would greatly appreciate your suggestions!
I have to login to multiple hosts at one time, sometimes the number is around 20. The user and pass are same for all the hosts.
Currently to ssh onto these servers I have to run the ssh command manually in power shell and enter the password.
Is there any way I can just provide the servers list along with user/pass and open multiple PowerShell windows in one go? (help me if that can be achieved using ps script)
Sometimes I have to run the same command on all hosts, for that I am using mobaxterm. But again, in this tool as well I have to ssh to servers one by one.
Is there any single tool which can do both the magics (ssh to multiple hosts in one go and I can run commands parallelly)
I'm trying to get Remote-SSH working with ssh-agent, from Windows 7 desktop to CentOs 7 server.
I'm using ssh, ssh-add and ssh-agent from the Git for windows package. From the cmd prompt, this is all working fine, I can "ssh-add -l" and see the keys, and I can run "ssh " and it runs with no problems and without asking for password:
C:\Users\gnb>"c:\Program Files\Git\usr\bin\ssh-add.exe" -l
4096 SHA256:zg2IR6OlPwCGP8SzcbriXIQjth5zuDc9rbO6uaNPmcU gnb#VDI028-MEL (RSA)
C:\Users\gnb>ssh vdi ls
Desktop
tsclient
wkspace
C:\Users\gnb>
From within VS-Code, I can't get this to work. Running the exact same ssh-add command from within the VS-Code Terminal does not seem to find the agent:
C:\Users\gnb>"c:\Program Files\Git\usr\bin\ssh-add.exe" -l
Could not open a connection to your authentication agent.
The actual remote functionality in VS-Code more or less works, but keeps stopping to ask for passwords.
What's missing here? Why can the vs-code environment not connect to the ssh-agent?
OK, I've had a few more hours playing around with this and I think I understand what's going on.
It only works from cmd if it is the same cmd window that was used to start the agent. Opening a new cmd window then ssh gets the same msg as starting vs-code from the menu - can't find the agent. It appears that the start-ssh-agent script that comes with git/ssh on Win7 is setting some environment variables or some such that the ssh client needs. This does make sense, Unix ssh-agent acts the same way, but I'm clearly not used to thinking about windows apps in those terms.
It also seems the start-ssg-agent script will set the environment variables to point to an existing agent if one is running, else will create a new agent. So a 2 line batch file
start-ssh-agent
code
will reliably start up VS Code with the ssh-agent. If you name the identity file in the ssh config, vs-code will add they key to the agent when required. Otherwise you need to manually add the key to the agent, or fall back to entering the password all the time.
Suspect the better solution is to be on Win10 and use ssh-agent as a service, which should mean VS-code should find the agent when run from a menu. But I can't test that.
It's well known that emacs can be used as a terminal emulator (while itself is running in a terminal emulator), thus making it a valid alternative to more traditional terminal-in-a-terminal approaches, such as tmux or screen. However, there's one thing that could be done easily with the latter and I've found no alternative in emacs' term for this one so far.
Both tmux and screen can detach from a terminal and all tasks ran in their windows continue to run in background. It's done using C-b, d in tmux and C-a, d in screen by default. Later, I can return (reattach) to the terminal I've detached from by running something like tmux attach or screen -r. Also, sessions run in both of these terminal multiplexers are persistent - i.e. if I'm connected to some remote terminal and connection fails, I can reconnect and reattach to the terminal without losing any of my work - it really helps in case of faulty network link that occasionally breaks ssh connections.
Is there something like that available for emacs? Basically, I'd want to be able to:
Detach from emacs and leave it running in background with all the sub-processes ran in term buffers intact.
Reattach to it later and find all my processes running.
Automatic detachment of emacs from terminal on receiving a SIGHUP.
Use emacs daemon:
$ emacs --daemon
Then simply launch a new frame, equivalent for screen -x:
$ emacsclient -t