I have an odd situation here, maybe one of you can help. We have a script that runs via a cron job. It's purpose is to decrypt PGP-encrypted files in a certain directory. I have tried the command two different ways, both fail with the same error message:
gpg --decrypt $file > ${file%.txt}.decrypted.txt gpg --output ${file%.txt}.decrypted.txt --decrypt $file
(Don't even ask about the name substitution. The end-user insists they MUST submit files with a .txt extension, and not .pgp or .gpg)
Anyway, I can run the script fine from a login shell. It works beautifully. But when it runs from a cron job two things happen:
1. A file of zero size is created called file.decrypted.txt 2. The error message in the cron email I get says:
gpg: encrypted with ELG-E key, ID XXXXXXXX gpg: decryption failed: secret key not available
Why does it say "secret key not available"? The output of gpg -K shows that the key is in fact available, and this is further confirmed when I run the script manually and the files are decrypted just fine.
Sean Carolan scarolan@gmail.com wrote:
Why does it say "secret key not available"? The output of gpg -K shows that the key is in fact available, and this is further confirmed when I run the script manually and the files are decrypted just fine.
Is the cron job running as a different user? eg; are you running gpg as a non-privileged user and the cronjob as root?
On Mon, Oct 19, 2009 at 2:41 PM, Spiro Harvey spiro@knossos.net.nz wrote:
Is the cron job running as a different user? eg; are you running gpg as a non-privileged user and the cronjob as root?
The cronjob script runs from /etc/crontab. Let me try root's personal crontab instead.
On Mon, Oct 19, 2009, Sean Carolan wrote:
I have an odd situation here, maybe one of you can help. We have a script that runs via a cron job. It's purpose is to decrypt PGP-encrypted files in a certain directory. I have tried the command two different ways, both fail with the same error message:
Typically this type of problem is caused by environment variables that are set in a login shell, but are missing or different than those set for jobs running under cron.
A relatively simple way of finding the differences in the environment is to use the ``env'' command. In the shell, execute the command ``env | sort > /tmp/env.shell''. Then create a simple script and run it under cron:
#!/bin/bash # (or whatever you run as a shell) env | sort > /tmp/env.cron exit.
Use ``diff -u /tmp/env.shell /tmp/env.cron'' to see the differences.
Bill
Typically this type of problem is caused by environment variables that are set in a login shell, but are missing or different than those set for jobs running under cron.
You nailed it, Bill. Running the cron from root's personal crontab worked fine. Must have been environment variable related.
On Mon, Oct 19, 2009, Sean Carolan wrote:
Typically this type of problem is caused by environment variables that are set in a login shell, but are missing or different than those set for jobs running under cron.
You nailed it, Bill. Running the cron from root's personal crontab worked fine. Must have been environment variable related.
This is probably in a FAQ somewhere as it bites many.
I first ran into this problem at least 25 years ago running Xenix on Radio Shack Model 16s while doing cron updates of FilePro stuff which barfed without a TERM environment variable set even though notthing was using it.
Bill
-
Bill Campbell -
Sean Carolan -
Spiro Harvey