Perché un comando remoto SSH ottiene meno variabili di ambiente rispetto all'esecuzione manuale? [chiuso]
-
03-07-2019 - |
Domanda
Ho un comando che funziona bene se eseguo SSH su una macchina e lo eseguo, ma fallisce quando provo ad eseguirlo usando un comando remoto ssh come:
ssh user@IP <command>
Confronto dell'output di " env " utilizzando entrambi i metodi si verifica nei diversi ambienti. Quando accedo manualmente alla macchina ed eseguo env, ottengo molte più variabili di ambiente rispetto a quando eseguo:
ssh user@IP "env"
Qualche idea sul perché?
Soluzione
Esistono diversi tipi di shell. La shell di esecuzione del comando SSH è una shell non interattiva, mentre la shell normale è una shell di accesso o una shell interattiva. Segue la descrizione, da man bash:
A login shell is one whose first character of argument zero is a -, or one started with the --login option. An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state. The following paragraphs describe how bash executes its startup files. If any of the files exist but cannot be read, bash reports an error. Tildes are expanded in file names as described below under Tilde Expansion in the EXPANSION section. 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 behav ior. When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists. When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. 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 ~/.bashrc. When bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed: if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi but the value of the PATH variable is not used to search for the file name.
Altri suggerimenti
Che ne dici di procurarti il ??profilo prima di eseguire il comando?
ssh user @ host " source / etc / profile; /path/script.sh"
Potresti trovare la soluzione migliore per cambiarlo in ~ / .bash_profile
, ~ / .bashrc
, o altro.
(Come qui (linuxquestions.org) )
L'ambiente Shell non viene caricato quando si esegue il comando ssh remoto. È possibile modificare il file di ambiente ssh:
vi ~/.ssh/environment
Il suo formato è:
VAR1=VALUE1
VAR2=VALUE2
Controlla anche la configurazione di sshd per PermitUserEnvironment = yes opzione.
Ho avuto un problema simile, ma alla fine ho scoperto che ~ / .bashrc era tutto ciò di cui avevo bisogno.
Tuttavia, in Ubuntu, ho dovuto commentare la riga che interrompe l'elaborazione ~ / .bashrc:
#If not running interactively, don't do anything
[ -z "$PS1" ] && return
Ho trovato una soluzione semplice per questo problema da aggiungere fonte / etc / profilo all'inizio del file script.sh stavo cercando di eseguire sul sistema di destinazione. Sui sistemi qui, ciò ha causato la configurazione delle variabili ambientali necessarie per script.sh come se fossero in esecuzione da una shell di login.
In una delle risposte precedenti è stato suggerito di usare ~ / .bashr_profile ecc .... Non ho trascorso molto tempo su questo, ma il problema è che se si invia a un utente diverso sul sistema di destinazione rispetto alla shell sul sistema di origine da cui si accede mi è sembrato che ciò causi l'utente del sistema di origine nome da utilizzare per ~.
Esporta semplicemente le variabili di ambiente che desideri sopra il controllo per una shell non interattiva in ~ / .bashrc.