Question Impossible d'exécuter AWS CLI à partir de CRON (informations d'identification)


Essayez d'exécuter un simple script de sauvegarde AWS CLI. Il parcourt les lignes d'un fichier d'inclusion, sauvegarde ces chemins jusqu'à S3 et sauvegarde la sortie dans un fichier journal. Lorsque j'exécute cette commande directement, elle s'exécute sans erreur. Lorsque je l'exécute via CRON, l'erreur «Impossible de localiser les informations d'identification» s'affiche dans mon journal de sortie.

Le script 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

J'ai seulement ajouté la ligne au fichier de configuration après avoir commencé à voir l'erreur, pensant que cela pourrait résoudre le problème (même si je suis certain que c'est là que AWS regarde par défaut).

Le script shell est exécuté en tant que root. Je peux voir le fichier de configuration AWS à l'emplacement spécifié. Et tout me semble bien (comme je l'ai dit, tout va bien en dehors de CRON).


23
2017-07-23 15:51


origine


Essayez un chemin absolu pour ~/.aws/config. - ceejayoz
Certainement essayé en premier (il utilisait /root/.aws/config), mais est revenu à ~ / après l'avoir vu dans d'autres threads. Même erreur de toute façon. - binaryorganic
Pas une réponse directe, mais un commentaire sur l’utilisation des clés d’API: Il est préférable (et bien plus facile) d’attribuer des rôles à vos instances et de créer des règles autour de ces rôles. Dans ce cas, vous n’êtes pas obligé de spécifier les clés, ou faites-les traîner en texte clair sur l'instance. Malheureusement, cela ne peut être spécifié qu'au moment de la création de l'instance. En passant, pour la copie des fichiers journaux (et des sauvegardes, etc.), jetez un coup d'œil aux outils s3cmd, qui offrent des fonctionnalités similaires à celles de rsync. - nico


Réponses:


Si cela fonctionne lorsque vous l'exécutez directement, mais pas à partir de cron, il y a probablement quelque chose de différent dans l'environnement. Vous pouvez enregistrer votre environnement de manière interactive en faisant

set | sort > env.interactive

Et fais la même chose dans ton script

set | sort > /tmp/env.cron

Et alors diff /tmp/env.cron env.interactive et voir ce qui compte. Des choses comme PATH sont les coupables les plus probables.


19
2017-07-24 22:19



Merci! Un pas en avant pour pouvoir résoudre le problème par moi-même est fondamentalement inestimable. Il y avait certainement plusieurs différences dans la variable PATH, et je pense que dans ce cas, c’est la différence dans HOME qui a jeté les bases. En ce qui concerne mon problème spécifique, j'ai fini par l'exécuter à partir du fichier cron de l'utilisateur, au lieu de / etc / crontab, ce qui a tout résolu de mon côté. Merci encore! - binaryorganic
Droite. ajout d'un correct PATH variable(echo $PATH dira ce qu'il devrait être) dans le script d'habitude résout le problème - Fr0zenFyr


Lorsque vous exécutez un travail à partir de crontab, votre $HOME la variable d'environnement est /

Le client Amazon cherche soit

~/.aws/config

ou

~/.aws/credentials

Si $HOME = /, le client ne trouvera pas ces fichiers

Pour que cela fonctionne, mettez à jour votre script afin qu’il exporte un répertoire de base $HOME

export HOME=/root

puis mettez un fichier de configuration ou d’authentification en

/root/.aws/

27
2017-10-15 14:00



Cela a aidé, avec le correctif suivant de stackoverflow.com/a/26480929/354709 ce qui impliquait l'ajout du chemin absolu de la commande aws - car $ PATH n'était pas correctement défini dans l'utilisateur root. - Dan Smart
Cela devrait être la réponse acceptée. - Madbreaks


J'ai pu résoudre ce problème grâce à le suivant:

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

6
2017-07-08 17:35



Mais tout l'intérêt de faire aws configure est pour que vous n'ayez pas à mettre des informations d'identification, par exemple. les scripts. Voir la réponse postée par @chicks pour résoudre ce problème correctement. - Madbreaks
Ne pas stocker AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY valeurs dans les scripts. La première ligne aurait déjà dû fournir ces valeurs. - AWippler


Les binaires de l'outil aws cli sont installés sous /usr/local/bin/aws.

L'erreur que j'ai eu est que l'utilisateur cron n'a pas pu accéder /usr/local/bin/aws en courant; il ne peut accéder qu'à /usr/bin/

Ce que j'ai fait était de créer un lien dans /usr/bin pour aws avec la commande ci-dessous.

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

J'ai également ajouté des modifications à mon script. voici un exemple de fonction:

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

}

Et l'entrée cron:

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

Cette méthode a fonctionné pour moi.


1
2017-08-11 06:37



Mansur, le format de votre réponse est complètement cassé. - Aldekein
en utilisant le chemin complet /usr/bin/aws est la clé de la solution. - Ramratan Gupta


Placez ce code avant votre ligne de commande à exécuter dans crontab -e

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

1
2018-05-31 20:48



J'ai essayé la première solution avec le diff mais rien. le truc pour moi était la variable PATH. - borracciaBlu


Cette ligne par défaut .bashrc fichier pour l’utilisateur empêchera les shells non interactifs d’obtenir l’environnement complet de l’utilisateur (y compris la variable PATH):

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

Commentez la ligne pour permettre $HOME/.bashrc être exécuté à partir d'un contexte non interactif.

Je devais aussi ajouter un explicite source commande à mon script shell pour que l'environnement soit correctement configuré:

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

Voir cette réponse pour plus d'informations.


1
2017-10-04 19:20





Je sais que ce n'est pas la solution parfaite mais cela a fonctionné pour moi:

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

0
2018-03-29 07:30





Juste pour ajouter de la valeur ajoutée, j’avais un problème avec la nouvelle version de bash en utilisant awscli outil installé via PIP i a constaté que rien ne fonctionnera avec cet outil avec les nouvelles versions de bash.

J'ai pu résoudre en installant aws-apitools-ec2 cela peut être installé par

yum install -y aws-apitools-ec2 

Je joins son guide pour plus de référence.

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


0
2017-08-02 04:51



sur Ubuntu 16.04 je ne pouvais pas trouver le paquet. - borracciaBlu


J'ai eu le même problème, mais après avoir supprimé la redirection stderr de mon entrée cron (2>@1), J'ai vu aws: command not found dans le journal.

En effet, AWS cli a été installé dans le dossier de départ de l'utilisateur et j'ai ajouté une ligne à son utilisateur. .bash_profile d'ajouter le chemin d'accès AWS cli au $PATH. Curieusement, c’est en fait la façon dont le Documentation AWS cli install vous dit de l'installer. Mais l'utilisateur .bash_profile n'est pas utilisé lorsque la crontab de l'utilisateur est exécutée (du moins pas dans mon environnement de toute façon).

Donc, tout ce que j'ai fait pour résoudre ce problème est de m'assurer que mon script crontab avait également aws cli sur son chemin. Donc ci-dessous le shebang de mon script, j'ai maintenant PATH=~/.local/bin:$PATH.


0
2017-08-24 10:43