I am having trouble executing below tmuxinator config. When I run the configuration first letter of second command in panes section is removed. This is happening when I have to execute commands over a ssh session. Same behaviour is observed in executing commands in local but without any errors(first letter of second command is seen missing but gets executed in local).
Here is my sample config file
# /Users/ash/.config/tmuxinator/bst.yml
name: bassh
root: ~/
windows:
- apps:
layout: tiled
panes:
- app1:
- ssh bst
- ssh ash#198.174.145.1
Out put in tmux on running tmuxinator session for bst
~
➜ cd /Users/ash
sh bst
ssh ash#198.174.145.1
~
➜ ssh bst
sh ash#198.174.145.1
[ash#gzp-t2-v-server ~]$ sh ash#198.174.145.1
sh: ash#198.174.145.1: No such file or directory
[ash#gzp-t2-v-server ~]$
below are the versions I am using
➜ tmux -V
tmux 3.1b
➜ tmuxinator version
tmuxinator 2.0.1
➜ zsh --version
zsh 5.7.1
Related
Goals: I am trying to create a startup script on google which run tmux and also running python3 script on the tmux after start/reset the VM (virtual machine). My python script was a telegram bot script which response to the chat.
My current condition: I just know that startup script was run as a root so I run it using sudo -H -u USERNAME tmux new-session -d -s SESSION-NAME. It runs perfectly on startup script and the session was there when I make SSH connection to the machine. I am using debian 10 as OS and already install both python3 and tmux.
Problem: I want to run python3 code in the tmux session, so I add "python3 XXXX.py" at the back of the startup script. but it doesn't work as it should be. when I make SSH connection the session was not there. when I check the startup script - it was said that it was run perfectly but I cannot find my session and the script also did not run.
My current code:
#! bin/bash
sudo -H -u USERNAME tmux new-session -d -s SESSION-NAME "python3 SCRIPT.py"
I'm running this command from my local machine:
ssh -tt -i "pem.pem" ec2-user#ec2-IPADDRESS.compute-1.amazonaws.com "sudo su -c 'cd /dir/;npm install pm2'"
It connects, operates as a super users, cds to dir and attempts to run the command but returns that npm is not a command recognized by the system.
However, when I connect "manually" i.e.
ssh -i "pem.pem" ec2-user#ec2-IPADDRESS.compute-1.amazonaws.com
sudo su
cd /dir
npm install pm2
it works.
npm is installed under root and the system can see it.
ssh -tt -i "pem.pem" ec2-user#ec2-IPADDRESS.compute-1.amazonaws.com "sudo su -c 'cd /dir/;whoami'"
and
ssh -i "pem.pem" ec2-user#ec2-IPADDRESS.compute-1.amazonaws.com
sudo su
cd /dir
whoami
both return "root"
Why can't the npm command be found when running on top of an ssh?
When you login, you create an interactive shell, which typically will read a couple of files, including /etc/profile, $HOME/.profile, and $HOME/.bashrc in the case of bash.
Any of these files can add extra elements (paths) to the PATH variable, which affects which commands can be found.
When you run the command line directly, no such initialisation takes place, and the value of $PATH may be limited to just /bin:/usr/bin.
Next there is sudo, which may or may not import the value of PATH when looking for commands.
Solution
Best you can do is find out where npm is installed, and use its full PATH.
I'm wrote a workflow to install some tool dependencies on a Linux self-hosted GitHub runner VM. I'm using homebrew to do the tool installs. Using homebrew requires that it not be run on the root user which is what the GitHub Runner logs in as. I'm wondering why when I create a step that switches the user from root to my test user things break but when I sudo to that user in every step things work fine, I think I explained this poorly so see below:
Failing Workflow (you can see the first step switches the user to testUser):
installHomebrew:
name: Install Homebrew
runs-on: [self-hosted]
steps:
- name: Switch to etpAdmin user
run: sudo -u testUser -i
- name: Install Homebrew silently
run: sudo apt install linuxbrew-wrapper -y
- name: Run brew for the first time to create the .linuxbrew directory
run: brew -h
This will fail on the last step claiming homebrew shouldn't be run on root while the following workflow works just fine.
installHomebrew:
name: Install Homebrew
runs-on: [self-hosted]
steps:
- name: Install Homebrew silently
run: sudo apt install linuxbrew-wrapper -y
- name: Run brew for the first time to create the .linuxbrew directory
run: sudo -u testUser -i brew -h
My Linux is a little rusty but I was under the impression using sudo -u (username) -i will log the terminal into the specified user until logout/switching user again, am I wrong or is there a better way to accomplish this?
Disclaimer; I'm not familiar with the platform you are running on or the tool you are using, but I do have an educated guess.. and I hope this also how the -i flag behaves.
As most provisioners work, they usually run each step (mostly) independently from other steps. Which (again, usually) means that environment from one step is not carried over to the next one. So in this case, running sudo -i in one step will not have any effect on subsequent steps. You can try this to see how the provisioner in your case operates:
testUserChange:
name: Test active user
runs-on: [self-hosted]
steps:
- name: Default user
run: whoami
- name: Sudo user
run: sudo -u testUser -i whoami
- name: Should be default user again
run: whoami
- name: Maybe interactive shell like in first attempt
run: sudo -u testUser -i
- name: Who am I now
run: whoami
Now as for the -i, the manual states:
This means that login-specific resource files such as .profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed.
While this may be a bit confusing, as most provisioners don't expect user interactive input at runtime, they would usually close the STDIN handle (the input to the process). If we have two users, user0ne and usertw0, I hope I can demonstrate the behavior;
$ export PS1="This is user0ne env \$ " # just to show when environment variables are re-set due to loading the login scripts
This is user0ne env $
This is user0ne env $ whoami
user0ne
This is user0ne env $ sudo -u usertw0 /bin/sh
This is user0ne env $ whoami
usertw0
This is user0ne env $ exit
This is user0ne env $ whoami
user0ne
This is user0ne env $
In the above example, you can see that while the effective user is tw0, the environment is still set to what 0ne has set. Let's try with -i:
This is user0ne env $ sudo -u usertw0 -i /bin/sh
$ whoami
usertw0
$ exit
This is user0ne env $
So by now, looks like -i sets the environment (and login) to tw0's. Now, while the documentation does state that without any argument an interactive shell is opened:
This is user0ne env $ sudo -u usertw0 -i
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
usertw0#ubuntu:~$ logout
This is user0ne env $
Let's see what happens if we close the input handler (or more accurately, input nothing):
This is user0ne env $ sudo -u usertw0 -i < /dev/null
This is user0ne env $ whoami
user0ne
This is user0ne env $
And the same will happen even if you provide /bin/sh as the command to run, like shown in a snippet above:
This is user0ne env $ sudo -u usertw0 -i /bin/sh < /dev/null
This is user0ne env $ whoami
user0ne
This is user0ne env $
So even though the documentation does state it will open an interactive shell, the shell closes once there is no input to be read, and the state returns to the previous user.
Cheers! :)
I'm trying to run the node command in my git bash terminal. When I run the node command, nothing happens when I press enter. The $ goes away and it just leaves a blinking cursor on the next line without the >.
My-PC MINGW32 /
$ node -v
v4.5.0
My-PC MINGW32 /
$ where node
C:\Program Files\nodejs\node.exe
My-PC MINGW32 /
$ node
_
Could someone tell me what the issue could be?
Thanks!!
If you're not getting a new line with a > after entering "node" - this is probably because newer versions of Git Bash don't run in the TTY mode they used to. Discussion here. You can verify by entering:
node -p -e "Boolean(process.stdout.isTTY)"
If that returns false - then the Node REPL (and some other console tools) won't work correctly.
There are a couple workarounds:
Workaround A
winpty node
Or you can add an alias in your .bash_profile:
alias node="winpty node"
# and for npm CLI/scripts:
alias npm="winpty npm.cmd"
Workaround B
Create a new shortcut to Git Bash with the following Target:
"C:\Program Files\Git\git-cmd.exe" --no-cd --command=usr/bin/bash.exe -l -i
and use that instead of the default Git Bash.
Logging via terminal I can switch to root user fine:
ubuntu#ip-10-0-0-70:~$ sudo -s
root#ip-10-0-0-70:~# whoami
root
So I created in rundeck a job script with this:
whoami;
echo "1st step";
sudo -s;
echo "2nd step";
And when I run this, it prints:
ubuntu
1st step
After print '1st step' it get stucked forever. Seems a problem with sudo -s command.
tried sudo -i but the same happens
tried sudo su - root but the same happens
rundeck is logging as ubuntu user, me too
any idea to switch to root in rundeck script?
This is the expected behaviour.
You are running a shell via 'sudo -s' and then not leaving/exiting it ! So it waits forever for somethig that won't come.
You can probably add 'sudo' as an Advanced option of your script (where it says "Run script with an interpreter or prefix. E.g.: sudo, time:").
But it will run your whole script as root.
If you just want a specific command to be run as root , just prefix your command with sudo as so:
sudo "enter_your_command_to_be_run_as_root_here"
Entering the command prefixed by Sudo will generate the following error on most linux distributions.
sudo: sorry, you must have a tty to run sudo
You can enable sudo without tty by running 'visudo' and commenting out the defaults line or removing 'requiretty' from the defaults line.
Details can be found here:
http://www.cyberciti.biz/faq/linux-unix-bsd-sudo-sorry-you-must-haveattytorun/