Quiero usar el script .sh para la implementación de mi aplicación. Ese script está en mi servidor doméstico (Ubuntu 15.10 Server), marcado como ejecutable. El acceso a este script se realiza a través de ssh, utilizando este tutorial, he configurado ssh login, que ejecuta ese script. Básicamente, solo llamo ssh [email protected] someArguments
y ejecuta mi script con someArguments
parámetros. El usuario deployer
tiene uid = 0, por lo que es básicamente root
(esto cambiará en el futuro, lo configuré solo para eliminar los problemas de permisos hasta que funcione bien).
Y aquí es donde las cosas se ponen difíciles. El script informa /usr/bin/env: php: No such file or directory
en el comando /bin/composer install
(usando Composer ). Las cosas son más raras cuanto más miro ese guión. Antes de esta línea, también se llama /bin/composer self-update
y /bin/composer -V
, que se ejecuta correctamente y muestra la salida correcta.
He comprobado las siguientes cosas:
/usr/bin/env php -v
muestra la versión correcta de PHP (igual que/usr/bin/php -v
)whereis php
muestraphp: /usr/bin/php /usr/local/bin/php /usr/share/man/man1/php.1.gz
php5-cli
el paquete está instalado y la versión más nueva$PATH
contiene/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
which env
muestra/usr/bin/env
También he intentado lo siguiente:
- Ejecutar el script directamente como
bash deploy.sh
root (ya que es el mismo que el usuario): funciona perfectamente sin errores - ejecutar comandos fallidos directamente, también perfectamente sin errores
Esto me parece un caso muy específico, por qué este comando no funciona. Pasé 12 horas depurándolo y no tengo ideas aquí.
PD: Se /usr/bin/env: node: No such file or directory
produce un error similar ( ) cuando hay bower install
(usando Bower ), pero no cuando se ejecuta npm install
(usando NPM ).
sh deploy
lugar debash deploy
(quizás algo de bashism). ¿Cómo comprobaste las " cosas siguientes "? Recomiendo verificarlos en el script, para que pueda descubrir eventuales anulaciones y desinfecciones de envs.sh deploy
ybash deploy
ambos dan los mismos resultados/usr/bin/env > environment.txt
Respuestas:
Asegúrese de que los finales de línea y / o espacios invisibles no estén causando el problema.
Elimine los espacios en la primera línea del script e inserte otros nuevos, asegurándose de no mantener presionada la tecla CTRL mientras presiona la barra espaciadora.
Además, asegúrese de no tener terminaciones de línea de DOS (CR + LF). Ver /programming/82726/convert-dos-line-endings-to-linux-line-endings-in-vim para más detalles.
fuente
La forma más fácil ... cambia el shell del usuario como el script.
/ etc / passwd
Script de ejemplo (asegúrese de que el bit de ejecución esté configurado chmod + x)
/scripts/deploy.sh
¡Funciona siempre! Incluso debería poder usar el script para solucionar problemas / depurar cualquier variable env que pueda sentir que no está configurada, etc. También funcionarán los argumentos de manejo que se pasan a ssh.
Nota: Su mejor práctica es CALIFICAR siempre TOTALMENTE las rutas para cualquier script, ejecutable, etc. Lo anterior es solo un ejemplo que permite configurar la ruta predeterminada para llamar a moo.sh dentro de la carpeta moo;)
Eso fue fácil ... Gracias por publicar ...
Referencia: / etc / passwd format
fuente
ssh
en el servidor, y por carrilauthorized_keys
, se llama al script y luego termina la conexión. ¿Cómo debo modificarauthorized_keys
para mantener esto funcionando?El
env
comando buscará a través de un usuario$PATH
para encontrar el primer ejecutable del nombre dado. Por lo tanto,/usr/bin/env php
buscará un archivo ejecutable llamadophp
en cualquiera de los directorios$PATH
del usuario que lo ejecuta.En su caso, eso es casi seguro porque cuando ejecuta un comando
ssh
, no inicia un shell completo y en realidad no lee los archivos de inicialización de su shell. Puede verificar esto ejecutando este comando (tenga en cuenta las comillas simples):Y comparando la salida con lo que obtienes si tú
ssh [email protected]
y luego corresecho $PATH
. En mi sistema por ejemplo:Por lo tanto, el
$PATH
acceso al script al ejecutarlossh [email protected]
no es el mismo que cuando inicia sesión para probarlo.En cualquier caso, la solución simple es utilizar la ruta completa al intérprete en lugar de
env
. Ambasenv
y las rutas completas tienen sus ventajas e inconvenientes , pero, en este caso, la ruta es más segura:fuente
composer install
comando, que obviamente no puedo modificar. También$PATH
está bien, como mencioné en mi pregunta también, verifiqué todas las cosas agregándolas al script y ejecutándolas de forma remota a través de ssh login Además, no puedo verificar lossh [email protected] 'echo $PATH'
que dijiste, ya que mi inicio de sesión ssh se limita a un solo script, pero lo comprobé cuando agregué $ PATH a ese script (indicado anteriormente) De todos modos, gracias por tu respuesta y acepta + 1 por explicarme laenv
cosaenv
realidad se llama compositor interno. Pero esto no resuelve el problema, por qué algunas llamadas de compositor pasan y otras no. Sin embargo, investigaré esto más a fondo buscando en su código. Gracias por su tiempo¿Es posible que
bash
necesite restablecer su tabla hash?Si es así, puede intentar agregar
hash -r
en algún lugar de su script, lo que obliga al shell a revisar$PATH
nuevamente en lugar de confiar en la información (posiblemente desactualizada) de la tabla hash.Cuando sea necesario,
hash
también puede habilitar el shell para recordar rutas a ejecutables instalados en ubicaciones no estándar utilizando la-p
opción, u olvidar rutas con la-d
opción.Fuentes:
https://unix.stackexchange.com/a/86017/121251
https://stackoverflow.com/a/22543353/2146843
fuente
Parece que tal vez necesites agregar php a tu camino. Tratar:
También es posible que desee verificar dónde vive su php para asegurarse de que la ruta allí sea correcta. Tratar:
fuente
php -v
genera la versión correcta de PHP y lacomposer --version
versión del compositor. Como dije, el problema está en un solo comando.Está claro que tiene un problema de ruta ya que su script de implementación no puede encontrar cosas que definitivamente están en la ruta cuando realiza un inicio de sesión ssh normal.
Lo primero que debe hacer para confirmar que tiene un problema de RUTA es actualizar su script de implementación para registrar la salida de,
env
o al menosecho $PATH
. Supongo que por la forma en que se llama el script de implementación, $ PATH no está configurado como cabría esperar. Esta salida de depuración confirmará / negará mi teoría.Miré el tutorial que seguiste. Probablemente debería asegurarse en la actualización
command=
de sercommand="/bin/sh /path/to/your/script..."
si aún no se ha asegurado de que su script se ejecute en el shell correcto.Si tiene un problema de RUTA, una solución rápida / sucia es establecer explícitamente RUTA al comienzo de su script de implementación.
Explicación detallada y más opciones ...
En Linux, cuando se ejecutan comandos, heredan el entorno de su proceso padre.
Cuando inicia sesión como usuario normal a través de SSH, suceden cosas (como ejecutar / etc / bashrc / etc / profile ~ / .bash_profile ~ / .bashrc, etc.). En ese momento, es posible que haya actualizado el entorno de su proceso haciendo cosas como
export PATH="$PATH:~/mybin"
en esos scripts. Ahora, cualquier proceso futuro que ejecute heredará su entorno actual.Ejecutar un comando en lugar de obtener un shell de inicio de sesión significa que el comando es ejecutado por ssh daemon y heredará el entorno del proceso ssh daemon ... que probablemente sea diferente de su entorno como usuario conectado.
La página de manual para claves autorizadas cubre lo que sucede después de la autenticación. En cuanto al medio ambiente:
Entonces, el lugar apropiado para configurar el entorno para el proceso es
~/.ssh/environment
dónde~
está el directorio de inicio para el usuario que está autenticado para ejecutar el comando. También debe verificar su sshd_config para asegurarse de que PermitUserEnvironment esté permitido.~/.ssh/environment
el formato también se especifica en la página del manual, por supuesto.Una forma alternativa de especificar el entorno sin utilizar el método mencionado anteriormente es utilizar la
environment="NAME=value"
opción en el archivo autorizado_claves. Consulte la página del manual que he vinculado anteriormente para obtener más detalles.fuente
Without knowing exactly how you have setup your deploy script to run
: en mi pregunta al principio, hay un enlace, cómo lo configuré (usando~/.ssh/authorized_keys
. Gracias por el consejo con el comando de actualización, lo probé, pero desafortunadamente sin ninguna diferencia. Sin embargo, investigaré esto y probaré diferentes shells . Acepte un +1 para esa idea.