We are using linux on an embedded system that has busybox 1.20.2 for the various shell commands. We are having a very strange problem in that env does now show the value of LD_LIBRARY_PATH:
$ export LD_LIBRARY_PAT=/usr/bin
$ export LD_LIBRARY_PATH=/usr/bin
$ export LD_LIBRARY_PATH1=/usr/bin
$ env | sort
ENV=/etc/profile.environment
HISTFILE=/tmp/.ash_history.debug.357
HOME=/home/debug
LD_LIBRARY_PAT=/usr/bin
LD_LIBRARY_PATH1=/usr/bin
LOGNAME=debug
MAIL=/var/mail/debug
PATH=/home/debug/bin:/usr/bin:/bin:/usr/sbin:/sbin
PWD=/home/debug
PYTHONPATH=:/home/debug/tools/tools-0.0.0/common
SHELL=/bin/bash
SHLVL=1
SSH_CLIENT=10.10.10.22 58307 22
SSH_CONNECTION=10.10.10.22 58307 10.10.12.23 22
SSH_TTY=/dev/pts/0
TERM=xterm
USER=debug
_=/usr/bin/env
$
$ echo $LD_LIBRARY_PAT
/usr/bin
$ echo $LD_LIBRARY_PATH
/usr/bin
$ echo $LD_LIBRARY_PATH1
/usr/bin
As you can see, LD_LIBRARY_PATH is set, but it just doesn't show up in the output of env. AFAIK, it is the only environment variable that this happens.
Can anyone explain why this is happening? Thanks!
Linux won't let you mess with the LD_LIBRARY_PATH because busybox (probably) has its setuid bit turned on. Busybox has a bunch of common linux commands built into its binary, so it needs setuid.
Related
Where are the environment variables located on a docker container, more precisely, where is ENV=1 stored from the following:
$ docker run --rm -e ENV=1 -it ubuntu:16.04 bash
root#40e384fc9c1f:/# env
HOSTNAME=40e384fc9c1f
TERM=xterm
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
ENV=1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
SHLVL=1
HOME=/root
_=/usr/bin/env
All linux docs I read pointed to either: /etc/environment, ~/.bashrc, ~/.bash_profile, and ~/profile, but when dumped those files, I saw nothing related to declaration of ENV=1.
Is it perhaps something specific to docker and how it sets up the environment?
If a variable is specified as an option when executing a Docker command, the Docker image is read-only, so it is likely to be stored only in memory, not in the file.
When you run docker run -e VAR=value some-image, the container has a single process, and the environment variable is set in that process's environment. It's not in any particular file. The lowest-level Unix function to run a command is execve(2) and in that system call you just pass the new command's environment as parameters.
Locally, try running
export ANYTHING=value
env | grep ANYTHING
grep ANYTHING ~/.profile
and you'll similarly notice that the environment variable is set; running env(1) as a subprocess sees it; but it doesn't exist in any of the files you mention.
Normally in Docker, none of the files you mention are read at all. It's highly likely that the standard shell isn't GNU bash; if you're using an Alpine-based image, you may not even have a /bin/bash. None of this is a problem, but it means that you should usually ignore shell dotfiles.
Instead, to set an environment variable in an image, use the Dockerfile ENV directive. When you docker build the image, that value will be persisted, and you can see its value if you docker inspect the image, but it's not directly accessible on disk anywhere and it won't be visible in any of the dotfiles you mention.
As an example:
FROM alpine
# Set an environment variable using ENV
ENV VAR_1=from-dockerfile-env
# These won't work at all
RUN echo 'export VAR_2=from-etc-profile' >> /etc/profile
RUN echo 'export VAR_3=from-etc-bashrc' >> /etc/bashrc
# Also has no effect
RUN echo 'export VAR_4=from-source-script' > /source-script.sh
RUN echo 'source /source-script.sh' >> /etc/profile
# _Also_ has no effect
RUN export VAR_5=from-dockerfile-run
# When you run the container, see what is set (only $VAR_1)
CMD env | grep VAR
Folks,
I'm following the Docker tutorial here: https://docs.docker.com/get-started/part4/#configure-a-docker-machine-shell-to-the-swarm-manager and coming up against resistance when running this particular command:
eval $(docker-machine env myvm1)
I'm actually running (as above but with addition of sudo).
eval $(sudo docker-machine env myvm1)
I get no output from the command line to tell me anything has been done and when I run:
sudo docker-machine ls
I see that myvm1 does not have an active state as expected. I do know that this step isn't necessary but I'd like to understand why the command is not working and try to fix it.
I am running docker 17.09.0-ce
On Ubuntu 16.04 LTS
zsh shell (have tried switching to bash)
This is just on my local machine by the way, not a server.
Any help would be much appreciated.
There's less to go wrong if you run the eval on the far side of sudo:
sudo sh -c 'eval "$(docker-machine env myvm1)"; docker-machine ls'
Otherwise, the environment variables set by evaling the output of docker-machine env aren't necessarily (barring some very specific /etc/sudoers configuration) propagated through to the future docker-machine invocation.
If you wanted to automate this with a shell function, that can be done:
# docker-env sudo; usage: desudo vm-name command-to-run
desudo() {
local cmd1 cmd2
printf -v cmd1 'eval "$(docker-machine env %q)"' "$1"; shift
printf -v cmd2 '%q ' "$#"
sudo bash -c "${cmd1} && exec ${cmd2}"
}
...used as:
desudo vm1 docker-machine ls
You should run eval $(docker-machine env myvm1).
In fact, you don't have to add sudo.
But you may doesn't have permission to run docker without sudo, here is how to solve this issue on Linux.
Following the steps in this article "Post-installation steps for Linux"
Create the docker group. sudo groupadd docker
Add your user to the docker group. sudo usermod -aG docker $USER
Log out and log back in so that your group membership is re-evaluated.
Verify that you can run docker commands without sudo.docker run hello-world.
If you see the following error:
WARNING: Error loading config file: /home/user/.docker/config.json -
stat /home/user/.docker/config.json: permission denied
Fix it with:
$ sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
$ sudo chmod g+rwx "/home/$USER/.docker" -R
I too was having the exact same problem as posted and have spent the better part of the morning googling for an answer. I went back through the documentation and realised that I completely omitted the post-installation steps for Linux.
https://docs.docker.com/install/linux/linux-postinstall/
I followed the instructions laid out in the section labelled Manage Docker as a non-root user and eval $(sudo docker-machine env myvm1) and the subsequent docker-machine ls worked as expected. In addition... it eliminates the need to prefix all your docker commands withsudo.
I should have RTFM I guess?
I'm actually running (as above but with addition of sudo).
eval $(sudo docker-machine env myvm1)
I get no output from the command line to tell me anything has been done and when I run:
sudo docker-machine ls
I see that myvm1 does not have an active state as expected.
run this command it will work
sudo sh -c 'eval "$(docker-machine env myvm1)"; docker-machine ls'
I am using CentOS 6.5 version. I got sudo permissions and installed java, and set up JAVA_HOME this way .
$ cat /root/.bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
export JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
PATH=$PATH:$JAVA_HOME/bin
export PATH
And now when i did
$ echo $JAVA_HOME
/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
But once i logout and do
$ echo $JAVA_HOME
/usr/local/jdk
Could you please tell me how do i set java_home for all users ??
vi /etc/profile
export JRE_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
export PATH=$PATH:$JRE_HOME/bin
export JAVA_HOME=/your-path-to-java
export JAVA_PATH=$JAVA_HOME
export PATH=$PATH:$JAVA_HOME/bin
System settings for java, CentOS ,,, for all users :
# /usr/sbin/alternatives --config java
I'm using virtualenvwrapper and trying to create a virtualenv using a version of python that's not the default.
What I'd like to do is:
$ which python2.7
>> /usr/local/bin/python2.7
$ mkvirtualenv -p /usr/local/bin/python2.7 env
...But without the copy-paste. Is there a way to do this in one line?
mkvirtualenv -p "$(type -P python2.7)" env
is the correct way to write this as a one-liner. type is a POSIX standard utility, so it is more likely to exist and work consistently across POSIX-ish systems than which.
I am missing my basic unix commands on Yosemite 10.10
Here is my path from ~/.zshrc
export PATH="/Users/tims/.rbenv/shims:/usr/local/bin:/usr/bin:/usr/local/shared/bin:/usr
I will check my ~/.bash_profile
Very strange
$ type -a cd
cd is a shell builtin
cd is /usr/bin/cd
https://unix.stackexchange.com/questions/116955/where-is-cd-located