I'm currently writing a script to set some PATH in a remote machine using ssh. I have successfully set the variables in the .bashrc. However, it the last step of my script is "source .bashrc". However, when i ssh to the machine manually, the PATH is still not set. What is the problem?
If on computer A, you set PATH with a script run via ssh on computer B, in a script, and then log in to computer B again, PATH will go back to what it was initially. The computer doesn't remember the value of PATH between processes, and it doesn't share it. PATH is an environment variable which is specific to each process. If you use
export PATH
then it will be inherited by child processes, but here your second login session is not a child process of the first one.
Related
I need to set environment variable for my NodeJS application. I'm using OS W10. I tried wrote in CMD
SET PORT=5000
When i wrote SET in CMD i saw value PORT=5000, but if i closed CMD and opend it one again and wrote again SET PORT i got message: Environment variable port not defined.
And if i try to get data from Node.JS application via command process.env.PORT i got value undefined. Do you have anybody experience with this isssue ?
Thanks.
An environment variable set in a Windows 10 command shell persists only for the lifetime of that command shell and is only seen in that command shell (or in child processes).
So, if you want to set an environment variable in the command shell for your node.js app, you have to set it in that very command shell that you're about to run your node.js app from. This can either be done manually or you can create a batch file that sets the environment variable and then runs your node.js program.
If you want to set a persistent environment variable that is automatically available in all future command shells, then you can go into Windows settings and modify the default environment that is passed to all new command shells. Here are some steps to do that:
Open Windows Settings
Type environment in the search box in the settings window.
If you are logged in as an administrator, you should get a drop-down that contains two options, edit system environment variables or edit environment variables for your account. Pick the desired choice.
A dialog comes up where you can then edit, add or delete persistent environment variables.
SET only sets the environment setting for current session, once closed you loose it. In order to get PORT value using process.env.PORT, you need to set PORT first then run your server within same CMD window.
If you are using BASH (Git Bash) you can do it using one line
PORT=5000 node server.js
I highly recommend using DOTENV package to manage your Environment Variables.
I have an IP address that I use very often, so I tried to set it as an environment variable now that I installed Ubuntu. I edited /etc/environment and added a couple of lines for my api token and my IP address. It looks like this:
PATH="some/paths"
TOKEN="my:token"
ZRUS="my.ip.address"
Now if I want to access the IP I would in theory do ssh $ZRUS. However, it does not work; I do echo $ZRUS and I get a blank line, so I do printenv and I get a list of all the environment variables and I don't see my IP there. I then do su root and I do printenv again and I get the same list plus the IP address and the TOKEN. I then do su myuser and do echo $ZRUS and magically the IP works.
Now I'm wondering why I have to log in as root first to get my global environment variables to work in the local user. It seems as if the scope varied depending on whether root has had a go on the session or not, which seems strange to me.
Do you guys think this is a bug or a functionality? And how would you overcome this?
Environment variables set in an environment file /etc/environment will only take effect if you read them into your active shell source /etc/environment or you logout/login (which will re-read the environment files into your active shell).
The act of su myuser is essentially creating a new shell for your current user which re-reads the environment file
I have to remotely connect to a gateway(working on Linux platform), inside which I have couple of executable files (signingModule.sh and taxModule.sh).
Now I want to write one script in my desktop which will connect to that gateway and run signingModule.sh and taxModule.sh in two different terminals.
I have written below code:
ssh root#10.138.77.150 #to connect to gateway
sleep 5
cd /opt/swfiscal/signingModule #path of both modules
./signingModule #executable.
But through this code I am able to connect my gateway but after connecting to gateway nothing is happening.
2nd code:
source configPath # file where i have given path of both the modules
cd $FCM_SCRIPTS # variable in which i have stored the path of modules
ssh root#10.138.77.150 'sh -' < startSigningModule** #to connect and run one module.
as an output of this i am getting:
-source: configPath: file not found
Please help me working this out. Thanks in advance.
Notes:
I can copy paste my files in that gateway if required.
Gnome-Terminal or any other alternatives of this is not working in my gateway
ssh root#10.138.77.150 "cd /opt/swfiscal/signingModule && ./signingModule"
Line source configPath doesn't work because you need specify full path to the file.
You can pass several commands to ssh to run them in sequence; but I prefer a different solution: I have whole scripts locally; and running them remotely means:
Using scp to copy my script to the remote system
Using ssh to then run the script on the remote system
The big advantage here: there is always a potential for getting things wrong (for example: quoting) when directly giving commands to ssh. But when you put everything into a script, you have exact/full control over what is going to happen. You can put things like "set -e" into your script to improve error handling ...
(and of course, you can also automate the two steps listed above!)
I have a daemon process running on a server that needs access to an environment variable that specifies file path information (e.g. MYPATH=/a/b/c). I know how to specify this in my .bashrc file to give me access while I'm on the interactive shell, but unclear how to make sure a value accessible to a daemon process that's running as root.
In short, my question is: How do I set an environment variable that can be accessible by a daemon process running as root?
Write a script - like
#!/bin/sh
export MY_VAR="some value"
exec /path/to/daemon
Put it in /etc/rc.X to use this script.
See the manual page for that (and read what does the numbers mean in /etc/rcX.d?)
I am attempting to execute a command on a remote linux server via an ssh command on a local server like this:
ssh myremoteserver 'type ttisql'
where ttisql is an executable on the path of my remote machine.
The result of running this is:
bash: line 0: type: ttisql: not found
When I simply connect first and do:
ssh myremoteserver
and then enter the command:
[myuser#myremoteserver~]$: type ttisql
I get back the path of the ttisql exe as I would expect.
The odd thing is that when I execute the first command in my beta environment it works as expected and returns the path of the exe. In the beta scenario, machine A is connecting to remote machine B but both machines are onsite and the ssh command connects to the remote machine quickly.
The problem is encountered in our production environment when machine A is local and machine B is offsite and the ssh command takes a second or two to connect.
The only difference I can see is the time it takes the production ssh to connect. The path on the remote system is correct since the command works if entered after the initial connection.
Can anyone help me understand why this simple command would work in one environment and not the other? Could the problem be related to the time it takes to connect via ssh?
Your PATH is setup differently when your shell is interactive (= when you are logged in on the server), and when not interactive (running commands with ssh).
Look into the rc files used by your shell, for example .bashrc, .bash_profile, .profile (depends on your system). If you set PATH at the right place, then ttisql can work when you run it via ssh.
Another solution is to use the absolute path of ttisql, then it will not depend on your PATH setup.
The environment can be different in a non-interactive session (ssh command) from an interactive session (ssh, then command). Try echo $PATH in both cases.
ssh myremoteserver 'echo $PATH'
vs
ssh myremoteserver
[myuser#myremoteserver~]$: echo $PATH
If they differ, look in all startup script for some differentiated behavior based on $PS1 or $-