Я хочу использовать .sh скрипт для развертывания моего приложения. Этот скрипт находится на моем домашнем сервере (Ubuntu 15.10 Server), помечен как исполняемый. Доступ к этому сценарию осуществляется через ssh, с помощью этого руководства я настроил ssh login, который запускает этот сценарий. В общем, я просто звоню, ssh deployer@XXX.com someArgumentsи он запускает мой сценарий с someArgumentsпараметрами. У пользователя deployeruid = 0, поэтому его в основном root(это будет изменено в будущем, я установил его только для устранения проблем с разрешениями, пока он не будет работать нормально).

И вот тут все становится сложнее. Скрипт сообщает /usr/bin/env: php: No such file or directoryпо команде /bin/composer install(используя Composer ). Чем страннее я смотрю на этот сценарий, тем страннее. Перед этой строкой также вызывается /bin/composer self-updateи /bin/composer -V, который работает правильно и отображает правильный вывод.

Я проверил следующие вещи:

• /usr/bin/env php -vотображает правильную версию PHP (так же, как /usr/bin/php -v)
• whereis php дисплеи php: /usr/bin/php /usr/local/bin/php /usr/share/man/man1/php.1.gz
• php5-cli пакет установлен и самая новая версия
• $PATH содержит /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
• which env дисплеи /usr/bin/env

Я также попробовал следующие вещи:

• запуск скрипта напрямую как bash deploy.shпод root (так как он такой же, как у этого пользователя) - отлично работает без ошибок
• запуск сбойных команд напрямую - также без ошибок

Так что это кажется мне очень специфическим случаем, почему эта команда не работает. Я потратил 12 часов на его отладку, и у меня нет идей здесь.

PS: Подобная ошибка ( /usr/bin/env: node: No such file or directory) возникает, когда есть bower install(с помощью Bower ), но не при работе npm install(с использованием NPM ).

Убедитесь, что окончания строк и / или невидимые пробелы не вызывают проблемы.

Удалите пробелы в первой строке скрипта и вставьте новые, следя за тем, чтобы не удерживать CTRL при нажатии пробела.

Кроме того, убедитесь, что у вас нет окончания строки DOS (CR + LF). См. Https://stackoverflow.com/questions/82726/convert-dos-line-endings-to-linux-line-endings-in-vim для получения подробной информации.

Самый простой способ .... изменить пользовательскую оболочку как скрипт.

/ И т.д. / пароль

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

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

Пример сценария (убедитесь, что бит выполнения установлен в chmod + x)

/scripts/deploy.sh

#!/bin/bash 
PATH=$PATH:/moo etc...
moo.sh

Работает каждый раз! Вы даже должны иметь возможность использовать сценарий для устранения неполадок / отладки любых переменных env, которые, по вашему мнению, не установлены и т. Д. ... также будут работать аргументы обработки, передаваемые в ssh.

Примечание. Рекомендуется всегда ПОЛНОСТЬЮ КВАЛИФИЦИРОВАТЬ пути для любых сценариев, исполняемых файлов и т. Д. Выше приведен лишь пример, который позволяет задавать путь по умолчанию для вызова moo.sh в папке moo;)

Это было легко .. Спасибо за публикацию ..

Ссылка: / etc / passwd формат

Команда envпросматривает пользователя, $PATHчтобы найти первый исполняемый файл с заданным именем. Таким образом, /usr/bin/env phpбудет искать исполняемый файл, который вызывается phpв любом из каталогов $PATHпользователя, который его запускает.

В вашем случае это почти наверняка, потому что при запуске команды поверх sshвы не запускаете полную оболочку и фактически не читаете файлы инициализации вашей оболочки. Вы можете проверить это, выполнив эту команду (обратите внимание на одинарные кавычки):

ssh deployer@XXX.com 'echo $PATH'

И сравнивая вывод с тем, что вы получаете, если вы ssh deployer@XXX.comи затем запускаете echo $PATH. В моей системе. например:

$ 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

Следовательно, $PATHдоступ к вашему сценарию при запуске ssh deployer@XXX.comне совпадает с тем, когда вы входите в систему для его тестирования.

В любом случае, простое решение - использовать полный путь к интерпретатору вместо env. Оба envпути и полные пути имеют свои преимущества и недостатки, но в этом случае путь безопаснее:

#!/usr/bin/php

Возможно ли, что bashтребуется сброс к своей хэш-таблице?

Если это так, вы можете попробовать добавить hash -rгде-нибудь в своем скрипте, что заставляет оболочку просматривать $PATHснова, а не полагаться на (возможно, устаревшую) информацию из хеш-таблицы.

При необходимости hashможно также включить оболочку для запоминания путей к исполняемым файлам, установленным в нестандартных местах, с помощью этой -pопции или забыть пути с помощью этой -dопции.

Источники:

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

Похоже, может быть, вам нужно добавить php к вашему пути. Пытаться:

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

Вы также можете проверить, где живет ваш php, чтобы убедиться, что путь там правильный. Пытаться:

which php

Ясно, что у вас есть проблема с путем, так как ваш скрипт развертывания не может найти вещи, которые определенно находятся на пути, когда вы выполняете обычную регистрацию SSH.

Первое, что нужно сделать, чтобы подтвердить, что у вас есть проблема с PATH, - обновить скрипт развертывания, чтобы записать выходные данные envили хотя бы echo $PATH. Я предполагаю, что, как называется ваш сценарий развертывания, $ PATH установлен не так, как вы ожидаете. Этот отладочный вывод подтвердит / опровергнет мою теорию.

Я посмотрел учебник, которым вы следовали. Вы, вероятно, должны убедиться в обновлении, command=чтобы быть, command="/bin/sh /path/to/your/script..."если вы еще не удостоверились, что ваш скрипт запускается правильной оболочкой.

Если у вас есть проблема с PATH, быстрое / грязное решение состоит в том, чтобы просто установить PATH в начале сценария развертывания.

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

Подробное объяснение и дальнейшие варианты ...

В Linux, когда команды выполняются, они наследуют среду своего родительского процесса.

Когда вы входите в систему как обычный пользователь через SSH, случаются некоторые вещи (например, запуск / etc / bashrc / etc / profile ~ / .bash_profile ~ / .bashrc и т. Д.). В этот момент вы, возможно, обновили среду своего процесса, выполнив действия, подобные export PATH="$PATH:~/mybin"тем, что описаны в этих сценариях. Теперь все будущие процессы, которые вы запускаете, унаследуют вашу текущую среду.

Выполнение команды вместо получения оболочки входа означает, что команда запускается демоном ssh и будет наследовать среду процесса демона ssh ... которая, вероятно, отличается от вашей среды вошедшего в систему пользователя.

Страница man для авторизованных ключей описывает, что происходит после аутентификации. Относительно окружающей среды:

6. Читает файл ~ / .ssh / environment, если он существует, и пользователям разрешено изменять свою среду. Смотрите параметр PermitUserEnvironment в sshd_config (5).

Таким образом, подходящее место для настройки среды для процесса находится в том месте, ~/.ssh/environmentгде ~находится домашний каталог пользователя, который прошел проверку подлинности для запуска команды. Вам также необходимо проверить ваш sshd_config, чтобы убедиться, что PermitUserEnvironment разрешен.

~/.ssh/environment формат также указан в справочной странице, конечно.

         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.

Альтернативный способ указать среду без использования вышеупомянутого метода - использовать environment="NAME=value"опцию в файле авторизованных ключах. Смотрите man-страницу, на которую я ссылался выше,