O que estou tentando escrever é um script de shell que fará o backup de um site e de todos os bancos de dados MySQL que o suportam. Eu encontrei exemplos em toda a rede, mas quando eu executar o script no bash em uma sessão SSH preso, ele falhará. Se eu digitar os comandos diretamente na sessão SSH, eles funcionam bem.
#!/bin/sh
DB1="first_db"
THEDATE=$(date +"%Y-%m-%d")
THEUSER=user
THEDBPW=password
mysqldump -u $THEDBUSER -p$THEDBPW $DB1 > dbbackup_$DB1_$THEDATE.sql
tar -czf sitebackup_website_$THEDATE.tar /home/website/public_html
gzip sitebackup_website_$THEDATE.tar
Esse script reside no servidor da Web, portanto, para fins de teste, eu SSH no servidor, cd no diretório e execute bash backup.sh . mysqldump não está se conectando, parecendo falhar ao passar a senha (ela retorna um relatório de erro 'usando a senha: NO'). Em seguida, o comando tar falhará, informando que não é possível declarar /home/website/public_html com 'nenhum arquivo ou diretório'. tar relata que está saindo com status de erro devido a erros anteriores.
O que estou perdendo aqui?
Verifique se o script para fins de linha do Windows está efetuando login no servidor e executando
cat -v /path/to/script
Se a linha terminar com ^M , esse é o problema.
Você pode corrigir um arquivo com finais de linha quebrados executando
dos2unix /path/to/script
Se o dos2unix não existir no servidor, você pode usar o sed, assim:
sed -i 's/\r$//' /path/to/script
Você atribuiu o nome de usuário à variável THEUSER , mas o comando mysqldump está usando a variável THEDBUSER .
tardir=$PWD ; cd /home/website/public_html &&
tar -czf "$tardir"/sitebackup_complete-office_"$THEDATE.tar"
ou apenas:
tar -C/home/website/public_html -czf \
sitebackup_complete-office_"$THEDATE.tar"
Em geral, muitos tars deixarão de funcionar com caminhos absolutos, a menos que explicitamente instruído para fazê-lo.
By default, GNU tar drops a leading
/on input or output,and complains about file names containing a..component. This option turns off this behavior.
É perfeitamente possível que os comandos ssh's estejam resolvendo caminhos antecipadamente, dependendo da entrega e da cotação do comando. O mesmo é relevante para a expansão das variáveis em seus nomes de caminho.
Se eu entendi a descrição do problema corretamente, a principal diferença parece ser a sessão SSH jailed - os processos executados dentro da sessão presa não podem ser vistos fora do diretório de jail (geralmente sua residência). É por isso que você não tem problemas em sessões não encarceradas. Você também pode dar uma olhada na entrada da Wikipedia Jail para obter mais detalhes.