Pregunta

Tengo un script que tiene una parte que se ve así:

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

Por alguna razón, si ejecuto este script manualmente, funciona perfectamente bien y todos los archivos están cifrados.Si ejecuto esto como trabajo cron, echo $file funciona bien (veo "cifrar <archivo>" en el registro), pero el archivo no se cifra y gpg silent falla sin salida estándar/stderr.

¿Alguna pista?

¿Fue útil?

Solución

Resulta que la respuesta fue más fácil de lo que esperaba.Hay un --batch Falta el parámetro, gpg intenta leer desde /dev/tty que no existe para trabajos cron.Para depurar que he usado --exit-on-status-write-error parámetro.Pero para usarlo me inspiré en el estado de salida 2, informado por eco $? como sugirió Cd-Man.

Otros consejos

En mi caso, gpg no puede encontrar el directorio de inicio para usar claves:

gpg:sin clave secreta predeterminada:Sin clave secreta

gpg:0003608.cmd:firmar+cifrar falló:Sin clave secreta

Entonces agregué --homedir /root/.gnupg.El comando final puede verse así

echo 'contraseña' | gpg -vvv --homedir /root/.gnupg -batch --passphrase-fd 0 --output /usr/share/file.gpg --encrypt --sign /usr/share/file.tar.bz2

Debe asegurarse de que GPG esté en su ruta cuando se esté ejecutando el cronjob.Su mejor suposición sería obtener la ruta completa de GPG (haciendo which gpg) y ejecutarlo usando la ruta completa (por ejemplo /usr/bin/gpp...).

Algunos otros consejos de depuración:

  • generar el valor de $? después de ejecutar GPG (así:eco "$?").Esto le proporciona el código de salida, que debería ser 0, si tuvo éxito.
  • redirija STDERR a STDOUT para GPG y luego redirija STDOUT a un archivo, para inspeccionar cualquier mensaje de error que pueda imprimirse (puede hacer esto en una línea de comando: /usr/bin/gpg ... 2>&1 >> gpg.log)

asegúrese de que el usuario que ejecuta la tarea cron tenga los permisos necesarios para cifrar el archivo.

Me encontré con este problema una vez.

Realmente no puedo decirte por qué, pero no creo que cron se ejecute con la misma variable de entorno que el usuario.

De hecho, tuve que exportar el buen camino para que mis programas se ejecutaran bien.¿Gpg al menos está intentando ejecutarse?

¿O los archivos que está intentando cifrar están realmente en el directorio actual cuando se ejecuta el cron?

Tal vez intente ejecutar un echo whereis gpg y echo $PATH en su guión para ver si está incluido...Trabajó para mi.

Los trabajos @skinp Cron se ejecutan mediante sh, mientras que la mayoría de los Unix modernos usan bash o ksh para inicios de sesión interactivos.El mayor problema (en mi experiencia) es que sh no entiende cosas como:

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

que debe cambiarse a:

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

Entonces, si cron ejecuta un script de shell que define una variable de entorno usando la primera sintaxis, antes de ejecutar algún otro comando, el otro comando nunca se ejecutará porque sh fracasa al intentar definir la variable.

En mi caso:"gpg:el descifrado falló:Clave de sesión incorrecta".

Intenté agregar /usr/bin/gpg, verificar la versión, configurar --batch, configurar --home (con /root/.gnupg y /home/user/.gnupg) y todo no funcionó.

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

Resultó que cron en la instancia de AWS Beanstalk necesitaba que se usara la variable de entorno para establecer la frase de contraseña $GPG_PP.Cron ahora:

0 15 * * * $(source /opt/elasticbeanstalk/support/envvars && /home/ec2-user/bin/script.sh >> /home/ec2-user/logs/cron_out.log 2>&1)
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top