Hi,
this matter is probably resolved by now, but for the archives (and
consideration by David):
John Rouillard wrote on 2013-09-09 21:23:35 +0000 [Re: [BackupPC-users] Issues with a restore]:
On Mon, Sep 09, 2013 at 02:21:27PM -0400, David Williams wrote:
On 9/9/2013 1:53 PM, John Rouillard wrote:
On Mon, Sep 09, 2013 at 12:07:03PM -0400, David Williams wrote:
I will want to restore a whole
bunch of files. Does the backuppc documentation explain how to set
up the ssh key for backuppc to execute as root on the target (which
is in fact one and the same machine)?
^^^^^^^^^^^^^^^^^^^^^^^^
Then why bother with ssh at all?
[...]
Ok, so what would go into the restore command then? [...]
basically, you replace the ssh part with a corresponding sudo part. You also
need to remove one level of quoting. And set up sudo.
For example, the default RsyncClientRestoreCmd is (or was at some point)
$sshPath -q -x -l root $host $rsyncPath $argList+
which would become
/usr/bin/sudo $rsyncPath $argList
(note the missing "+" behind $argList). Replace RsyncClientCmd accordingly if
you also want to continue doing backups (without ssh).
You need an entry something like
backuppc ALL=NOPASSWD: /usr/bin/rsync --server *
in /etc/sudoers (use 'visudo' to edit that).
The same principal is also applicable to tar backups.
[...]
Ah sorry for confusing the issue. I forgot that you can do direct
restores via the web interface. I run with that feature disabled for
security [...]
So do I. For that case, you'd want to additionally enforce the --sender
command line option in the sudoers entry:
backuppc ALL=NOPASSWD: /usr/bin/rsync --server --sender *
or even
backuppc ALL=NOPASSWD: /usr/bin/rsync --server --sender --numeric-ids --perms --owner --group -D --links --times --block-size=2048 --recursive *
(adapt to the command actually run by BackupPC - possibly consult your
auth.log to see the command actually passed to sudo).
As Les followed up with, my method bypasses the web interface totally.
Yes, but you *can* use sudo instead of ssh for escalating privileges on local
backups, and it does make sense, because you avoid the overhead of encryption.
In fact, for security reasons I use an 'ssh -l backuppc remote_host sudo rsync'
type of setup even for remote backups rather than allowing passwordless root
access with an unencrypted ssh key. Thus sudo is also a *more secure* option
for local backups. Someone should really put that into the wiki if it's not
already there ;-) (yes, I promise to really *try* to remember to do so ...).
Hope that helps someone :-).
Regards,
Holger
