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 deployer@XXX.com someArgumentsy ejecuta mi script con someArgumentsparámetros. El usuario deployertiene 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 directoryen 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-updatey /bin/composer -V, que se ejecuta correctamente y muestra la salida correcta.

He comprobado las siguientes cosas:

• /usr/bin/env php -vmuestra la versión correcta de PHP (igual que /usr/bin/php -v)
• whereis php muestra php: /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.shroot (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 directoryproduce un error similar ( ) cuando hay bower install(usando Bower ), pero no cuando se ejecuta npm install(usando NPM ).

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.

La forma más fácil ... cambia el shell del usuario como el script.

/ etc / passwd

Before:
deploy:x:0:0:,,,:/root:/bin/bash

After:
deploy:x:0:0:,,,:/root:/scripts/deploy.sh

Script de ejemplo (asegúrese de que el bit de ejecución esté configurado chmod + x)

/scripts/deploy.sh

#!/bin/bash 
PATH=$PATH:/moo etc...
moo.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

El envcomando buscará a través de un usuario $PATHpara encontrar el primer ejecutable del nombre dado. Por lo tanto, /usr/bin/env phpbuscará un archivo ejecutable llamado phpen cualquiera de los directorios $PATHdel 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):

ssh deployer@XXX.com 'echo $PATH'

Y comparando la salida con lo que obtienes si tú ssh deployer@XXX.comy luego corres echo $PATH. En mi sistema por ejemplo:

$ echo $PATH
/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:

$ ssh localhost 'echo $PATH'
/usr/bin:/bin:/usr/sbin:/sbin

Por lo tanto, el $PATHacceso al script al ejecutarlo ssh deployer@XXX.comno 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. Ambas envy las rutas completas tienen sus ventajas e inconvenientes , pero, en este caso, la ruta es más segura:

#!/usr/bin/php

¿Es posible que bashnecesite restablecer su tabla hash?

Si es así, puede intentar agregar hash -ren algún lugar de su script, lo que obliga al shell a revisar $PATHnuevamente en lugar de confiar en la información (posiblemente desactualizada) de la tabla hash.

Cuando sea necesario, hashtambién puede habilitar el shell para recordar rutas a ejecutables instalados en ubicaciones no estándar utilizando la -popción, u olvidar rutas con la -dopción.

Fuentes:

https://unix.stackexchange.com/a/86017/121251
https://stackoverflow.com/a/22543353/2146843

Parece que tal vez necesites agregar php a tu camino. Tratar:

vim ~/.bashrc
PATH=$PATH:/usr/local/bin/php
export PATH

También es posible que desee verificar dónde vive su php para asegurarse de que la ruta allí sea correcta. Tratar:

which php

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, envo al menos echo $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 ser command="/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.

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"

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:

6. Lee el archivo ~ / .ssh / environment, si existe, y los usuarios pueden cambiar su entorno. Vea la opción PermitUserEnvironment en sshd_config (5).

Entonces, el lugar apropiado para configurar el entorno para el proceso es ~/.ssh/environmentdó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.

         This file is read into the environment at login (if it exists).
         It can only contain empty lines, comment lines (that start with
         '#'), and assignment lines of the form name=value.  The file
         should be writable only by the user; it need not be readable by
         directory becomes accessible.  This file should be writable only
         by the user, and need not be readable by anyone else.

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.