Неможливо запустити AWS CLI з CRON (облікові дані)

Спроба запустити простий скрипт резервного копіювання AWS CLI. Він проходить цикл через рядки у файлі включення, створює резервні копії цих шляхів до 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

}

І запис крона:

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 був встановлений у домашній папці користувача, і я додав рядок до мого користувача, .bash_profileщоб додати шлях AWS cli до $PATH. Як не дивно, це насправді те, що документація про встановлення AWS cli підказує вам встановити його. Але користувач .bash_profileне звикає, коли виконуються кронтаб користувача (принаймні, не в моєму середовищі).

Отже, все, що я зробив, щоб виправити це, було гарантувати, що мій сценарій 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 ....