Не удается запустить AWS CLI из CRON (учетные данные)

Попытка запустить простой скрипт резервного копирования CLI AWS. Он перебирает строки во включаемом файле, копирует эти пути до S3 и выводит выходные данные в файл журнала. Когда я запускаю эту команду напрямую, она запускается без ошибок. Когда я запускаю его через CRON, в моем выходном журнале появляется ошибка «Не удается найти учетные данные».

Сценарий оболочки:

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

Я только добавил строку в файл конфигурации после того, как начал видеть ошибку, думая, что это может исправить ее (даже если я почти уверен, что именно там AWS смотрит по умолчанию).

Сценарий оболочки работает от имени пользователя root. Я вижу конфигурационный файл AWS в указанном месте. И все это выглядит хорошо для меня (как я уже сказал, это прекрасно работает вне CRON).

Если он работает, когда вы запускаете его напрямую, но не из cron, возможно, в среде что-то другое. Вы можете сохранить свою среду в интерактивном режиме, выполнив

set | sort > env.interactive

И сделать то же самое в вашем сценарии

set | sort > /tmp/env.cron

А потом diff /tmp/env.cron env.interactiveи посмотрим, что имеет значение. Такие вещи, как PATHнаиболее вероятные виновники.

Когда вы запускаете задание из crontab, ваша $HOMEпеременная окружения/

Клиент Amazon ищет либо

~/.aws/config

или

~/.aws/credentials

Если $HOME= /, то клиент не найдет эти файлы

Чтобы заставить его работать, обновите ваш скрипт так, чтобы он экспортировал фактический домашний каталог для $HOME

export HOME=/root

а затем положить файлы конфигурации или учетные данные в

/root/.aws/

Я смог решить эту проблему с помощью следующего :

export AWS_CONFIG_FILE="/root/.aws/config"
export AWS_ACCESS_KEY_ID=XXXX
export AWS_SECRET_ACCESS_KEY=YYYY

Поместите этот код перед вашей командной строкой в ​​crontab -e

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Двоичные файлы инструмента aws cli установлены в /usr/local/bin/aws.

У меня была ошибка, что пользователь cron не мог получить доступ /usr/local/bin/awsво время работы; он может получить доступ только/usr/bin/

Я создал ссылку /usr/binдля aws с помощью команды ниже.

root@gateway:~# ln -s /usr/local/bin/aws /usr/bin/aws

Я также добавил некоторые изменения в свой скрипт; вот пример функции:

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

}

И запись cron:

30 5 * * * sh /usr/local/cron/magentocron.sh

Этот метод работал для меня.

Эта строка в .bashrcфайле по умолчанию для пользователя не позволит неинтерактивным оболочкам получить полную пользовательскую среду (включая переменную PATH):

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

Закомментируйте строку так, чтобы $HOME/.bashrcее можно было выполнить из неинтерактивного контекста.

Я также должен был добавить явное source команду в мой скрипт оболочки, чтобы правильно настроить среду:

#!/bin/bash
source $HOME/.bashrc

Смотрите этот ответ для дополнительной информации.

Все мы знаем, что переменная пути среды $ PATH имеет местоположение двоичных файлов. $ PATH Crontab может не иметь местоположения awscli.

Что вы можете сделать, это найти путь к двоичному файлу awscli.

# which aws
/usr/local/bin/aws

и добавьте путь в $ PATH crontab, добавив строку ниже в начале вашего скрипта (после shebang).

PATH=$PATH:/usr/local/bin/

Это сработало для меня!

Я знаю, что это не идеальное решение, но это сработало для меня:

export HOME=/home/user
export AWS_CONFIG_FILE="/home/user/.aws/config"
export AWS_ACCESS_KEY_ID=XXX
export AWS_SECRET_ACCESS_KEY=XXX

Просто чтобы добавить добавленную стоимость, у меня возникли проблемы с новой версией Bash при использовании awscli инструмента, установленного через PIP, я обнаружил, что ничто не будет работать с этим инструментом с новыми версиями bash.

Я смог решить, установив aws-apitools-ec2это можно установить

yum install -y aws-apitools-ec2 

Я прилагаю его руководство для дополнительной справки.

http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/ec2-clt.pdf

У меня была та же проблема, но после удаления перенаправления stderr из моей записи cron ( 2>@1) я увидел aws: command not foundв журнале.

Это связано с тем, что AWS cli был установлен в домашней папке пользователя, и я добавил строку в моего пользователя, .bash_profileчтобы добавить путь к AWS cli в $PATH. Как ни странно, именно так в документации по установке AWS cli указана установка . Но пользователь .bash_profileне привыкает, когда выполняется пользовательский crontab (по крайней мере, в любом случае, в моем окружении).

Поэтому все, что я сделал, чтобы это исправить, - убедился, что в моем скрипте crontab также есть aws cli. Итак, ниже, чем мой сценарий, у меня теперь есть PATH=~/.local/bin:$PATH.

Для меня это сработало:

#!/bin/bash

HOME=/home/ubuntu
AWS_CONFIG_FILE="/home/ubuntu/.aws/config"

aws ec2 describe-instances #or whatever command you need to use.

Пользователь по умолчанию в современных экземплярах EC2 - это Ubuntu, а корневая папка - это домашняя папка пользователя. Вот где также есть все.

Не самое лучшее, но мне пришлось предоставить конфигурацию непосредственно в моем скрипте shell / bash перед командами клиента AWS. нравится:

#!/bin/bash

export AWS_ACCESS_KEY_ID=<ZZZ>
export AWS_SECRET_ACCESS_KEY=<AAA>
export AWS_DEFAULT_REGION=<BBB>
aws s3 cp ....