Você pode querer tentar adicionar
</dev/null
no final dos comandos ofensivos, apenas no caso de, de alguma forma, os comandos precisarem de entrada.
Eu tenho um script de shell simples que:
Ambos os servidores são configurados com login sem senha do SSH por meio de chave pública.
A execução do script na linha de comando funciona bem. Executá-lo do servidor a partir de um comando shell_exec do PHP executará o script, mas os comandos ssh e scp não parecem ser executados, ou pelo menos não produzem nada, mesmo se eu usar um sinalizador -v.
Aqui está a função PHP que chama o script de shell:
function mobi_watermark($userid, $email, $epubpath)
{
$outpath = "/tmp/epub$userid/"; # the book gets marked for each user, store each epub under a unique work folder to avoid collision
shell_exec("chmod -R 777 ".$outpath); # web server creates files under user "nobody".
shell_exec("del.sh"); # deletes old files if they exist
shell_exec("rep.sh $userid $email $epubpath"); # creates the initial .epub and tmp dir
shell_exec("chmod -R 777 ".$outpath);
shell_exec("kindle.sh $outpath"); # this is the mobi conversion, where the problem is
$this->mobi_ufa_download('ufa-187.mobi',$outpath);
}
E aqui está o script de shell com os comandos com falha: [kindle.sh]
#!/usr/local/bin/bash
# uses the same /tmp$userid path as the other scripts, but on the remote server
TMPPATH=$1
cd $TMPPATH
# create remote dir
ssh -v user@server 'mkdir -v '$TMPPATH
# copy the source epub file to remote
scp -v $TMPPATHfile-name.epub user@server:$TMPPATH
# perform the conversion and copy the .mobi result back to originating server
/usr/bin/ssh -v user@server 'cd '$TMPPATH'; /home/username/kindlegen/kindlegen ./file-name.epub; scp -v file-name.mobi user@originating-server:'$TMPPATH';rm -rf '$TMPPATH
Se eu executar esta série de comandos a partir de um arquivo de script ou como comandos individuais da linha de comando, tudo funciona perfeitamente.
Quando executado através do script php, eu posso ver a saída do script se eu decidir ecoar comandos de teste, e o scp reportará um erro se eu quebrar o nome do arquivo fonte, mas nada acontece para os comandos scp ou ssh se estiverem corretos . Não há nem mesmo nenhuma saída de depuração detalhada do sinalizador -v.
Eu devo estar perdendo algo óbvio? Eu estou supondo que é porque o PHP está usando o usuário 'nobody' que o SSH não gosta. Existe uma maneira de contornar isso, se esse é o problema?
Você pode querer tentar adicionar
</dev/null
no final dos comandos ofensivos, apenas no caso de, de alguma forma, os comandos precisarem de entrada.
Onde a chave ssh privada é armazenada, no arquivo ~ / .ssh / id _... do usuário você executa o comando como?
Se sim, o apache não está sendo executado como seu usuário. O Apache precisa ter acesso a uma cópia da chave ssh. Você também pode adicionar o -i aos seus comandos ssh e scp para que ele não precise existir no diretório inicial do apache.
A função shell_exec () provavelmente fornece algumas informações que você ignora por não coletando. Experimente
$info=shell_exec("kindle.sh $outpath");
echo "<pre>$output</pre>";
é o que eu faria para começar a depurar este problema.
Editar:
Configurar os privs em .ssh e id_rsa em 777 causará grandes problemas, já que o ssh se recusa a funcionar se eles forem muito permissivos. Ajuste-os de volta para 700 e 600, respectivamente.
Eu não entendo por que você não está vendo nada voltar tente
$info=shell_exec("kindle.sh 2>&1 $outpath");
echo "<pre>$output</pre>";
O que deve forçar o stderr a sair também.
Quando me deparo com problemas ao executar scripts externos a partir de processos httpd e php, eu tento executar manualmente sob o mesmo usuário que o processo httpd é executado.
su nobody
É uma probabilidade muito alta que o usuário ninguem tenha um conjunto de shell, você precisará ativar um shell para su .