Я хочу использовать .sh скрипт для развертывания моего приложения. Этот скрипт находится на моем домашнем сервере (Ubuntu 15.10 Server), помечен как исполняемый. Доступ к этому сценарию осуществляется через ssh, с помощью этого руководства я настроил ssh login, который запускает этот сценарий. В общем, я просто звоню, ssh deployer@XXX.com someArguments
и он запускает мой сценарий с someArguments
параметрами. У пользователя deployer
uid = 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 ).
sh deploy
вместоbash deploy
(возможно, какой-то башизм). Как вы проверили « следующие вещи »? Я рекомендую проверить их в сценарии, чтобы вы могли обнаружить возможные переопределения и санации envs.sh deploy
иbash deploy
оба дают одинаковые результаты/usr/bin/env > environment.txt
Ответы:
Убедитесь, что окончания строк и / или невидимые пробелы не вызывают проблемы.
Удалите пробелы в первой строке скрипта и вставьте новые, следя за тем, чтобы не удерживать CTRL при нажатии пробела.
Кроме того, убедитесь, что у вас нет окончания строки DOS (CR + LF). См. Https://stackoverflow.com/questions/82726/convert-dos-line-endings-to-linux-line-endings-in-vim для получения подробной информации.
источник
Самый простой способ .... изменить пользовательскую оболочку как скрипт.
/ И т.д. / пароль
Пример сценария (убедитесь, что бит выполнения установлен в chmod + x)
/scripts/deploy.sh
Работает каждый раз! Вы даже должны иметь возможность использовать сценарий для устранения неполадок / отладки любых переменных env, которые, по вашему мнению, не установлены и т. Д. ... также будут работать аргументы обработки, передаваемые в ssh.
Примечание. Рекомендуется всегда ПОЛНОСТЬЮ КВАЛИФИЦИРОВАТЬ пути для любых сценариев, исполняемых файлов и т. Д. Выше приведен лишь пример, который позволяет задавать путь по умолчанию для вызова moo.sh в папке moo;)
Это было легко .. Спасибо за публикацию ..
Ссылка: / etc / passwd формат
источник
ssh
на сервере, и, по очередиauthorized_keys
, вызывается скрипт, а затем соединение заканчивается. Как мне изменить,authorized_keys
чтобы это работало?Команда
env
просматривает пользователя,$PATH
чтобы найти первый исполняемый файл с заданным именем. Таким образом,/usr/bin/env php
будет искать исполняемый файл, который вызываетсяphp
в любом из каталогов$PATH
пользователя, который его запускает.В вашем случае это почти наверняка, потому что при запуске команды поверх
ssh
вы не запускаете полную оболочку и фактически не читаете файлы инициализации вашей оболочки. Вы можете проверить это, выполнив эту команду (обратите внимание на одинарные кавычки):И сравнивая вывод с тем, что вы получаете, если вы
ssh deployer@XXX.com
и затем запускаетеecho $PATH
. В моей системе. например:Следовательно,
$PATH
доступ к вашему сценарию при запускеssh deployer@XXX.com
не совпадает с тем, когда вы входите в систему для его тестирования.В любом случае, простое решение - использовать полный путь к интерпретатору вместо
env
. Обаenv
пути и полные пути имеют свои преимущества и недостатки, но в этом случае путь безопаснее:источник
composer install
команды, которую я, очевидно, не могу изменить. Также$PATH
все в порядке, как я уже упоминал в своем вопросе, я проверил все вещи, добавив их в скрипт и запустив удаленно через ssh login. Также я не могу проверить,ssh deployer@XXX.com 'echo $PATH'
как вы заявили, так как мой логин ssh ограничен только одним сценарием, но я проверял его, когда добавлял $ PATH к этому сценарию (указано выше). В любом случае, спасибо за ваш ответ и принимаю + 1 для объяснения мнеenv
вещиenv
на самом деле называется внутри композитора. Но это не решает проблему, почему некоторые вызовы композитора проходят, а некоторые нет. Однако я буду дальше исследовать это, изучая его код. Спасибо за ваше времяВозможно ли, что
bash
требуется сброс к своей хэш-таблице?Если это так, вы можете попробовать добавить
hash -r
где-нибудь в своем скрипте, что заставляет оболочку просматривать$PATH
снова, а не полагаться на (возможно, устаревшую) информацию из хеш-таблицы.При необходимости
hash
можно также включить оболочку для запоминания путей к исполняемым файлам, установленным в нестандартных местах, с помощью этой-p
опции или забыть пути с помощью этой-d
опции.Источники:
https://unix.stackexchange.com/a/86017/121251
https://stackoverflow.com/a/22543353/2146843
источник
Похоже, может быть, вам нужно добавить php к вашему пути. Пытаться:
Вы также можете проверить, где живет ваш php, чтобы убедиться, что путь там правильный. Пытаться:
источник
php -v
выводит правильную версию PHP иcomposer --version
выводит версию композитора. Как я уже сказал, проблема только в одной команде.Ясно, что у вас есть проблема с путем, так как ваш скрипт развертывания не может найти вещи, которые определенно находятся на пути, когда вы выполняете обычную регистрацию SSH.
Первое, что нужно сделать, чтобы подтвердить, что у вас есть проблема с PATH, - обновить скрипт развертывания, чтобы записать выходные данные
env
или хотя быecho $PATH
. Я предполагаю, что, как называется ваш сценарий развертывания, $ PATH установлен не так, как вы ожидаете. Этот отладочный вывод подтвердит / опровергнет мою теорию.Я посмотрел учебник, которым вы следовали. Вы, вероятно, должны убедиться в обновлении,
command=
чтобы быть,command="/bin/sh /path/to/your/script..."
если вы еще не удостоверились, что ваш скрипт запускается правильной оболочкой.Если у вас есть проблема с PATH, быстрое / грязное решение состоит в том, чтобы просто установить PATH в начале сценария развертывания.
Подробное объяснение и дальнейшие варианты ...
В Linux, когда команды выполняются, они наследуют среду своего родительского процесса.
Когда вы входите в систему как обычный пользователь через SSH, случаются некоторые вещи (например, запуск / etc / bashrc / etc / profile ~ / .bash_profile ~ / .bashrc и т. Д.). В этот момент вы, возможно, обновили среду своего процесса, выполнив действия, подобные
export PATH="$PATH:~/mybin"
тем, что описаны в этих сценариях. Теперь все будущие процессы, которые вы запускаете, унаследуют вашу текущую среду.Выполнение команды вместо получения оболочки входа означает, что команда запускается демоном ssh и будет наследовать среду процесса демона ssh ... которая, вероятно, отличается от вашей среды вошедшего в систему пользователя.
Страница man для авторизованных ключей описывает, что происходит после аутентификации. Относительно окружающей среды:
Таким образом, подходящее место для настройки среды для процесса находится в том месте,
~/.ssh/environment
где~
находится домашний каталог пользователя, который прошел проверку подлинности для запуска команды. Вам также необходимо проверить ваш sshd_config, чтобы убедиться, что PermitUserEnvironment разрешен.~/.ssh/environment
формат также указан в справочной странице, конечно.Альтернативный способ указать среду без использования вышеупомянутого метода - использовать
environment="NAME=value"
опцию в файле авторизованных ключах. Смотрите man-страницу, на которую я ссылался выше,источник
Without knowing exactly how you have setup your deploy script to run
: в моем вопросе в начале есть ссылка, как я ее настроил (используя~/.ssh/authorized_keys
. Спасибо за подсказку с командой обновления, я попробовал, но, к сожалению, без разницы. Однако я буду дальше исследовать это и пробовать различные оболочки Пожалуйста, примите +1 за эту идею.