Fabric: 원격 서버의 환경 변수 및 PATH 문제(.bashrc를 소싱하지 않음)

이것은 대박이 아니라 멋진 일입니다.

무엇 bash는 파일하기 시작할 때 소스 결정은 복잡 할 수 http://blog.flowblok.id.au/2013-02/shell-startup-scripts.html 하고있는 데비안 / 우분투 (대부분의 배포판)가 일부 사용자 정의 /etc/profile 및 기본 ~/.bashrc .

fab에서 사용하는 기본 쉘은 /bin/bash -l -c 이고 -l 는 "로그인" 쉘로 만듭니다. debian/ubuntu 사용자 지정이 없으면 bash "login" 셸에서 ~/.bash_profile 를 소싱할 수 있지만 ~/.bashrc 는 소싱할 수 없습니다.

그러나 우분투 16.04에서는 login-shell의 경우에도 기본적으로 .bashrc 를 소싱하는 것으로 보입니다. 그러나 기본 .bashrc 의 맨 아래에 추가된 행은 처리되지 않습니다. 비대화형 실행이 감지되면 맨 위 근처에서 구제되기 때문입니다.

여기에 ubuntu-16.04 기본 사용자 .bashrc 에 두 줄을 추가했습니다.

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

export VAR1=val1

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

export VAR2=val2

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
...

다음은 테스트 중인 fabfile입니다.

from fabric.api import run, env, task

<strong i="23">@task</strong>
def get_myvars():
    run("echo VAR1=$VAR1 VAR2=$VAR2")

결과:

$ fab -H testpy05.ec2.st-av.net get_myvars
[testpy05.ec2.st-av.net] Executing task 'get_myvars'
[testpy05.ec2.st-av.net] run: echo VAR1=$VAR1 VAR2=$VAR2
[testpy05.ec2.st-av.net] out: VAR1=val1 VAR2=
[testpy05.ec2.st-av.net] out: 
...

한 눈에 제대로 들립니다. @ploxiln 감사합니다!

자세한 답변 감사합니다!

이것은 표준 ssh 동작과 다른 것으로 보이며 디버그하기 어려웠습니다. 내가 수동으로 ssh'했을 때 OSX에서 .bash_profile을 실행하지 않기 때문에 패브릭이 다른 PATH 값을 가졌을 때 모두 제대로 작동했습니다.

@bitprophet 이것은 OSX 버그 일 수 있습니다 ??

@code-tree 패브릭 1 또는 2를 사용하고 있습니까? 1.x는 명시적 셸 래퍼를 사용하므로 표준 OpenSSH 클라이언트와 다릅니다. 버전 2는 래핑을 수행하지 않으며 sshd가 사용자를 대신하여 실행되는 측면에서 OpenSSH 클라이언트와 훨씬 더 유사하게 작동해야 합니다.

버전 1에는 해당 쉘 래퍼를 변경하기 위한 몇 가지 env 구성 값 옵션이 있으므로 -i 와 같은 플래그를 추가하려고 할 수 있습니다.

2.2.1 버전을 사용하고 있기 때문에 이상합니다. 현재 내 앱이 작동하도록 하려면 다음을 수행해야 합니다.
c.run('bash -l -c "python3 ./configure.py"')
Python 3을 설치할 때 Fabric에서 실행되지 않는 .bash_profile 를 통해 PATH에 추가되었습니다. 표준 내장 sshd 구성도 수정하지 않았습니다.

이상합니다. 복제할 수 있는지 확인해야 합니다. 내가 의미하는 바를 증명하기 위해 빠른 온전한 추적을 수행했습니다. Fabric 2는 '특별한' 작업을 수행하지 않습니다. re: sshd 기반 실행:

• Runner.run은 시작이며 command
• 여기에 있는 Runner._run_body를 호출 하고 여전히 명시적 kwarg로 사용합니다.
• _run_body는 Runner.start를 호출합니다.
• Fabric의 Remote runner's .start는 여기
• command 대한 추가 수정 없이 Channel.exec_command를 호출합니다.
• Paramiko는 거기에서 인계받아 바닐라 SSH 실행 채널 요청을 구성하고 명령을 인라인합니다.
• 그 후에는 ssh myserver <command> 와 완전히 동일해야 합니다.

@code-tree 또한 가능하면 실행 중인 항목과 기타 환경 세부 정보(클라이언트 및 서버 OS/버전 등)에 대한 자세한 정보를 게시하십시오.

물론, 이전 OSX 버전을 서버로 실행하고 있습니다. 최신 MacOS에서 모든 것이 제대로 작동하는지 확인할 수 있다면 오 잘 됩니다. 그러나 그렇지 않은 경우 일반적으로 MacOS를 서버로 사용하는 데 문제가 있습니까?

• 클라이언트: Ubuntu 16.04, Python 3.6.6, OpenSSH 7.2p2, Bash 4.3.48, Fabric 2.2.1
• 서버: OSX 10.11, Python 3.6.6, OpenSSH 6.9p1, Bash 3.2.57

참고로 이것이 실제로 오진의 경우인지 궁금합니다.

OSX에서 .bash_profile을 실행하지 않기 때문에 패브릭에 다른 PATH 값이 있습니다.

대신 Fabric 2가 로컬 환경 변수를 파이프로 분류한다는 측면에서 ssh 와 다른 #1744의 예가 될 수 있습니까? (문제의 정확한 env 변수와 로컬 및 원격 유사 여부에 따라 다릅니다. @code-tree는 로컬 및 원격 bash_profile의 정확한 값을 다시 확인하여 이 이론을 쉽게 반증할 수 있습니다... 😁)

그러나 나는 이 문제를 직접적으로 해결할 것입니다. 내가 미친 것이 아니라는 것을 알기 위해서입니다. sshd가 쉘과 소스 파일의 관점에서 무엇을 하고 있는지에 대한 이해입니다.

또한 이것이 쉘 및 시작 파일에 관한 #1816의 시나리오/지능과 관련이 있는지 궁금합니다. ssh 한 방향으로 동작하고 Fabric이 다른 방식으로 동작한다는 주장 때문에 _아마도_ 직접적으로 관련이 없지만("sshd가 쉘을 정상적으로 호출하는 방법"과 다름) 어쨌든 연결할 가치가 있습니다.

지난 몇 개월 동안 했던 것으로 기억하는 깊은 sshd 코드 다이빙을 우연히 발견했습니다. 짜증나는 일이지만 지금은 찾을 수 없습니다. 편집: 아 인증 전에 명령을 실행하는 것과 관련이 없는 Paramiko 문제(혼란스러운 점이 없기 때문에 연결되지 않음)라고 생각합니다. 좋아요.

좋습니다. 그렇다면 우리가 exec 명령을 요청할 때 실제로 무슨 일이 일어나고 있습니까?

• SSH-the-protocol은 shell 채널 요청(사용자가 정의한 로그인 셸 프로그램을 로드하고 command 하지 않음) 또는 exec 채널을 요청합니다. 요청("경로를 포함할 수 있는 주어진 명령 문자열을 실행함"이라고 말하고 더 이상 지정하지 않음)
• Paramiko는 위에서 찾은 것처럼 후자를 수행합니다.
• 그렇다면 OpenSSH 자체는 실제로 무엇을 하고 있습니까? openssh-portable( 775f8a23f2353f5869003c57a213d14b28e0736e )의 로컬 체크아웃을 살펴보겠습니다.

글쎄, 먼저 내가 좀 빙빙 돌게. 내가하고시 DEBUG3 수준의 로그에서 볼 (! OpenSSH를 6.7를 실행하는) 임의의 데비안 8.10 컨테이너에 대해 실행 ssh localhost whoami :

debug1: server_input_channel_req: channel 0 request exec reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec
Starting session: command for root from 172.17.0.1 port 42598

fab -H localhost -- whoami :

debug1: server_input_channel_req: channel 0 request exec reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req exec
Starting session: command for root from 172.17.0.1 port 42610

알겠습니다. 둘 다 exec ...그건 당연합니다. 프로세스 트리에서 다른 것이 있습니까? 없어야 하고...없어야 합니다. 둘 다 다음과 같이 보입니다.

sshd,1 -D -e
  └─sshd,1535
      └─pstree,1537 -alpU

그래서, 확실히 플레이 중인 쉘이 없습니까? 뭐하는거야? && 와 같은 조잡한 것을 사용할 수 있습니까?

저 할 수 있어요! 예: whoami && id 는 잘 작동합니다. 유닉스 프로세스 제어에 대한 나의 이해를 감안할 때 이것은 약간 이상합니다. sshd가 말 그대로 exec(string) 하는 것 같지는 않지만 쉘을 사용하여 해석하는 경우 pstree 없습니까?

이제 openssh-portable을 자세히 살펴보고 무엇이 무엇인지 살펴봐야 할 때라고 생각합니다.

• 모든 마술은 session.c 에서 일어나는 것 같습니다.
• 첫 번째 흥미로운 중지는 session_input_channel_req 로그 라인이 발생하는 곳입니다. session_input_channel_req 에서 세션 유형(shell, pty open, exec, 하위 시스템 등)에 따라 다양한 기능을 기록하고 디스패치합니다.
• 우리의 경우 exec 이며 이는 session_exec_req 를 의미
• 이는 우리를 do_exec 로
• 회전의 어떤은 다시 기록하고, 결국 우리를 맞이할 하나에 do_exec_pty 나 (우리가 PTY을 요청하지 않았기 때문에 우리의 경우; 로그 선이 TTY 번호에 대해 조금이 없기 때문에 당신은 말할 수) do_exec_no_pty
• 포크 한 다음 do_child 를 호출하는
• 실제로 쉘을 얻고 환경을 설정합니다 !
• rc 파일로 작업을 수행합니다 ...
  
  
  
  • SSH의 자체 .rc 파일을 의미한다는 점을 제외하고
  
  
• 마지막으로, 예, 쉘, -c 및 명령 문자열로 execve 를 실행하도록 설정한 쉘을 사용

또한 2016년 12월 https://github.com/paramiko/paramiko/pull/398#issuecomment -264281759에서와 같이 과거에 이 추적의 일부를 _did_ 했습니다(그러나 다른 이유/초점으로). 완전히 잊고 있었다...

pstree 에서 쉘이 보이지 않는 이유는 execve 사용하기 때문입니다. 도 replace-me 스타일의 exec 호출을 수행할 수 있습니다. 아래 주석을 참조하세요.)

어쨌든, 그래서! 이것은 여전히 ​​Fabric 및 OpenSSH의 클라이언트가 셸 실행 측면에서 정확히 동일한 작업을 수행하고 있음을 의미해야 합니다. 그들 중 누구도 하지 않는 것은 OpenSSH 코드베이스의 이러한 부분을 수정하는 것입니다. @code-tree의 macOS 수준 사용자 및 구성된 셸에 따라 bash 의 실제 값과 함께 항상 bash -c "python3 ./configure.py" 와 같아야 합니다.

env var transmission이 차별화 요소라는 내 직감이 정확한지 궁금합니다. 두 실행 환경이 어떻게 다를 수 있는지 생각할 수 있는 유일한 이유입니다. 내 CLI 중심 테스트의 FWIW에서 env 는 두 시스템 모두에서 동일하게 보고하며 다른 환경 관련 문제에 관계없이 _default_ 동작(SSH 보안 정책으로 인해)은 항상 로컬 환경이 "누수"되지 않아야 합니다. 반대편.

예, sshd가 항상 사용자의 셸에서 명령 문자열을 실행한다고 확신합니다(/etc/passwd에 구성됨). 그러나 명령 문자열을 구문 분석하고 단일 명령임을 결정할 수 있는 경우 명령 문자열 앞에 "exec"가 추가됩니다.

$ ssh testdeploy02.ec2.st-av.net pstree -a
...
  |-sshd -D
  |   `-sshd 
  |       `-sshd  
  |           `-pstree -a

$ ssh testdeploy02.ec2.st-av.net 'pstree -a && sleep 1'
...
  |-sshd -D
  |   `-sshd 
  |       `-sshd  
  |           `-bash -c pstree -a && sleep 1
  |               `-pstree -a

$ ssh testdeploy02.ec2.st-av.net 'VAR=-a sh -c "exec pstree \$VAR"'
...
  |-sshd -D
  |   `-sshd 
  |       `-sshd  
  |           `-pstree -a

환경 변수의 경우 대부분 ssh 클라이언트 및 sshd 서버 구성에 의해 제어됩니다.

$ grep Env /etc/ssh/*_config
/etc/ssh/ssh_config:    SendEnv LANG LC_*
/etc/ssh/sshd_config:AcceptEnv LANG LC_*

따라서 ssh 클라이언트는 일부 변수(명령 문자열 자체 외부)를 명시적으로 보내고 sshd에 의해 필터링됩니다. 그러나 분명히 몇 가지 예외가 있습니다.

$ ssh testdeploy02.ec2.st-av.net env | grep TERM
$ ssh -t testdeploy02.ec2.st-av.net env | grep TERM
TERM=xterm-256color

실제로 "쉘을 단일 명령으로 교체하는 자동 실행"동작이 bash의 기능이라고 생각합니다.

$ dash -c "pstree -a"
...
  ├─sshd -D
  │   └─sshd 
  │       └─sshd  
  │           └─bash
  │               └─dash -c pstree -a
  │                   └─pstree -a

$ bash -c "pstree -a"
  ├─sshd -D
  │   └─sshd 
  │       └─sshd  
  │           └─bash
  │               └─pstree -a

편집: 완전성을 위해:

$ bash -c "pstree -a && sleep 1"
  ├─sshd -D
  │   └─sshd 
  │       └─sshd  
  │           └─bash
  │               └─bash -c pstree -a && sleep 1
  │                   └─pstree -a

아 예, 제가 잘못 생각했습니다. execve 는 sshd 자식 proc 이 대체된다는 것을 의미하므로 그 이후에 일어나는 일은 셸 자체와 -c xxx 달려 있습니다. 내 테스트는 zsh, fwiw에 있었습니다.

또한 @ploxiln 예 , env vars가 있는 것은 위에 링크된 다른 티켓을 참조하고 있지만 @code-tree가 실제로 다른 티켓을 경험하고

죄송합니다. 잘못된 경보인 것 같습니다. ssh 인라인을 통해 명령을 실행하는 것과 ssh를 통해 로그인한 후 실행하는 것 사이에 차이가 있다는 것을 알지 못했습니다. ssh host 'echo $PATH' 하면 로그인 후 echo $PATH 가 제대로 작동하는 PATH도 업데이트되지 않았습니다.

나는 여전히 ssh가 왜 이것을하는지 정말로 이해하지 못합니다 (실제로 ssh host 'bash -l -c "python3 ./configure.py"' 해야 하는 것 같습니다). 그럼에도 불구하고 이것은 결국 Fabric 문제가 아니라고 말하는 것이 안전합니다. 혼란을 드려 죄송합니다.

@code-tree 앞서 언급한 것과 관련이 있습니다. 셸에는 작동하는 몇 가지 다른 모드가 있으며, 흔히 '로그인' 및 '대화형'이라고 합니다(일반적으로 둘 다 고려되지 않는 기본 모드 위에 있음). 쉘이 실행 중이면 로드하는 rc 파일 세트가 변경됩니다.

여기서 두드러진 점은 bash -c xxx 가 "대화형"으로 간주되지 않으므로 .bash_profile 와 같은 특정 파일 로드를 건너뛰지만 bash 없이 -c bash 를 실행한다는 것입니다. 일반적으로 대화형이며 프로필 파일을 로드합니다.

위에서 보았듯이 sshd는 단일 명령을 실행하도록 요청할 때 항상 bash -c <command send down the pipe> 를 실행하므로(Fabric과 같이 또는 ssh host command 가 수행하는 것처럼) 항상 비대화식 모드에 있습니다. (Fabric 1이 하는 일을 하고 -l 자신의 중첩된 쉘을 실행하지 않는 한 ...하지만 bash -c "bash -l -c \"oh god escaping is hard help\"" 하고 있고 지금 가서 일부 🥃를 가지려고 합니다.

어쨌든 다 잃는 건 아니니까 몇 년에 한 번씩 이 부분에 대한 기억을 새로고침해야 하는 것 같으니까 어...이제 기분이 상쾌해 😆

이것은 대박이 아니라 멋진 일입니다.

무엇 bash는 파일하기 시작할 때 소스 결정은 복잡 할 수 http://blog.flowblok.id.au/2013-02/shell-startup-scripts.html 하고있는 데비안 / 우분투 (대부분의 배포판)가 일부 사용자 정의 /etc/profile 및 기본 ~/.bashrc .

fab에서 사용하는 기본 쉘은 /bin/bash -l -c 이고 -l 는 "로그인" 쉘로 만듭니다. debian/ubuntu 사용자 지정이 없으면 bash "login" 셸에서 ~/.bash_profile 를 소싱할 수 있지만 ~/.bashrc 는 소싱할 수 없습니다.

그러나 우분투 16.04에서는 login-shell의 경우에도 기본적으로 .bashrc 를 소싱하는 것으로 보입니다. 그러나 기본 .bashrc 의 맨 아래에 추가된 행은 처리되지 않습니다. 비대화형 실행이 감지되면 맨 위 근처에서 구제되기 때문입니다.

여기에 ubuntu-16.04 기본 사용자 .bashrc 에 두 줄을 추가했습니다.

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

export VAR1=val1

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

export VAR2=val2

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
...

다음은 테스트 중인 fabfile입니다.

from fabric.api import run, env, task

<strong i="24">@task</strong>
def get_myvars():
    run("echo VAR1=$VAR1 VAR2=$VAR2")

결과:

$ fab -H testpy05.ec2.st-av.net get_myvars
[testpy05.ec2.st-av.net] Executing task 'get_myvars'
[testpy05.ec2.st-av.net] run: echo VAR1=$VAR1 VAR2=$VAR2
[testpy05.ec2.st-av.net] out: VAR1=val1 VAR2=
[testpy05.ec2.st-av.net] out: 
...

당신은 내 생명을 구했습니다. 이것은 내가 찾는 완벽한 답변입니다 :) 많은 감사합니다!