Comment 5 for bug 758077

Revision history for this message
Kenneth Loafman (kenneth-loafman) wrote : Re: [Bug 758077] Re: non-interactive duplicity job using GPG keys crashes

I usually do this in my crontab:
   sudo -u ken -i duplicity ...

--
Sent from my Droid.
On May 4, 2011 9:06 AM, "Steffen" <email address hidden> wrote:
> Had the same problem. Solution: Ensure that in your /etc/crontab you set
> the environment variable $HOME to the home directory of the user that
> executes the cronjob. Because otherwise:
>
> 1) Duplicity won't be able to find it's archive directory and as a
> consequence duplicity will fetch the encrypted metadata from remote and
> needs your private key to decrypt the metadata. (Alternatively use
> duplicity's "--archive-dir" option.)
>
> 2) Additionally, without a correct $HOME environment variable, duplicity
> will use the wrong ~/.gnupg directory and therefore cannot find your
> public/private keys. (I don't know any workaround here, just set $HOME
> correctly. :))
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/758077
>
> Title:
> non-interactive duplicity job using GPG keys crashes
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> New
>
> Bug description:
> I'm running a duplicity nightly backup from cron that is having
> problems. I'm using a GPG keypair. The public key is used to encrypt
> without a PASSPHRASE or interaction, and the private key to decrypt
> and restore interactively with a PASSPHRASE later if necessary.
>
> This works from my command prompt *where I am not prompted for
> anything when running this command*.
>
> However, from cron, this fails with getpass.py being uncomfortable
> about not being able to control echo on the terminal:
>
> ARGS="--asynchronous-upload --tempdir /tmp --no-print-statistics \
> --include /data/backups/bin --encrypt-key CE71E9DC \
> --exclude-globbing-filelist $DEST/bin/rdiff-backup-excludes \
> -v2 --volsize 100 $@"
>
> duplicity $ARGS / file://$DESTDIR
>
>
> /usr/lib64/python2.6/getpass.py:83: GetPassWarning: Can not control echo
on the terminal.
> passwd = fallback_getpass(prompt, stream)
> Warning: Password input may be echoed.
> GnuPG passphrase: Traceback (most recent call last):
> File "/usr/bin/duplicity", line 1245, in <module>
> with_tempdir(main)
> File "/usr/bin/duplicity", line 1238, in with_tempdir
> fn()
> File "/usr/bin/duplicity", line 1139, in main
> sync_archive()
> File "/usr/bin/duplicity", line 949, in sync_archive
> globals.gpg_profile.passphrase = get_passphrase(1, "sync")
> File "/usr/bin/duplicity", line 129, in get_passphrase
> pass1 = getpass.getpass("GnuPG passphrase: ")
> File "/usr/lib64/python2.6/getpass.py", line 83, in unix_getpass
> passwd = fallback_getpass(prompt, stream)
> File "/usr/lib64/python2.6/getpass.py", line 118, in fallback_getpass
> return _raw_input(prompt, stream)
> File "/usr/lib64/python2.6/getpass.py", line 135, in _raw_input
> raise EOFError
> EOFError
>
> duplicity version 0.6.11, Python 2.6.5, RHEL 6.0 x86_64, target
> filesystem is an NFS mount
>
>
>
> Surely non-interactive duplicity commands shouldn't fail because duplicity
can't go interactive!!