aboutsummaryrefslogtreecommitdiff
path: root/FAQ
diff options
context:
space:
mode:
authorMicah Anderson <micah@riseup.net>2009-02-19 12:20:44 -0500
committerMicah Anderson <micah@riseup.net>2009-02-19 12:20:44 -0500
commit27a7859c42394a78c16b24f0d08ca28667bb1efa (patch)
tree4b825dc642cb6eb9a060e54bf8d69288fbee4904 /FAQ
parent386c4275946520bc590428e730a9d515155436a0 (diff)
downloadbackupninja-27a7859c42394a78c16b24f0d08ca28667bb1efa.tar.gz
backupninja-27a7859c42394a78c16b24f0d08ca28667bb1efa.tar.bz2
creating a debian only branch out of what used to be a subversion repository
Diffstat (limited to 'FAQ')
-rw-r--r--FAQ19
1 files changed, 0 insertions, 19 deletions
diff --git a/FAQ b/FAQ
deleted file mode 100644
index 16a411e..0000000
--- a/FAQ
+++ /dev/null
@@ -1,19 +0,0 @@
-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.