Tentando executar um script simples de backup do AWS CLI. Ele percorre as linhas em um arquivo de inclusão, faz o backup desses caminhos até o S3 e lança a saída em um arquivo de log. Quando executo este comando diretamente, ele é executado sem nenhum erro. Quando eu executo através CRON eu recebo um erro "Não é possível localizar credenciais" no meu log de saída.
O script de shell:
AWS_CONFIG_FILE="~/.aws/config"
while read p; do
/usr/local/bin/aws s3 cp $p s3://PATH/TO/BUCKET --recursive >> /PATH/TO/LOG 2>&1
done </PATH/TO/INCLUDE/include.txt
Eu só adicionei a linha ao arquivo de configuração depois que comecei a ver o erro, pensando que isso poderia consertá-lo (embora eu tenha certeza de que é onde a AWS fica por padrão).
O script de shell está sendo executado como root. Eu posso ver o arquivo de configuração da AWS no local especificado. E tudo parece bom para mim (como eu disse, funciona bem fora do CRON).
Se funciona quando você o executa diretamente, mas não do cron, provavelmente há algo diferente no ambiente. Você pode salvar seu ambiente interativamente fazendo
set | sort > env.interactive
E faça a mesma coisa no seu script
set | sort > /tmp/env.cron
E, em seguida, diff /tmp/env.cron env.interactive e veja o que é importante. Coisas como PATH são as mais prováveis culpadas.
Quando você executa um trabalho a partir do crontab, sua variável de ambiente $HOME é /
O cliente da Amazon procura
~/.aws/config
ou
~/.aws/credentials
Se $HOME = / , o cliente não encontrará esses arquivos
Para fazer isso funcionar, atualize seu script para que ele exporte um diretório pessoal real para $HOME
export HOME=/root
e, em seguida, coloque os arquivos de configuração ou credenciais em
/root/.aws/
Consegui resolver esse problema por meio de seguindo :
export AWS_CONFIG_FILE="/root/.aws/config"
export AWS_ACCESS_KEY_ID=XXXX
export AWS_SECRET_ACCESS_KEY=YYYY
Os binários da ferramenta aws cli são instalados em /usr/local/bin/aws .
O erro que tive foi que o usuário do cron não pôde acessar /usr/local/bin/aws durante a execução; só pode acessar /usr/bin/
O que eu fiz foi criar um link em /usr/bin para aws com o comando abaixo.
root@gateway:~# ln -s /usr/local/bin/aws /usr/bin/aws
Também adicionei algumas alterações no meu script; aqui está uma função de amostra:
starter () {
echo "
==================================================
Starting Instance
==================================================
"
/usr/bin/aws ec2 start-instances --instance-ids $instance --region us-east-1
sleep 30
echo "Assigning IP Address "
/usr/bin/aws ec2 associate-address --instance-id $instance --region us-east-1 --public-ip XX.XX.XX.XX
}
E a entrada do cron:
30 5 * * * sh /usr/local/cron/magentocron.sh
Esse método funcionou para mim.
Coloque este código antes de sua linha de comando para ser executado em crontab -e
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Esta linha no arquivo .bashrc padrão para o usuário impedirá que os shells não interativos obtenham o ambiente completo do usuário (incluindo a variável PATH):
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
Comente a saída de linha para permitir que $HOME/.bashrc seja executado a partir de um contexto não interativo.
Eu também tive que adicionar um comando explícito source ao meu shell script para configurar corretamente o ambiente:
#!/bin/bash
source $HOME/.bashrc
Veja esta resposta para informações adicionais.
Eu sei que não é a solução perfeita, mas que funcionou para mim:
export HOME=/home/user
export AWS_CONFIG_FILE="/home/user/.aws/config"
export AWS_ACCESS_KEY_ID=XXX
export AWS_SECRET_ACCESS_KEY=XXX
Apenas para adicionar algum valor acrescentado, eu estava tendo problemas com a nova versão bash, enquanto eu usava a ferramenta awscli instalada via PIP. Eu descobri que nada funcionará com esta ferramenta com novas versões bash.
Consegui resolver instalando aws-apitools-ec2 , isso pode ser instalado por
yum install -y aws-apitools-ec2
Estou anexando seu guia para mais referências.
Eu tive o mesmo problema, mas depois de remover o redirecionamento stderr da minha entrada cron ( 2>@1 ), vi aws: command not found no log.
Isso ocorre porque o AWS cli foi instalado na pasta base do usuário e eu adicionei uma linha ao .bash_profile do meu usuário para adicionar o caminho cli da AWS ao $PATH . Estranhamente, essa é a maneira que a documentação de instalação da AWS cli solicita que você instale isto. Mas o .bash_profile do usuário não é usado quando o crontab do usuário é executado (pelo menos não no meu ambiente).
Então, tudo o que fiz para consertar isso foi garantir que meu script crontab também tivesse o cli em seu caminho. Então, abaixo do shebang do meu script, agora tenho PATH=~/.local/bin:$PATH .
Para mim, isso funcionou:
#!/bin/bash
HOME=/home/ubuntu
AWS_CONFIG_FILE="/home/ubuntu/.aws/config"
aws ec2 describe-instances #or whatever command you need to use.
O usuário padrão nas instâncias atuais do EC2 é o ubuntu, e a pasta raiz é aquela pasta inicial do usuário. É aí que o aws cli também existe.
Não é o melhor, mas eu tive que fornecer a configuração diretamente no meu script shell / bash antes dos comandos do cliente da AWS. como:
#!/bin/bash
export AWS_ACCESS_KEY_ID=<ZZZ>
export AWS_SECRET_ACCESS_KEY=<AAA>
export AWS_DEFAULT_REGION=<BBB>
aws s3 cp ....