2017-02-17 09:49:06 +01:00
|
|
|
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.
|
|
|
|
|
|
2017-02-17 09:47:01 +01:00
|
|
|
What should I do when rdiff-backup fails?
|
|
|
|
|
=========================================
|
|
|
|
|
|
|
|
|
|
If rdiff-backup fails, the meta data file may get corrupt. When this
|
|
|
|
|
happens, rdiff-backup will complain loudly every time it is run and
|
|
|
|
|
possibly fail to backup some or all the files.
|
|
|
|
|
|
|
|
|
|
To force rdiff-backup to rebuild the meta data, set this option in
|
|
|
|
|
the `.rdiff` backup action file:
|
|
|
|
|
|
|
|
|
|
options = --force
|
|
|
|
|
|
|
|
|
|
After a rdiff-backup run has been successful you should remove
|
|
|
|
|
this option.
|
|
|
|
|
|
|
|
|
|
How to restrict privileges on the backup server?
|
|
|
|
|
================================================
|
|
|
|
|
|
|
|
|
|
backupninja uses a "push" mechanism, where backups are sent from one
|
|
|
|
|
or several hosts to a centralized backup server.
|
|
|
|
|
|
|
|
|
|
Mount your backup partition with limited execution rights
|
|
|
|
|
---------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
Edit `/etc/fstab` to mount your partition with limited rights. For example:
|
|
|
|
|
|
|
|
|
|
/home ext3 defaults,nosuid,noexec,nodev 0 2
|
|
|
|
|
|
|
|
|
|
Create a user for each client
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
|
|
|
|
On the backup server, it is important to create a separate user for
|
|
|
|
|
each client.
|
|
|
|
|
|
|
|
|
|
Use a restricted shell and jail users
|
|
|
|
|
-------------------------------------
|
|
|
|
|
|
|
|
|
|
Furthermore, you may use a restricted shell like
|
|
|
|
|
[rssh](http://www.pizzashack.org/rssh/index.shtml) or
|
|
|
|
|
[scponly](http://sublimation.org/scponly/wiki/index.php/Main_Page),
|
|
|
|
|
which also offer the ability to jail connections.
|
|
|
|
|
|
|
|
|
|
On the backup server:
|
|
|
|
|
|
|
|
|
|
$ apt-get install scponly
|
|
|
|
|
$ adduser --disabled-password --home /home/backup/ninja-host1 --shell /usr/bin/scponly ninja-host1
|
|
|
|
|
|
|
|
|
|
You may now use `ninja-host1` user to connect to the
|
|
|
|
|
`/home/backup/ninja-host1` jail.
|
