Ubuntu bug? Environment variables only after logging as root - linux

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

Related

http proxy setting does not present in salt-minion older versions

It seems that http proxy setting in salt-minion does not support in salt-minion older version. Do we have any workaround for this.
When I am running salt command from salt-master, environment variables set in salt minion do not work.I have my http proxy setting in environment variables.but when i am running command from salt-master it does not get variables set in env.
Please let me know if any workaround for this.
Salt minion version: 0.17.5
You should set it permanently, and system wide (all users, all processes) add set variable in /etc/environment:
sudo -H gedit /etc/environment
This file only accepts variable assignments like:
HTTP_PROXY="my value"
Do not use the export keyword here.
You need to logout from current user and login again so environment variables changes take place.

Setting environment variables for no-login users

I have an RHEL server with tomcat installed. Tomcat runs as a no-login user called tomcat . I have set the required environment variables in /etc/profile.d/myenvvars.sh as
export JRE_HOME=/usr/lib/jvm/jre
export MY_VAR=/usr/share/mydir
The environment variables are set and can be echoed in the terminal using
# echo $MY_VAR
# sudo -u tomcat echo $MY_VAR
However when tomcat starts my environment variable is not recognised by tomcat.
As per this article I found that my environment variables will not be recognised when tomcat starts as tomcat is a no-login user. Therefore I sourced the above file in ~/.bash_profile using
. /etc/profile.d/myenvvars.sh
However, I still have the same issue, the environment variable is not reccognised.
Any help would be appreciated.
As stated in the article your linked your settings need to be in ~/.bashrc.
There may be a chance that even this is not working... depending on how your tomcat is started.
You could have a custom script for tomcat to make sure it loads the environment variables e.g. something like this
tomcat-start.sh
. /etc/profile.d/myenvvars.sh
tomcat

Adding ssh keys to ssh-agent fails w/ running agent, environment variables set

[SSH] "Could not open a connection to your authentication agent". error
I am trying to add ssh keys into my ssh agent. I start by making sure that the ssh-agent is running.
exec ssh-agent bash
I make sure that ssh-agent is running.
ps axu | grep [s]sh
and get the following
root 1562 ... ssh-agent bash
The env variables are set correctly.
SSH_AGENT_PID=1562
SSH_AUTH_SOCK=/tmp/ssh-699iHAxuK4xX/agent.1561
However when I try to add the private key using
sudo ssh-add ~/.ssh/peter-key
I get the ssh error
Could not open a connection to your authentication agent.
I have tried the suggestions on stackoverflow and serverfault but nothing.
Note: I am running a linux machine on one of the free tier AWS machines with ubuntu. My instance's security group allow (temporarily) all incoming and outgoing ssh connections from any IP address. Anyone know what the error could be?
Just use
ssh-add ~/.ssh/peter-key
...not...
sudo ssh-add ~/.ssh/peter-key
Using sudo (optionally/configurably, but typically) clears a number of environment variables, including the ones you just verified were set. (Compare output of sudo env and plain env to see this effect).
If you must use sudo to read the key, then you can ensure that the necessary environment variable is set on the other side by doing so explicitly yourself:
sudo env "SSH_AUTH_SOCK=$SSH_AUTH_SOCK" ssh-add ~/.ssh/peter-key
However, it's possible for security-sensitive programs working with UNIX domain sockets to check the ownership and permission of software on the other end of that socket, and to refuse to communicate with anything running on a user account different from what they expect, so it's possible that this approach may not be future-proof against security features added to ssh-agent.

Setting path variable for apache user on Amazon EC2

I can't add /usr/local/bin to the apache users PATH variable. The user doesn't have a .profile, I can't su to the user, I can't export to the PATH from php using exec and adding
SetEnv PATH /usr/local/bin
To either the http.conf or the .htaccess file doesn't make a difference. I can't find the envvars file to change that but I suspect there's some other problem.
I have restarted apache, and indeed my server.
Ended up following what Alfe suggested in his answer, except rather than in the /etc/init.d/httpd file (which could be overwritten easily on update) I added to /etc/sysconfig/httpd:
export PATH=${PATH:+$PATH:}/usr/local/bin
Have a look at the /etc/passwd to see which login shell the apache user has (on EC2 Ubuntu instances it should be /bin/sh which is a link to /bin/dash). Then have a look at the man page of that shell and find out which configuration files are read upon login. (For /bin/dash that would be .login in the user's home directory.) In those you should be able to extend your $PATH as you like.
EDIT:
Since you seem to have no login shell for that user: Have a look at the /etc/init.d/* scripts which start the system services. Apache will be one of them. They are started as root and may change the current user (e. g. to the apache user). In there you might be able to adjust the PATH as you like it.
Patching those scripts, however, is not considered typical configuration. Updates might overwrite what ever you patch there.

Jenkins ignores proxy settings while building a job

I set a proxy under Plugins in Jenkins like suggested online.
I also edited the /etc/environment
bash-3.2$ cat /etc/environment
http_proxy=proxy.company.net:8080
https_proxy=proxy.company.net:8080
HTTP_PROXY=proxy.company.net:8080
HTTPS_PROXY=proxy.company.net:8080
HTTPS_PROXY_REQUEST_FULLURI=false
HTTP_PROXY_REQUEST_FULLURI=false
I verfied the variables and they are available on logon.
When I start ant manualy as root via ssh, my "composer.phar" script is able to connect and download files. As soon as Jenkins starts the job (I think its the "jenkins" linux user), he waits until timeout and aborts the build. I used "su jenkins -s /bin/bash" to get a shell as "jenkins" and the env-vars are set correctly...
What can I do? Why does Jenkins ignore these ENV-Vars?
Thanks.
The http_proxy variables (as seen e.g. on the wget man page) require a "http://" prefix to work properly for many programs.
Jenkins on the other hand has a proxy configuration at Manage Jenkins > Plugin Manager > Advanced. This configuration overrides the environment variables.
Check Alex' answer to another question for getting around this behavior for individual nodes/builds.
I did not get it solved. After a restart the server fails all Jenkins Jobs for some minutes... suddenly the connection to the proxy succeeds and everything works well.

Resources