diff options
| author | Micah Anderson <micah@riseup.net> | 2010-01-29 17:02:03 -0500 |
|---|---|---|
| committer | Micah Anderson <micah@riseup.net> | 2010-01-29 17:02:03 -0500 |
| commit | c1f1baebb5170abb49fb0ec5d6d463d6827bae1b (patch) | |
| tree | c57da8f9d364097473bd8cc35ed6f13f60959d61 /FAQ | |
| parent | 329e13e35d0bb394c5beed9893b2a869fda6648c (diff) | |
| download | backupninja-c1f1baebb5170abb49fb0ec5d6d463d6827bae1b.tar.gz backupninja-c1f1baebb5170abb49fb0ec5d6d463d6827bae1b.tar.bz2 | |
fix bad upstream merge
Diffstat (limited to 'FAQ')
| -rw-r--r-- | FAQ | 19 |
1 files changed, 19 insertions, 0 deletions
@@ -0,0 +1,19 @@ +Q: duplicity works fine when run standalone, but complains about gpg +"public key not found" when run from backupninja + +A: We bet you're using sudo to run both duplicity and backupninja, and have been +using sudo as well when generating the GnuPG key pair used by duplicity. + +Quick fix: generate a new GnuPG key pair in a root shell, or using +"sudo -H" instead of plain sudo. + +Another solution: import the GnuPG keypair into the root user's keyring, taking +care of running "gpg --update-trustdb" in a root shell or using "sudo -H" +afterwards, in order to tag this keypair as "ultimately trusted". + +Detailed explanation: sudo does not change $HOME by default, so GnuPG saved the +newly generated key pair to your own keyring, rather than to the root user's +keyring. Running "sudo duplicity" hides the problem, as it uses your own +keyring. Running "sudo backupninja" reveals the problem, as backupninja uses +"su" to make sure it runs duplicity in a real root environment, i.e. using the +root user's GnuPG keyring. |
