So I have this really nasty problem.
I once set up a tomcat Server on my raspberry pi. The version of it was 8.0.24. I've created a bash script which sets the variable $CATALINA_HOME=/home/pi/apache-tomcat-8.0.24 on each start.
Meanwhile the directory is /home/pi/tomcat - i removed the useless information.
I've changed the export in /etc/init.d/tomcat also, but it didnt help.
After every restart, CATALINA_HOME is set back to /home/pi/apache-tomcat-8.0.24 again.
Is there a way to see, which script sets the environmental variable?
Somewhere I told linux to change the path at startup to /home/pi/apache.. , but i cant find where.
You can add a line in a few of the startup scripts to print the value of $CATALINA_HOME. Try adding:
echo "In $0, \$CATALINA_HOME is $CATALINA_HOME"
to your .bashrc before and after the call to /etc/bashrc
There's also a script called setenv.bash inside Tomcat that sets these types of variables. Take a look in there too.
Related
I am using manjaro and bash shell. I am trying to hide passwords and secret keys in environment variables so that I can use them in my python script.
I tried this in my .bashrc file
export BOT_EMAIL="mymail#automail.com"
export BOT_PASS="pass_"
And if i run this script from terminal it runs
import os
a = os.environ.get("BOT_EMAIL")
b = os.environ.get("BOT_PASS")
print(a, b)
and gives me this output as expected
mymail#automail.com pass_
But the problem arrives when i try to run the script from sublime text 3 it gives me this
None None
which i think is sublime problem so I restarted sublime about ten times and even restarted my computer but it keeps giving None.
I am noob in programming and linux it would be very helpful if someone can solve this problem.
Sublime inherits its environment variables from the environment it's started in. So, if you start it from bash, it will be able to read all the variables you had set when it started. If you start it from the sublime_text.desktop file (an icon in a menu or on the side bar), it'll only be able to read the env variables that were set when the Launcher process started up -- i.e., at login. So, if you don't want to always start from the command line, put your environment variables in your ~/.profile file, then log out and back in. Putting them in ~/.bashrc won't work, as that's only read for interactive sessions.
Alternatively, you can define env vars in your build system. A sample one might look something like this:
{
"shell_cmd": "python3 -u \"$file\"",
"file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)",
"selector": "source.python",
"env": {"PYTHONIOENCODING": "utf-8",
"MYVAR1": "value1",
"MYVAR2": "value2"
}
}
This has the advantage of being able to change variables and values without having to log out and back in.
I think MattDMo touched on this (but just to elaborate on why thats important - as I recently resolved this same issue)
Your IDE is inheriting the env var from the program-startup. To have your new env var take effect: shut down and restart your IDE.
You are setting the environmental variable for your local user. Sublime most possibly should be running as a different user. You can figure this out from top or ps command.
If you want global variables set, explore /etc/profile or /etc/environment.
I am trying to create some new env variables in the rhel machine using chef.
The block executes successfully but on trying to echo the value, i am getting black result.
Script-1:
execute 'JAVA_HOME' do
command 'export JAVA_HOME='+node['java']['home']
end
Script-2:
bash 'env_test' do
code <<-EOF
echo $chef
EOF
environment ({ 'chef' => 'chef' })
end
Also gave this a shot as it was mentioned in the documentation:
ENV['LIBRARY_PATH'] = node['my']['lib']
Please let me know where am i going wrong here..
So the thing you need to know about environment variables is they only work in one direction (parent process to children) so an export in a subcommand does nothing after that execute resource finishes. The second and third examples both work though, with the second setting it for just that bash resource and the third for both the Chef process and everything it spawns. Remember that you need to run with with -l debug to see the output from subcommands Chef runs.
Above explanation is pretty helpful. Updating the /etc/environments file using chef to make sure that env variables are present from the next session. Also using the 3rd approach to make the env variables available for the current session.
I have Debian OS, and I want to start shell script after lightdm is being logged in, how can I do that?
I tried to put
session-setup-script=/path/to/my/script in /etc/lightdm/lightdm.conf
file, but It won't work.
Any advice?
Try invoking your script in an ~/.xsession file.
This file is executed upon X server startup. More info here: https://unix.stackexchange.com/questions/47359/what-is-xsession-for
I was having the same issue and realised that I had set the option at the wrong point in /etc/lightdm/lightdm.conf, a silly mistake.
The seat defaults are documented before the [SeatDefaults] heading and I was placing my setting on the line below the documentation.
so
# session-setup-script = Script to run when starting a user session (runs as root)
session-setup-script=/usr/bin/bla
Looking further down the file I found the heading [SeatDefaults] and below that the setting.
#session-setup-script=
Un-commenting that line and setting the script worked as expected.
I am new to openshift and I've tried hard to modify my env upon git push so that I don't need to rhc env set ENV_VAR=value -a appname everytime I push. According to the documentation, I can do export in one of the action hooks, but whenever I did so, the environment variable will not register..
What is the best way to register those variables automatically, rather than needing to execute rhc command or ssh into the machine and export?
The documentation seems to be outdated as the method of exporting in action_hooks doesn't work anymore
https://developers.openshift.com/en/managing-environment-variables.html
I see that you have your answer already, but in case others come here for the same question, I'd like to mention that the rhc env set command actually sets a variable persistently, so it "survives" the code push, build and gear restart.
The documentation linked in the question says that the export can be used to view environment variables during build; it does not recommend setting environment variables using hooks.
The variables' listing itself, using the build hook, should work just fine. (worked for me at the time of writing this)
In case the export in the build action hook seems not to work (does not list the variables), it is typically caused by the hook file not being set executable (or by a syntax error within the file).
Yes, the action hook way is already broken, even though you export through the hook, you can see that there is no declare -x statements thrown out like stated in the documentation anymore.
One other method you can do is to use the action hook to write to files in this directory:
$HOME/.env/user_vars
for example, if you want to set RAILS_ENV=development, write a script that churns out this file:
$HOME/.env/user_vars/RAILS_ENV
with this content:
development
Spent an awful lots of time to find alternative ways too, but this guy nailed it out, copied it in case the link becomes broken in the future:
If you need to set some environment variables in your GEAR you can use an action hook.
The pre-start action hook will serve you well but if you need to restore those variables after a gear restart, pre-start action hook won’t work.
Post-restart action hook, on the other hand, will execute its actions but I haven’t managed to get the environment variables working. After its execution all environment variables that should have a value were empty.
What I did was to modify pre-start action hook to create environment variables as files under $HOME/.env/user_vars
# Actual script
export OPENSHIFT_POSTGRESQL_DB_HOST="xxx.xxx.xxx.xxx"
export OPENSHIFT_POSTGRESQL_DB_PORT="***"
export OPENSHIFT_POSTGRESQL_DB_NAME="***"
export OPENSHIFT_POSTGRESQL_DB_USERNAME="***""
# Added script for post restart variables
echo "xxx.xxx.xxx.xxx" > OPENSHIFT_POSTGRESQL_DB_HOST
echo "***" > OPENSHIFT_POSTGRESQL_DB_PORT
echo "***" > OPENSHIFT_POSTGRESQL_DB_USERNAME
echo "***" > OPENSHIFT_POSTGRESQL_DB_PASSWORD
After this, if you execute gear restart, the environment variables will exist and will be accesible from your application.
Reference:
https://guilleml.wordpress.com/2015/02/17/setting-environment-variables-in-openshift/
I have a node process that uses an environment variable in the form SECRET_KEY=1234.5678.910112.
This works fine if set using export in my bash_profile and the process is run directly in the shell.
But when running it using supervisor the script only picks up the part before the first period. This is the case either when reading env vars set in bash_profile or set using environment= in the conf file.
Turns out all I needed to do was to add single quotes around my variable. I did do this before but didn't run supervisorctl reread to get the new config.