Mirrors/backupninja
1
0
Fork 0
mirror of https://0xacab.org/liberate/backupninja.git synced 2024-09-16 18:32:24 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge the two FAQs.

Browse Source
This commit is contained in:
intrigeri 2017-02-17 08:49:06 +00:00
parent 5319b341c2
commit f1523f9afa
3 changed files with 21 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
FAQ
View File

@ -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.

20
FAQ.md
View File

@ -1,3 +1,23 @@
duplicity works fine when run standalone, but complains about gpg "public key not found" when run from backupninja
==================================================================================================================
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.
What should I do when rdiff-backup fails?
=========================================

2
Makefile.am
View File

@ -1,7 +1,7 @@
# vi: noexpandtab softtabstop=0
## Process this file with automake to produce Makefile.in
EXTRA_DIST = FAQ README.md COPYING AUTHORS INSTALL.md NEWS ChangeLog \
EXTRA_DIST = FAQ.md README.md COPYING AUTHORS INSTALL.md NEWS ChangeLog \
backupninja.spec backupninja.spec.in autogen.sh
SUBDIRS = etc examples handlers lib man src