I have Rundeck 2.10.6-1 installed on a Ubuntu 16.04.4 LTS server and would like to set environmental variables just for rundeck. Rundeck itself is functioning normally.
I am able to set the environmental variables in /etc/environment for system-wide availability, but I'd like them to be accessible only by the rundeck session. One of them is SQLCMDPASSWORD, a plain text password, utilized by SQLCMD, so I'd like tighter access. We ended up using this approach for PSQL as well.
I have the rundeck $HOME directory identified as /var/lib/rundeck and the $USER name confirmed as 'rundeck'.
I find that adding environmental variables to .bashrc, .bash_profile, or .profile in that directory are not utilized by 'rundeck' as confirmed with a commandline job executing only 'printenv'. When logged in to the server as 'rundeck' I see the variables.
Am I setting these in right place?
So, no, those variables were not set in the correct place. Here's why...
There were some clues in the answers to this question and this question but neither was sufficient. Applications have their environmental variables set in their profile, and for rundeck that would be
$ more /etc/rundeck/profile
Second clue is from the head of that file which, loosely quoted, indicates
NOTE: DO NOT MODIFY THIS FILE. It will be replaced when the package is upgraded and your changes will not be saved. To override variables in this file, you can instead create a file at: /etc/default/rundeckd
So, I created that default file and set my environmental variables by adding the following content
export SQLCMDUSER=batman
export SQLCMDPASSWORD='secret_bat_password'
Now it works as intended.
Related
My goal is to put my telegraf config into source control. To do so, I have a repo in my user's home directory with the appropriate config file which has already been tested and proven working.
I have added the path to the new config file in the "default" environment variables file:
/etc/default/telegraf
like this:
TELEGRAF_CONFIG_PATH="/home/ubuntu/some_repo/telegraf.conf"
... as well as other required variables such as passwords.
However, when I attempt to run
telegraf --test
It says No config file specified, and could not find one in $TELEGRAF_CONFIG_PATH etc.
Further, if I force it by
telegraf --test --config /home/ubuntu/some_repo/telegraf.conf
Then the process fails because it is missing the other required variables.
Questions:
What am I doing wrong?
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
What am I doing wrong?
See what user:group owns /etc/default/telegraf. This file is better used when running telegraf as a service via systemd. Additionally, if you run env do you see the TELEGRAF_CONFIG_PATH variable? What about your other variables? If not, then you probably need to source the file first.
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Yes! Take a look at all the options of telegraf with telegraf --help and you will find:
--config-directory <directory> directory containing additional *.conf files
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
That is not the method I would suggest going down. Check out the config directory option above I mentioned.
Ok, after a LOT of trial and error, I figured everything out. For those facing similar issues, here is your shortcut to the answer:
Firstly, remember that when adding variables to the /etc/default/telegraf file, it must effectively be reloaded. So for example using ubuntu systemctl, that requires a restart.
You can verify that the variables have been loaded successfully using this:
$ sudo strings /proc/<pid>/environ
where <pid> is the "Main PID" from the telegraf status output
Secondly, when testing (eg telegraf --test) then (this is the part that is not necessarily intuitive and isn't documented) you will have to ALSO load the same environmental variables into the current user (eg: SET var=value) such that running
$ env
shows the same results as the previous command.
Hint: This is a good method for loading the current env file directly rather than doing it manually.
I am trying to add to the PATH via the Environment Variable settings windows for python.exe.
I have read the instructions using SetX from the March 3, 2012 discussion about this issue and am worried I will make a mess of my machine, so want to stick with the GUI process.
The directory path is C:\Users\Paul\AppData\Local\Programs\Python\Python37\python.exe.
That is a copy from the addition I made in the System Variables section of the Environment Variables window.
I have labelled the Variable Name as "Python", no quotation marks.
I have checked the path, and it looks good to me, and have rebooted the computer. But I still get the
'python.exe' is not recognized as an internal or external command, operable program or batch file.' error in every directory expect if I am specifically in the Python37 directory.
Any idea what I am doing wrong?
The path environment variable contains one or more paths, separated by semicolons. When you try to execute a command in cmd.exe it checks each path listed in the path variable in order of first to last until it finds the executable or runs out of paths to check.
You can experiment without making permanent changes to your system first. Run cmd.exe and type
set path=%path%;C:\Users\Paul\AppData\Local\Programs\Python\Python37
Running python.exe should now work in any directory in this cmd.exe window.
Unlike other environment variables, path is special and is a merged value from the system and user variables. Since you installed python just for yourself you might as well just use a user variable.
In the system properties where you edit environment variables, if there is no path user variable, create one and set it to C:\Users\Paul\AppData\Local\Programs\Python\Python37 or if it already exists, append ;C:\Users\Paul\AppData\Local\Programs\Python\Python37.
In newer versions of Windows 10 the UI is different and you don't have to add the semicolon because it lets you edit them as separate entries.
I am trying to configure EJBCA 6.15.2.1 on Wildfly 12.0.0.Final inside a Docker container with the help of EJBCA .properties files. In $EJBCA_HOME/conf/externalra-gui.properties.sample there is a comment showing that one of the default settings is: appserver.home=${env.APPSRV_HOME}. I tried to set other options in a similar way, e. g. in database.properties: database.datasource=${env.WF_DATASRC}.
I run ant clean deployear and it didn't deploy my EJBCA instance properly at first - server.log showed that there is no datasource under the name "${env.WF_DATASRC}". It proceeded correctly after I'd changed the line to: database.datasource=ejbcads, which is the exact value of the variable and the name of the data source inside the WildFly server.
I get similar errors during further installation steps. Is there another way of setting EJBCA configuration using environment variables?
I am using Yocto, when i run command env, i could see couple of variables have been set. But when I open up /etc/environment, those variable is not in there.
When i set variable in /etc/environment, for example, proxies, it is not reflected to my system.
How can I know where's the environment variable file?
Thank you.
Yocto environment is set by executing oe-init-build-env script. You can add bitbake variables in local.conf file.
I see that $JAVA_HOME is a built-in variable in IzPack. Can I assign to it in a pre-install script and have the installer use that? Currently I am stuck on a machine that defaults to an open-source JRE that runs horribly and I need to reassign it to the Sun JRE so that the installer will run properly.
In the pre-install script, can I append to the $PATH with:
${ENV[PATH]} = ${ENV[PATH]}:/usr/local/java/bin
Let me know what I can do, I cannot get access to write to the .cshrc or .cshrc.login and I cannot tell my users to set the environment variables themselves.
The answer to this for me was that I had to write a python script that set the environment variables and then called a subprocess to launch the installer. This is far from ideal, but it seems like if your machine is stuck by default with an open source JRE, then you can't fix that any other way.