Eu quero usar o script .sh para a implantação do meu aplicativo. Esse script está no meu servidor (Ubuntu 15.10 Server), marcado como executável. O acesso a esse script é feito por meio do ssh, usando este tutorial, eu configurei o login ssh, que executa esse script. Então basicamente eu apenas chamo ssh [email protected] someArguments e ele executa meu script com someArguments como parâmetros. O usuário deployer tem uid = 0, então é basicamente root (isso será alterado no futuro, eu o configurei apenas para eliminar problemas de permissões até que funcione bem).
E aqui é onde as coisas ficam complicadas. O script relata /usr/bin/env: php: No such file or directory no comando /bin/composer install (usando Composer ). As coisas são mais estranhas quanto mais eu olho nesse script. Antes dessa linha, também é chamado de /bin/composer self-update e /bin/composer -V , que são executados corretamente e exibem a saída correta.
Eu verifiquei as seguintes coisas:
/usr/bin/env php -v exibe a versão correta do PHP (igual a /usr/bin/php -v ) whereis php exibe php: /usr/bin/php /usr/local/bin/php /usr/share/man/man1/php.1.gz
php5-cli package está instalado e a versão mais recente $PATH contém /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
which env exibe /usr/bin/env
Eu também tentei seguir as coisas:
bash deploy.sh em root (já que é igual a esse usuário) - funciona perfeitamente sem erros Então, isso me parece muito específico, porque esse comando não funciona. Passei 12 horas debugando e estou sem ideias aqui.
PS: Erro semelhante ( /usr/bin/env: node: No such file or directory ) ocorre quando há bower install (usando Bower ), mas não ao executar npm install (usando NPM ).
Certifique-se de que os términos de linha e / ou espaços invisíveis não estejam causando o problema.
Remova os espaços na primeira linha do script e insira novos, certificando-se de não segurar a tecla CTRL enquanto pressiona o espaço.
Além disso, verifique se você não tem finais de linha do DOS (CR + LF). Consulte o link para obter detalhes.
O caminho mais fácil .... altera o shell do usuário como o script.
Before:
deploy:x:0:0:,,,:/root:/bin/bash
After:
deploy:x:0:0:,,,:/root:/scripts/deploy.sh
Exemplo de script (verifique se o bit de execução está definido chmod + x)
#!/bin/bash
PATH=$PATH:/moo etc...
moo.sh
Trabalhatodahora!Vocêdeveatésercapazdeusaroscriptparasolucionarproblemas/depurarquaisquervariáveisenvquevocêpossaacharquesejamdesconfiguradas,etc...tambémosargumentosdemanipulaçãosendopassadosparaosshtambémfuncionarão.
Nota:SuaMelhorPráticaparasempreTOTALMENTEQUALIFICARoscaminhosparaquaisquerscripts,executáveis,etc.Acimaéapenasumexemploquepermitequeocaminhopadrãosejaconfiguradoparachamarmoo.shdentrodapastamoo;)
Issofoifácil..Obrigadoporpostar..
Referência:
O comando env examinará o $PATH de um usuário para localizar o primeiro executável do nome fornecido. Portanto, /usr/bin/env php procurará um arquivo executável chamado php em qualquer um dos diretórios no $PATH do usuário que o está executando.
No seu caso, é quase certo que, ao executar um comando sobre ssh , você não inicia um shell completo e realmente não lê os arquivos de inicialização do seu shell. Você pode verificar isso executando este comando (observe as aspas simples):
ssh [email protected] 'echo $PATH'
E comparando a saída com o que você obtém se você ssh [email protected] e então executar echo $PATH . No meu sistema. por exemplo:
$ 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
Portanto, o $PATH ao qual seu script tem acesso quando executado com ssh [email protected] não é o mesmo de quando você faz login para testá-lo.
Em qualquer caso, a solução simples é usar o caminho completo para o interpretador em vez de env . Tanto env quanto os caminhos completos têm seus benefícios e desvantagens , mas, nesse caso, o caminho é mais seguro:
#!/usr/bin/php
É possível que bash precise de um reset para sua tabela de hash?
Se assim for, você pode tentar adicionar hash -r em algum lugar em seu script, o que força o shell a procurar $PATH novamente, em vez de depender de informações (possivelmente desatualizadas) da tabela de hash.
Quando necessário, hash também pode habilitar o shell a lembrar caminhos para executáveis instalados em locais não padrão usando a opção -p ou esquecer caminhos com a opção -d .
Fontes:
Parece que talvez você precise adicionar o php ao seu caminho. Experimente:
vim ~/.bashrc
PATH=$PATH:/usr/local/bin/php
export PATH
Você também pode querer verificar onde o seu php mora para ter certeza de que o caminho está correto. Experimente:
which php
É claro que você tem um problema de caminho já que seu script de implementação não consegue encontrar coisas que estão definitivamente no caminho quando você faz um login normal do ssh.
A primeira coisa a fazer para confirmar que você tem um problema no PATH é atualizar o script de implantação para registrar a saída de env ou pelo menos echo $PATH . Eu estou supondo que a forma como seu script de implantação é chamado, $ PATH não está definido como seria de esperar. Esta saída de depuração confirmará / negará minha teoria.
Eu olhei para o tutorial que você seguiu. Você provavelmente deve certificar-se de atualizar o command= para command="/bin/sh /path/to/your/script..." se ainda não tiver certeza de que seu script é executado pelo shell correto.
Se você tiver um problema PATH, uma correção rápida / suja é apenas definir explicitamente o PATH no início do seu script de implantação.
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
No linux, quando os comandos são executados, eles herdam o ambiente do processo pai.
Quando você faz login como usuário normal via SSH, há coisas que acontecem (como executar / etc / bashrc / etc / profile ~ / .bash_profile ~ / .bashrc etc). Nesse ponto, você pode ter atualizado o ambiente do seu processo fazendo coisas como export PATH="$PATH:~/mybin" nesses scripts. Agora, qualquer processo futuro que você execute herdará seu ambiente atual.
Executar um comando em vez de obter um shell de login significa que o comando é executado pelo daemon ssh e herdará o ambiente do processo do daemon ssh ... que provavelmente é diferente de seu ambiente como um usuário conectado.
A man page para chaves autorizadas aborda o que acontece após a autenticação. Em relação ao meio ambiente:
- Reads the file ~/.ssh/environment, if it exists, and users are allowed to change their environment. See the PermitUserEnvironment option in sshd_config(5).
Portanto, o local apropriado para configurar o ambiente para o processo é em ~/.ssh/environment , em que ~ é o diretório inicial do usuário autenticado para executar o comando. Você também precisa verificar seu sshd_config para certificar-se de que PermitUserEnvironment é permitido.
~/.ssh/environment format também é especificado na página man do curso.
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.
Uma maneira alternativa de especificar o ambiente sem usar o método mencionado acima é usar a opção environment="NAME=value" no arquivo authorized_keys. Veja a página de manual que eu relacionei acima para detalhes.