Je souhaite utiliser le script .sh pour le déploiement de mon application. Ce script se trouve sur mon serveur domestique (serveur Ubuntu 15.10), marqué comme exécutable. L'accès à ce script se fait via ssh, en utilisant ce tutoriel, j'ai configuré la connexion ssh, qui exécute ce script. Donc, fondamentalement, je viens d'appeler ssh [email protected] someArguments
et il exécute mon script avec someArguments
comme paramètres. L'utilisateur deployer
a uid = 0, donc c'est fondamentalement root
(cela sera changé à l'avenir, je l'ai défini uniquement pour éliminer les problèmes d'autorisations jusqu'à ce qu'il fonctionne bien).
Et c'est là que les choses deviennent délicates. Le script rend compte /usr/bin/env: php: No such file or directory
à la commande /bin/composer install
(à l'aide de Composer ). Les choses sont d'autant plus bizarres que je regarde ce script. Avant cette ligne, il est également appelé /bin/composer self-update
et /bin/composer -V
, qui s'exécute correctement et affiche une sortie correcte.
J'ai vérifié les choses suivantes:
/usr/bin/env php -v
affiche la version PHP correcte (identique à/usr/bin/php -v
)whereis php
affichephp: /usr/bin/php /usr/local/bin/php /usr/share/man/man1/php.1.gz
php5-cli
le package est installé et la dernière version$PATH
contient/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
which env
affiche/usr/bin/env
J'ai également essayé les choses suivantes:
- exécuter le script directement
bash deploy.sh
sous root (car il est le même que cet utilisateur) - fonctionne parfaitement sans erreurs - exécution directe de commandes défaillantes - également parfaitement sans erreurs
Donc cela me semble être un cas très spécifique, pourquoi cette commande ne fonctionne pas. J'ai passé 12 heures à le déboguer et je suis à court d'idées ici.
PS: une erreur similaire ( /usr/bin/env: node: No such file or directory
) se produit lorsqu'il y a bower install
(à l'aide de Bower ), mais pas lors de l'exécution npm install
(à l'aide de NPM ).
sh deploy
place debash deploy
(peut-être un bashisme). Comment avez-vous vérifié les " choses suivantes "? Je recommande de les vérifier dans le script, afin que vous puissiez découvrir d'éventuels remplacements et désinfections d'envs.sh deploy
et lesbash deploy
deux donnent les mêmes résultats/usr/bin/env > environment.txt
Réponses:
Assurez-vous que les fins de ligne et / ou les espaces invisibles ne causent pas le problème.
Supprimez les espaces dans la première ligne du script et insérez-en de nouveaux, en veillant à ne pas maintenir CTRL enfoncé tout en appuyant sur espace.
Assurez-vous également que vous ne disposez pas de fins de ligne DOS (CR + LF). Voir /programming/82726/convert-dos-line-endings-to-linux-line-endings-in-vim pour plus de détails.
la source
Manière la plus simple .... changer le shell de l'utilisateur en script.
/ etc / passwd
Exemple de script (assurez-vous que le bit d'exécution est défini chmod + x)
/scripts/deploy.sh
Fonctionne à chaque fois! Vous devriez même pouvoir utiliser le script pour dépanner / déboguer toutes les variables env que vous pourriez ressentir comme non définies, etc.
Remarque: Il est recommandé de toujours QUALIFIER ENTIÈREMENT les chemins d'accès pour tous les scripts, exécutables, etc.
C'était facile .. Merci d'avoir posté ..
Référence: format / etc / passwd
la source
ssh
serveur, et par voieauthorized_keys
, le script est appelé, puis la connexion se termine. Comment dois-je modifierauthorized_keys
pour que cela fonctionne?La
env
commande cherchera à travers un utilisateur$PATH
pour trouver le premier exécutable du nom donné. Donc,/usr/bin/env php
recherchera un fichier exécutable appeléphp
dans l'un des répertoires$PATH
de l'utilisateur qui l'exécute.Dans votre cas, c'est presque certainement parce que lorsque vous exécutez une commande
ssh
, vous ne démarrez pas un shell complet et ne lisez pas réellement les fichiers d'initialisation de votre shell. Vous pouvez le vérifier en exécutant cette commande (notez les guillemets simples):Et comparer la sortie à ce que vous obtenez si vous
ssh [email protected]
et puis exécutezecho $PATH
. Sur mon système. par exemple:Par conséquent, le
$PATH
fichier auquel votre script a accès lorsqu'il est exécutéssh [email protected]
n'est pas le même que lorsque vous vous connectez pour le tester.Dans tous les cas, la solution simple consiste à utiliser le chemin complet vers l'interpréteur au lieu de
env
. Les deuxenv
chemins et les chemins complets ont leurs avantages et leurs inconvénients mais, dans ce cas, le chemin est plus sûr:la source
composer install
commande, que je ne peux évidemment pas modifier. Tout$PATH
va bien, comme je l'ai mentionné dans ma question aussi, j'ai vérifié toutes les choses en les ajoutant dans le script et en les exécutant à distance via la connexion ssh. De plus, je ne peux pas vérifier lessh [email protected] 'echo $PATH'
comme vous l'avez déclaré, car ma connexion ssh est limitée à un seul script, mais je ne l'ai pas vérifié quand j'ajoute $ PATH à ce script (indiqué ci-dessus) Quoi qu'il en soit, merci pour votre réponse et acceptez + 1 pour m'avoir expliqué laenv
choseenv
est en fait appelé à l'intérieur du compositeur. Mais cela ne résout pas le problème, pourquoi certains appels de compositeur passent, d'autres non. Cependant, j'examinerai plus avant cela en examinant son code. Merci pour votre tempsEst-il possible d'avoir
bash
besoin d'une réinitialisation de sa table de hachage?Si c'est le cas, vous pouvez essayer d'ajouter
hash -r
quelque part dans votre script, ce qui oblige le shell à parcourir à$PATH
nouveau plutôt que de s'appuyer sur des informations (éventuellement obsolètes) de la table de hachage.Si nécessaire,
hash
peut également permettre au shell de mémoriser les chemins d'accès aux exécutables installés dans des emplacements non standard à l'aide de l'-p
option, ou d'oublier les chemins d'accès avec l'-d
option.Sources:
https://unix.stackexchange.com/a/86017/121251
https://stackoverflow.com/a/22543353/2146843
la source
On dirait que vous devez peut-être ajouter du php à votre chemin. Essayer:
Vous pouvez également vérifier où réside votre php pour vous assurer que le chemin y est correct. Essayer:
la source
php -v
sorties de la version correcte de PHP et lescomposer --version
sorties de la version du compositeur. Comme je l'ai dit, le problème est dans une seule commande.Il est clair que vous avez un problème de chemin, car votre script de déploiement ne peut pas trouver les éléments qui se trouvent définitivement sur le chemin lorsque vous effectuez une connexion ssh normale.
La première chose à faire pour confirmer que vous avez un problème avec PATH est de mettre à jour votre script de déploiement pour enregistrer la sortie de
env
ou au moinsecho $PATH
. Je suppose que la façon dont votre script de déploiement est appelé, $ PATH n'est pas défini comme vous vous y attendez. Cette sortie de débogage confirmera / infirmera ma théorie.J'ai regardé le tutoriel que vous avez suivi. Vous devriez probablement vous assurer lors de la mise à jour de l'
command=
êtrecommand="/bin/sh /path/to/your/script..."
si vous ne l'avez pas déjà fait pour vous assurer que votre script est exécuté par le bon shell.Si vous avez un problème avec PATH, une solution rapide / sale consiste simplement à définir explicitement PATH au début de votre script de déploiement.
Explication détaillée et autres options ...
Sous Linux, lorsque les commandes sont exécutées, elles héritent de l'environnement de leur processus parent.
Lorsque vous vous connectez en tant qu'utilisateur normal via SSH, il se passe des choses (comme exécuter / etc / bashrc / etc / profile ~ / .bash_profile ~ / .bashrc etc.). À ce stade, vous avez peut-être mis à jour l'environnement de votre processus en faisant des choses comme
export PATH="$PATH:~/mybin"
dans ces scripts. Désormais, tous les futurs processus que vous exécuterez hériteront de votre environnement actuel.L'exécution d'une commande au lieu d'obtenir un shell de connexion signifie que la commande est exécutée par le démon ssh et héritera de l'environnement du processus du démon ssh ... qui est probablement différent de votre environnement en tant qu'utilisateur connecté.
La page de manuel pour les clés autorisées couvre ce qui se passe après l'authentification. Concernant l'environnement:
Donc , l'endroit approprié à l' environnement de configuration pour le processus est en
~/.ssh/environment
où~
est le répertoire personnel de l'utilisateur qui est authentifié pour exécuter la commande. Vous devez également vérifier votre sshd_config pour vous assurer que PermitUserEnvironment est autorisé.~/.ssh/environment
le format est également spécifié dans la page de manuel bien sûr.Une autre façon de spécifier l'environnement sans utiliser la méthode mentionnée ci-dessus consiste à utiliser l'
environment="NAME=value"
option dans le fichier authorized_keys. Voir la page de manuel que j'ai liée ci-dessus pour plus de détails.la source
Without knowing exactly how you have setup your deploy script to run
: dans ma question au début, il y a un lien, comment je l'ai mis en place (en utilisant~/.ssh/authorized_keys
. Merci pour le conseil avec la commande de mise à jour, je l'ai essayé, mais malheureusement sans aucune différence. Veuillez accepter un +1 pour cette idée