Question

J'ai un script dont une partie ressemble à ceci :

for file in `ls *.tar.gz`; do
  echo encrypting $file
  gpg --passphrase-file /home/$USER/.gnupg/backup-passphrase \
    --simple-sk-checksum -c  $file
done

Pour une raison quelconque, si j'exécute ce script manuellement, il fonctionne parfaitement et tous les fichiers sont cryptés.Si je lance ceci en tant que tâche cron, echo $file fonctionne bien (je vois "chiffrement <fichier>" dans le journal), mais le fichier n'est pas chiffré et gpg Silent échoue sans sortie stdout/stderr.

Des indices ?

Était-ce utile?

La solution

Il s’avère que la réponse était plus simple que ce à quoi je m’attendais.Il y a un --batch paramètre manquant, gpg essaie de lire depuis /dev/tty qui n'existe pas pour les tâches cron.Pour déboguer que j'ai utilisé --exit-on-status-write-error param.Mais pour l'utiliser, je me suis inspiré du statut de sortie 2, rapporté par echo $? comme l'a suggéré Cd-Man.

Autres conseils

Dans mon cas, gpg ne trouve pas le répertoire personnel pour utiliser les clés :

gpg :pas de clé secrète par défaut :Pas de clé secrète

gpg :0003608.cmd :échec de la signature et du chiffrement :Pas de clé secrète

J'ai donc ajouté --homedir /root/.gnupg.La commande finale peut ressembler à

Echo 'Mot de passe' | gpg -vvv --homedir /root/.gnupg --batch --passphrase-fd 0 --output /usr/share/file.gpg --encrypt ---ssign /usr/share/file.tar.bz2

Vous devez vous assurer que GPG est sur votre chemin lorsque la tâche cron est en cours d'exécution.Votre meilleure hypothèse serait d'obtenir le chemin complet de GPG (en faisant which gpg) et l'exécuter en utilisant le chemin complet (par exemple /usr/bin/gpp...).

Quelques autres conseils de débogage :

  • afficher la valeur de $? après avoir exécuté GPG (comme ceci :écho "$?").Cela vous donne le code de sortie, qui devrait être 0, si cela réussit
  • redirigez le STDERR vers STDOUT pour GPG, puis redirigez STDOUT vers un fichier, pour inspecter les messages d'erreur qui pourraient être imprimés (vous pouvez le faire en ligne de commande : /usr/bin/gpg ... 2>&1 >> gpg.log)

assurez-vous que l'utilisateur qui exécute la tâche cron dispose des autorisations nécessaires pour chiffrer le fichier.

J'ai rencontré ce problème une fois.

Je ne peux pas vraiment vous dire pourquoi, mais je ne pense pas que cron s'exécute avec la même variable d'environnement que l'utilisateur.

En fait, j'ai dû exporter le bon chemin pour que mes programmes s'exécutent bien.Gpg essaie-t-il au moins de s'exécuter ?

Ou les fichiers que vous essayez de chiffrer se trouvent-ils réellement dans le répertoire actuel lorsque le cron s'exécute ?

Essayez peut-être d'exécuter un echo whereis gpg et echo $PATH dans votre script pour voir s'il est inclus...A fonctionné pour moi.

Les tâches @skinp Cron sont exécutées par sh, alors que la plupart des Unix modernes utilisent bash ou ksh pour les connexions interactives.Le plus gros problème (d'après mon expérience) est qu'elle ne comprend pas des choses comme :

export PS1='\u@\h:\w> '

qu'il faut changer en :

PS1='\u@\h:\w> '
export PS1

Ainsi, si cron exécute un script shell qui définit une variable d'environnement en utilisant la première syntaxe, avant d'exécuter une autre commande, l'autre commande ne sera jamais exécutée car sh bombarde en essayant de définir la variable.

Dans mon cas:"gpg :le décryptage a échoué :Mauvaise clé de session".

J'ai essayé d'ajouter /usr/bin/gpg, de vérifier la version, de définir --batch, de définir --home (avec /root/.gnupg et /home/user/.gnupg) et tout n'a pas fonctionné.

/usr/bin/gpg -d --batch --homedir /home/ec2-user/.gnupg --no-mdc-warning -quiet --passphrase "$GPG_PP" "$file"

Il s'est avéré que cron sur l'instance AWS beanstalk nécessitait que la variable d'environnement soit utilisée pour définir la --passphrase $GPG_PP.Cron maintenant :

0 15 * * * $(source /opt/elasticbeanstalk/support/envvars && /home/ec2-user/bin/script.sh >> /home/ec2-user/logs/cron_out.log 2>&1)
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top