← Back to team overview

duplicity-team team mailing list archive

Re: [Question #183711]: Unable to resume backup due to gnupg issue.


Question #183711 on Duplicity changed:

Scott posted a new comment:
Well, I've done some more testing and I think I need to retract a couple
of my earlier issues.

1. I've now tested duplicity 0.6.18 and pinentry 0.8.1 (on Archlinux)
and I can successfully authenticate a full backup, an incremental
backup, and a restarted backup using gpg-agent as the root user from a
cron job on a remote server.  I'm using separate keys for encryption and
signing. I believe the reason this was causing me such huge issues
before was because of a. a pinentry bug that doesn't allow passphrase
entry as root from an su - session, and b. environment issues when
trying to run a duplicity script using either su or sudo. I can only
reliable get duplicity scripts to work from cron. If you have local root
access then this should not be an issue.

2. pinentry still needs to be patched in order to use gpg-agent as root
on a headless server where direct root login from ssh is neither desired
nor allowed.

3. My root gpg-agent has been running for 4 days now with the passphrases still cached and being used by my nightly backup script. I have these values in my  /root/.gnupg/gpg-agent.conf:
max-cache-ttl 60480000
default-cache-ttl 60480000

4. I believe you said in a previous post of mine that 0.6.18 didn't seem
to be respecting the --num-retries parameter

5. I use keychain to start my gpg-agent, so I use this line in my script to source the keys for cron:
eval `keychain --eval web_rsa 42A79D21 E6C991E3` || exit 1

I apologize if I've caused a little extra noise here over the past
several days!! I was getting pretty frustrated until I hit on the right
combo of bugfixes and script parameters to get everything working right.
Let me know if I can provide any additional information.


You received this question notification because you are a member of
duplicity-team, which is an answer contact for Duplicity.