Domanda

Ho uno script che ha una parte simile a questa:

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

Per qualche motivo, se eseguo questo script manualmente, funziona perfettamente e tutti i file vengono crittografati.Se lo eseguo come lavoro cron, echo $file funziona bene (vedo "crittografia <file>" nel registro), ma il file non viene crittografato e gpg silent fallisce senza output stdout/stderr.

Qualche indizio?

È stato utile?

Soluzione

Si scopre che la risposta è stata più semplice di quanto mi aspettassi.C'è un --batch parametro mancante, gpg tenta di leggere da /dev/tty che non esiste per i lavori cron.Per eseguire il debug che ho usato --exit-on-status-write-error param.Ma per usarlo mi sono ispirato all'exit status 2, segnalato da echo $? come suggerito da Cd-Man.

Altri suggerimenti

Nel mio caso gpg non riesce a trovare la directory home per utilizzare le chiavi:

gpg:nessuna chiave segreta predefinita:Nessuna chiave segreta

gpg:0003608.cmd:firma+crittografia non riuscita:Nessuna chiave segreta

Quindi ho aggiunto --homedir /root/.gnupg.Il comando finale può assomigliare a

Echo 'Password' | gpg -vvv ---homedir /root/.gnupg - -batch ---passphrase -fd 0 --output /usr/share/file.gpg --crypt ---sign /usr/share/file.tar.bz2

Dovresti assicurarti che GPG sia nel tuo percorso quando il cronjob è in esecuzione.La tua ipotesi migliore sarebbe quella di ottenere il percorso completo di GPG (facendo which gpg) ed eseguirlo utilizzando il percorso completo (ad esempio /usr/bin/gpp...).

Alcuni altri suggerimenti per il debug:

  • emettere il valore di $? dopo aver eseguito GPG (in questo modo:eco "$?").Questo ti dà il codice di uscita, che dovrebbe essere 0, se ha avuto successo
  • reindirizzare STDERR su STDOUT per GPG e quindi reindirizzare STDOUT su un file, per controllare eventuali messaggi di errore che potrebbero essere stampati (puoi farlo da riga di comando: /usr/bin/gpg ... 2>&1 >> gpg.log)

assicurati che l'utente che sta eseguendo il processo cron disponga delle autorizzazioni necessarie per crittografare il file.

Mi sono imbattuto in questo problema una volta.

Non posso davvero dirti perché, ma non penso che cron venga eseguito con la stessa variabile di ambiente dell'utente.

In realtà dovevo esportare il percorso corretto affinché i miei programmi funzionassero bene.gpg sta almeno tentando di eseguirsi?

Oppure i file che stai tentando di crittografare sono effettivamente nella directory corrente quando viene eseguito il cron?

Forse prova a eseguire a echo whereis gpg E echo $PATH nel tuo script per vedere se è incluso...Ha funzionato per me.

I lavori Cron @skinp vengono eseguiti da sh, mentre la maggior parte degli Unix moderni utilizzano bash o ksh per gli accessi interattivi.Il problema più grande (secondo la mia esperienza) è che sh non capisce cose come:

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

che deve essere modificato in:

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

Quindi, se cron esegue uno script di shell che definisce una variabile d'ambiente utilizzando la prima sintassi, prima di eseguire qualche altro comando, l'altro comando non verrà mai eseguito perché sh fallisce nel tentativo di definire la variabile.

Nel mio caso:"gPG:decrittazione fallita:Chiave di sessione errata".

Ho provato ad aggiungere /usr/bin/gpg, controllare la versione, impostare --batch, impostare --home (con /root/.gnupg e /home/user/.gnupg) e tutto non ha funzionato.

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

Si è scoperto che cron sull'istanza AWS Beanstalk necessitava dell'utilizzo della variabile di ambiente per impostare --passphrase $GPG_PP.Cron ora:

0 15 * * * $(source /opt/elasticbeanstalk/support/envvars && /home/ec2-user/bin/script.sh >> /home/ec2-user/logs/cron_out.log 2>&1)
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top