I realize that:
sudo -i
env
is different from:
sudo -i
sudo env
They are both sudo, why are they different?
In my case, I realize the PATHs are very different, so sometimes things can't run with "sudo blah" but it works when I first log into sudo, then run the command. (Like my other question #4976658)
There are expected differences, such as SUDO_USER, SUDO_UID, and SUDO_GID.
And then there is PATH.
When you run
sudo -i
env
you should expect root's PATH, but when you run
sudo -i
sudo env
you should expect a default PATH.
I think you will find that this is due to the "secure path" option, that both Ubuntu and Fedora have adopted.
I agree it's annoying. There are many other threads about this behavior. :-/
For example, see this stackoverflow thread:
sudo changes PATH - why?
Related
When I run any Ansible command the response is always abort. For example:
ansible --version
# Or:
ansible-playbook -i production site.yml --diff --check
Response:
[1] 78576 abort ansible --version
Any idea why or how to fix? I updated Ansible but error remained the same. Things used to work in the past but it's been a few months since I've used Ansible.
I found the solution to my problem here. It's a problem with OpenSSL:
https://nbari.com/post/python-quit-unexpectedly-macos/
The steps to fix:
brew reinstall openssl
cd /usr/local/lib
sudo ln -s /usr/local/opt/openssl/lib/libssl.dylib libssl.dylib
sudo ln -s /usr/local/opt/openssl/lib/libcrypto.dylib libcrypto.dylib
This looks like something specific on your system which has been misconfigured.
re-trace your steps which could’ve led to this error
Try to reinstall Python / Ansible
use ‘ps aux | grep ansible’ to see if there are other Ansible processes running
virtualenv?
worst case ; reinstall system
I'm on Fedora release 25 with zsh 5.2
I am trying to use a command with sudo. (In this example, docker-compose)
Problem:
which command shows where it is.
$ sudo PATH=$PATH which docker-compose
/usr/local/bin/docker-compose
In spite of that, command not found
$ sudo PATH=$PATH docker-compose
sudo: docker-compose: command not found
I could make it work by sudo `which docker-compose` but I want to know why this occurs.
What I tried:
I double-quoted PATH=$PATH but got the same result.
$ sudo "PATH=$PATH" docker-compose
sudo: docker-compose: command not found
/usr/local/bin/ is not on root path. Check with
sudo bash -c 'echo "$PATH"'
/usr/sbin:/usr/bin:/sbin:/bin
Use absolute path to the command.
Adding /usr/local/bin to root path seems to be a security risk.
How do I install the anaconda / miniconda without prompts on Linux command line?
Is there a way to pass -y kind of option to agree to the T&Cs, suggested installation location etc. by default?
can be achieved by bash miniconda.sh -b (thanks #darthbith)
The command line usage for this can only be seen with -h flag but not --help, so I missed it.
To install the anaconda to another place, use the -p option:
bash anaconda.sh -b -p /some/path
AFAIK pyenv let you install anaconda/miniconda
(after successful instalation)
pyenv install --list
pyenv install miniconda3-4.3.30
For a quick installation of miniconda silently I use a wrapper
script script that can be executed from the terminal without
even downloading the script. It takes the installation destination path
as an argument (in this case ~/miniconda) and does some validation too.
curl -s https://gist.githubusercontent.com/mherkazandjian/cce01cf3e15c0b41c1c4321245a99096/raw/03c86dae9a212446cf5b095643854f029b39c921/miniconda_installer.sh | bash -s -- ~/miniconda
Silent installation can be done like this, but it doesn't update the PATH variable so you can't run it after the installation with a short command like conda:
cd /tmp/
curl -LO https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
bash Miniconda3-latest-Linux-x86_64.sh -b -u
Here -b means batch/silent mode, and -u means update the existing installation of Miniconda at that path, rather than failing.
You need to run additional commands to initialize PATH and other shell init scripts, e.g. for Bash:
source ~/miniconda3/bin/activate
conda init bash
In the case when I first ssh to the server and then run command, it executes successfully
root#chef:~# chef-solo -v
Chef: 11.10.0
But when I try to run it like this
ssh root#188.xxx.xxx.xxx -t -C "chef-solo -c /var/chef/solo.rb"
I receive an error:
bash: chef-solo: command not found
Why is this happening, and how can I solve this issue ?
It is still matter of $PATH and ssh - not chef-solo. Interactive and non-interactive sessions not necessarily have same value for the $PATH variable. Same ssh problem is described here on stackoverflow. You may also check GNU bash manual to have deeper insight of (non-)interactive and (non-)login shells. To shorten, solution would be one of the following:
Run chef-solo using absolute path. Here's how your command might look like:
ssh root#188.xxx.xxx.xxx -t -C "/usr/local/ruby/bin/chef-solo -c /var/chef/solo.rb"
Tune the .bash configuration files to load same $PATH variable for both interactive and non-interactive shells.
Note: To find out what's the absolute path, login to the machine via ssh and run which chef-solo (Don't know how experienced you are with linux. Sorry if I'm underestimating your knowledge)
I am wanting to detect in a shell script if a command I am going to run via sudo can in fact run via sudo. On newer versions of sudo I can do sudo -l "command" and this gives me exactly the result I want.
However, some of the systems have an old version of sudo in which -l "Command" isn't available. Another way I was thinking about doing it was to just try running the command then see if sudo prompted for the password. However, I do not see an easy way to do this as sudo writes the password prompt to the TTY and not via stdout.
Does anyone else know of a straight forward way to do this?
I should also mention "expect" doesn't seem to be available on the systems with the older sudo revisions, either.
Just for reference the "difficult" version of sudo appears to version 1.6.8
On Linux, on (at least) Debian-like systems, you can have a look at /etc/sudoers (and the optional /etc/sudoers.d/* files, if created, and included in the main /etc/sudoers) that give (among others)
the search path to where (which dir) a command can be issued
the sudo user (root) privileges
groups who can use sudo and their privileges
This is the sudoers man page for more information.
if you're only wanting to check that a password is required to run a command then you should be able to run:
$ sudo -n <command>
E.g.
$ sudo -n echo
sudo: sorry, a password is required to run sudo