environment usando su - vs “ssh user @ machine” como usuário no lucid

Question

Estou tentando depurar um problema no ambiente de shell em uma máquina que está executando o lucid.

Ambos root & usuário tem / bin / bash como seu shell em / etc / passwd Quando eu uso "sudo su - user", meu PATH inclui o seguinte diretório: /usr/local/rvm/rubies/ruby-1.9.3-p194/bin/ruby quando eu "ssh user @ machine" tem: /usr/local/rvm/rubies/ruby-1.9.2-p290/bin/ruby

Agora, provavelmente há algumas respostas específicas de ruby / rvm aqui - não é isso que estou procurando, o que estou tentando entender é o problema geral de onde procurar para encontrar o que quer que seja definindo o caminho. Eu sei que / etc / profile é executado, mas está sendo executado em ambos os casos, então não sei qual é o problema - existem outros arquivos que também são carregados no login - em um caso, mas não no outro. ? / qualquer outra coisa que esteja sendo carregada e que possa estar configurando o PATH?

Portanto, parece que algo está acontecendo antes de o / etc / profile ser carregado. Eu echoi o ambiente na primeira linha do / etc / profile, e no caso do ssh, o caminho já incluía uma referência a /usr/local/rvm/rubies/ruby-1.9.2-p290/bin - em o sudo caso não. Parece que o / etc / environment é usado no caso do ssh, mas não no caso do sudo ...

Uma outra coisa que encontrei recentemente é relevante também, de: Qual é a diferença entre "su" com e sem hífen?

o arquivo /etc/login.defs é usado ao fazer su, e a configuração PATH do / etc / environment é sobrescrita pelo ENV_PATH ou pelo ENV_SUPATH lá ...

um esclarecimento / etc / profile é usado para shells de login, mas não para shells que não são de login - por exemplo, sudo env não mostra variáveis que são definidas apenas em / etc / profile

ao fazer login em uma conta, as variáveis configuradas somente em / etc / environment não serão exibidas

    

Answer 1

Isso provavelmente se deve à diferença entre o login e os shells interativos. Veja aqui para um bom resumo.

O primeiro arquivo que o sistema lê para definir variáveis é /etc/environment . Depois disso, quais arquivos são lidos depende da forma como o bash foi invocado. Quando você ssh user@machine , você inicia um login shell , mas quando você su username , você inicia um interativo, não-login shell . O Bash irá ler suas configurações de inicialização de arquivos diferentes em cada caso. O seguinte é da página man bash (ênfase minha):

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.

Então, o bash lê diferentes arquivos de inicialização, dependendo de sua invocação. Dê uma olhada no conteúdo desses arquivos em sua máquina, você provavelmente encontrará $PATH sendo definido de diferentes maneiras.

Dito isto, como @mpy corretamente apontado nos comentários, sudo su - user deve iniciar um shell de login. Você está certo que está usando sudo su - e não é simples sudo su ou apenas su ? O - deve iniciar um shell de login que deve ler exatamente os mesmos arquivos de inicialização que ssh user .