mirror of
https://0xacab.org/liberate/backupninja.git
synced 2024-09-19 15:11:38 +02:00
Merge the two FAQs.
This commit is contained in:
parent
5319b341c2
commit
f1523f9afa
19
FAQ
19
FAQ
@ -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
20
FAQ.md
@ -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?
|
What should I do when rdiff-backup fails?
|
||||||
=========================================
|
=========================================
|
||||||
|
|
||||||
|
@ -1,7 +1,7 @@
|
|||||||
# vi: noexpandtab softtabstop=0
|
# vi: noexpandtab softtabstop=0
|
||||||
## Process this file with automake to produce Makefile.in
|
## 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
|
backupninja.spec backupninja.spec.in autogen.sh
|
||||||
|
|
||||||
SUBDIRS = etc examples handlers lib man src
|
SUBDIRS = etc examples handlers lib man src
|
||||||
|
Loading…
Reference in New Issue
Block a user