Necesito ejecutar un comando ssh sudo.
comando es el siguiente:
ssh -i keyfile [email protected] 'sh -v /opt/dir/script'
el script contiene lo siguiente:
sudo -E node some.js
La razón por la que uso el argumento -E es que el usuarioA ejecuta el comando.Yel proceso que se inicia necesita cargar definiciones desde
/user/userA/.bashrc
el comando anterior NO carga las variables definidas en
/user/userA/.bashrc
Realmente se ejecuta como si -E no estuviera haciendo nada. es decir, todas las variables se muestran como indefinidas.
Si inicio sesión en la máquina remota de forma interactiva como usuarioA y ejecuto el mismo comando, es decir,
sudo -E node some.js
las variables se cargan correctamente y veo el comportamiento esperado.
¿Alguien puede ver lo que necesito hacer de manera diferente?
Respuesta1
Estás esperando que el shell sea source ~/.bashrc, así que supongo que el shell es Bash.
Giro número 1: el servidor SSH pasa el código de shell a un shell no interactivo. Bash no interactivono esleer ~/.bashrc.
Giro número 2: Bash intenta determinar cuándo se está ejecutando con su entrada estándar conectada a una conexión de red, como cuando lo ejecuta un servidor SSH. Si bash determina que se está ejecutando de esta manera,haceleer y ejecutar comandos desde ~/.bashrc.
Giro número 3: en muchas distribuciones (incluido Ubuntu), el valor predeterminado (esquelético) ~/.bashrccomienza con un código que regresa si el shell no es interactivo. En efecto, el resto del archivo esno obtenido.
Supongo que en su caso las variables de entorno relevantes se definen después de este código. El código puede verse así:
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
Una solución sencilla es mover las tareas para que esténanteseste código. Si desea mover comandos que hacen más cosas (por ejemplo, echoalgo, ejecutar algo), tenga mucho cuidado porque puede interrumpir las transferencias remotas de archivos. Leer¿Por qué se bashrccomprueba si el shell actual es interactivo?Si se trata solo de variables, entonces deberías estar seguro.
En general el ambientedebe definirse en~/.profileen lugar de en ~/.bashrc, pero si mueve las asignaciones a ~/.profileentonces experimentará esto:~/.profileno se carga cuando se usa SSH. No es descabellado tenerlos ~/.bashrcentonces.
Alternativamente, puede colocarlos en un archivo separado, por ejemplo ~/.special_env, y obtener el archivo desde ~/.bashrco ~/.profileo lo que sea. La ventaja es que puede obtener el archivo a pedido, independientemente de las peculiaridades y giros:
ssh -i keyfile [email protected] '. ~/.special_env; sh -v /opt/dir/script'