-
Notifications
You must be signed in to change notification settings - Fork 16
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
FAQ: new file, with first Q/A for duplicity vs. sudo related issues
- Loading branch information
Showing
1 changed file
with
19 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |